Give the agent a job
Create the agent inside a shared channel. Describe the requests it should handle, the systems and customers in scope, what it may do, and what counts as success. Add the connections, credentials, workflow steps, limits, and human responders it needs. For example: handle requests to change a service account setting. Read the ticket, identify the correct customer and user, inspect the current setting, make the permitted change, read it back, and send the customer an accurate update. Escalate if the identity is unclear or the result cannot be verified. Start with a controlled manual task. Test a successful case, a rejected action, missing information, and an unavailable connection before enabling unattended intake. See Create an agent.Follow a single ticket
1
Receive and understand
An enabled webhook, schedule, or manual request starts a task. The agent reads the request through its configured connections and establishes the customer, target, and expected outcome. Missing information becomes a question for your team.
2
Investigate with context
The agent checks live systems and, when enabled and permitted, searches Org Brain for shared operating knowledge. A previous fix is useful context; current checks establish whether it applies to this case.
3
Choose the next step
The workflow may continue with an agent step, run a saved procedure, or ask a person for input or review. Connector writes require exact-request approval by default. An organization admin can explicitly allow selected channel endpoints to run without approval.
4
Carry out permitted work
The agent uses its own configured connections and credentials. It remains subject to organization, channel, and workflow tool policy. If the needed operation requires local access or an unsupported tool, it hands the work to an operator with the evidence gathered so far.
5
Verify the result
The agent reads back the state and checks the workflow’s success criteria. It can wait for a later check when a change takes time. If verification fails, the configured retry or escalation path keeps the case from being reported as resolved without evidence.
6
Respond or hand off
The agent sends the customer update and changes the ticket through the configured help-desk or mail connection, under its write policy. When it cannot finish, it records the findings and next required action for a human. Completing a Studio task does not by itself close an external ticket.
7
Review and improve
Your team reviews the result in Outcomes, corrects mistakes, and retains useful lessons with the right audience. Org Brain facts, reusable procedures, and agent workflow improvements have different review paths; see How agents learn.
Understand what is running
The agent’s availability and a task’s progress are separate. Draft, Active, Paused, and Archived describe the agent. A task can be queued, running, waiting, completed, failed, or canceled. Pausing new intake does not undo a change already sent to an external system.
Waiting is part of the workflow
Cloud agents continue while the desktop is closed. Follow tasks in the agent’s Tasks view and inspect Activity and Review inside a task. Use Work → My approvals or the desktop inbox for decisions. See AI support agents for detailed controls and recovery.
Where Org Brain fits
Workers search organization-visible evidence. People can also retrieve channel evidence they are authorized to see. A completed run report and a learned channel fact stay in that channel; they do not automatically become knowledge for every agent or customer. Share an operating lesson organization-wide only when that audience is appropriate. Keep customer-specific details in their intended scope, and always verify changing facts against the live system. See Org Brain for sources, consent, citations, and knowledge review.Build your first support agent
Configure the job, connections, triggers, workflow, and limits.
Learn from completed work
Turn evidence into useful knowledge and reviewed improvements.