Create an Independent Agent
Create an independent agent when a workflow needs to run continuously without depending on a user session. The agent can monitor events, respond through a dedicated Slack or Microsoft Teams identity, and use admin-approved tools to execute work.
Independent agents are in beta. Available templates, channels, triggers, and publishing options depend on your deployment.
Prerequisites
Before you begin, ask your administrator to confirm that:
- Independent agents are enabled for your deployment.
- You have permission to create or edit agents.
- Your administrator created and shared any required service credentials. Credentials are optional unless the agent acts in a connected app as a non-human identity.
- The required Slack, Microsoft Teams, or connected-system tools are available.
- Your organization approved the workflow's knowledge sources and target channels.
Refer to Add a service credential to your agent for instructions on attaching an existing credential.
Design the workflow
Define the following details before opening Agent builder:
- Goal: The outcome the agent owns
- Inputs: The events, messages, or records that start work
- Knowledge: The sources the agent uses for context
- Tools: The systems the agent reads or updates
- Audience: The people or groups who interact with the agent
- Approval rules: The steps that require human review or approval
- Failure path: The steps the agent takes when a tool or connected system is unavailable
Start with one workflow and a minimal set of tools. Add more actions after validating the read-only path.
Create the agent
- In Glean, open Agents.
- Select Create agent.
- Select the Independent agent template. If it does not appear, ask your administrator to enable the feature or template.
- Enter a name and description that explain the role the agent owns.
- Save the draft and open it in Agent builder.
Configure the agent profile
Give the agent a recognizable name and description. Explain what it handles and where it operates. Avoid naming the agent after the person who built it.
For example:
- Name: On-call triage
- Description: Monitors the engineering escalation channel, gathers context from approved sources, and assigns follow-up to the appropriate owner.
If your deployment exposes identity or profile settings, use them to configure the agent's external name and profile.
Add channels and presence
Configure the Slack or Microsoft Teams channels where the agent listens or responds.
When selecting channels:
- Use channels dedicated to the workflow or channels where the agent's role is clear.
- Explicitly state which messages start a run and which messages the agent ignores.
- Start with a private or test channel.
- Confirm that you installed the agent's external app or bot in every target channel.
- Inform channel members what the agent does and how to report an incorrect response.
Refer to Set up Slack service credential or Set up Microsoft Teams service credential for setup instructions.
Add knowledge and tools
Add the smallest set of sources and tools required to support the workflow.
Use knowledge sources for context, such as runbooks, ownership records, or support procedures. Use tools for actions, such as reading a ticket, posting a message, or updating a record.
For every tool, set the execution mode:
- Read data only
- Draft a change for review
- Execute the change without user confirmation
Keep write tools interactive until you test and review the workflow.
Attach service credentials
If the agent acts in a connected system, attach an existing service credential:
- Open the agent in Agent builder.
- Select the Tools tab.
- Select Service credentials.
- Choose the credential that your administrator shared with you.
- Confirm that the credential matches the intended system, environment, and access scope.
- Save the agent.
An administrator creates, scopes, and manages credentials. The agent runtime receives the authentication server-side and does not expose the raw credential to you or the agent.
An agent can use multiple credentials. For example, it can use a Slack credential for channel messages and a Jira credential for ticket updates. Each credential applies only to its connected system.
Configure triggers
Select the events that start the workflow. Depending on your deployment, you can use a channel message, a connected-system event, or a schedule.
Define trigger conditions narrowly. For example, limit an on-call agent to a specific escalation channel and message pattern rather than every message in the workspace.
If the workflow runs on a schedule, ensure its output has a designated destination. Refer to Schedule triggers for default scheduled-agent behavior.
Test the workflow
Test the agent before publishing it to a shared audience:
- Run a normal input that should trigger the workflow.
- Run an input that should not trigger the workflow.
- Test missing, duplicate, and malformed inputs.
- Confirm that the agent retrieves only approved knowledge.
- Confirm that each tool uses the correct credential.
- Verify that write actions pause for approval when required.
- Inspect the message, ticket, or record created in the connected system.
- Review run details and fix any failed or unexpected steps.
Use a read-only or shadow configuration first if supported by your deployment. Do not test against production records unless the owner approves the test plan.
A test succeeds when the agent starts only for intended inputs, uses expected sources and credentials, produces an actionable result, and handles unsafe or unsupported requests without making unintended changes.
Publish the agent
Before publishing, review the following details:
- Agent name, description, and owner
- Target channels and audience
- Knowledge sources and permission boundaries
- Tools and service credentials
- Trigger conditions
- Approval requirements for write actions
- Failure and escalation behavior
- Support contact or feedback channel
Publish to a limited audience first. Expand access only after the owner reviews initial runs and verifies expected behavior.
Maintain the agent
Independent agents require ongoing maintenance. Review the agent when:
- A connected system updates its API, app, bot, or permissions.
- An administrator rotates, expires, or revokes a service credential.
- You add a new channel or audience.
- Knowledge sources change.
- The agent produces errors or unexpected writes.
- The workflow no longer aligns with the process it owns.
Maintain a record of the agent's purpose, credentials, connected systems, target channels, and rollback procedures to support ownership transitions.