AI support agents

AI support agents carry a configured support workflow from the incoming request to its outcome. Give an agent the tools to read tickets, investigate live systems, ask your team for decisions, perform approved work, and update the customer through connected ticketing or mail services. Include verification and escalation so the workflow ends with a supported resolution or a useful handoff. Studio calls these cloud agents digital workers. In the administration console they appear as Agents inside a shared channel. Each worker inherits that channel’s grounding and tool policy, and each execution creates a run, also called a work item. Workers continue independently of an open desktop. They can pause for a human, wait until a later time, or stop when budget or policy blocks further work. Start with The agent lifecycle for the operating model and Run the full support loop to design the customer journey, then use this guide to configure it.

​

Define the agent’s responsibility

Write a short support contract before generating the workflow: The generated agent and starter templates are a starting point. Review the stages and add the actual connections and permitted operations needed to finish the loop. A triage or drafting template does not automatically have authority to send replies or change infrastructure.

​

Before you start

The organization owner must enable Digital workers in Administration → Organization. Enablement requires at least two members; running workers also requires a supported pooled plan, available credits, and permitted models. If the switch or a run is unavailable, check the explanation in Organization settings or the run detail. Prepare an active shared channel with the right members, grounding, and tools. The worker cannot exceed the channel’s or organization’s policy. Set up credentials intended for the worker; your personal Key Chain entries are not automatically available in the cloud. Use an interactive chat or procedure for work a person should initiate and supervise directly. Workers suit repeatable inputs, explicit outputs, and a clear owner for decisions that need human review.

​

Create an agent

Older links to Workers redirect into the current channel and agent workspace.

​

Find your way around

The agent begins in Draft. Active accepts work, Paused ignores triggers, and Archived is read-only. Pause an agent when you need to stop new triggered work. Queued or waiting runs can be canceled separately; a run that is executing can be canceled only after it pauses. Use Setup → Delete agent to remove an agent from its channel and prevent new runs. Existing run history is kept. Review outstanding runs and human tasks separately before retiring an agent.

​

Triggers and schedules

Open Workflow, find Triggers, and select Add trigger. A worker can have multiple independent triggers. Trigger changes apply immediately. Turning off or removing one does not turn off the others. A run already picked up may still start after a schedule is removed. Schedules use Recurrence (RRULE) and an IANA Timezone. For example, RRULE:FREQ=WEEKLY;BYDAY=MO;BYHOUR=7;BYMINUTE=30 with Australia/Melbourne requests Monday at 07:30 in Melbourne. Check the preview before saving; it catches unsupported or invalid combinations. Workers can also dispatch work to other workers when that capability and the target are permitted. A worker’s durable wait pauses the existing run; a schedule creates a new run for each occurrence.

​

Long-running work and context

A task can wait for a teammate, provisioning, or a later verification check. Studio saves workflow progress and uses the task’s input, context summary, prior step outputs, and available evidence when continuing. It does not keep an unlimited conversation verbatim in the model’s context. Where durable timers are enabled, a single timed wait can be up to 30 days. For a longer dependency, plan bounded follow-up checks and an escalation owner. A timer resumes the existing task; a recurring schedule starts another task. Keep ticket IDs, customer/tenant IDs, external order references, decisions, and the next required check in the case record and step outputs. After a long wait, re-read live status and current authorization before acting. Org Brain can supply permitted background knowledge, but it is not a substitute for the case record or a guarantee of complete historical recall.

​

Stages, completion, and human review

The Workflow editor calls each stage a step. Give each step one clear job, the minimum necessary tools, and an observable result. A Procedure step must reference an active procedure shared with the organization. Saving the agent copies the procedure’s available steps into that workflow version. If the procedure changes, review and save the agent again to use the updated steps; existing runs keep their pinned version. The editor warns when a procedure is unavailable on the current device or requires desktop-only tools. An old saved copy does not bypass a procedure that has since been archived, deleted, or made private. See Procedures. Completion offers Advance or Verify, then advance. Verification uses acceptance criteria, a threshold, and a maximum number of attempts; budget limits still apply. Under Routing, choose the next step and any permitted alternative destinations. An agent cannot freely skip required steps or approvals. Approval → Human review creates a decision point before the stage leaves. Reviewers should be able to understand the input, evidence, proposed result, and scope. “Approve remediation on edge-03 under CHG-123” is more useful than “Continue?” A stage review happens at its configured boundary. If an external action must be approved before execution, place the review before the step that performs it and check the connector endpoint’s approval policy too. Selecting Automatic for a step does not itself grant permission to run connector writes without approval. Stage timing can set an SLA and choose what happens to an unanswered step: keep waiting, fail the item, or skip to the next stage where permitted. A human-review stage cannot skip its approval. Reminders and escalations can reach responders, the worker’s responsible owner, and channel administrators.

​

Tools, credentials, and Org Brain

Effective tools are restricted by cloud-runtime support, organization, channel, and stage policy. For a connector, explicitly allow the endpoints in the channel: enabling the connector alone is insufficient for a worker. A stored grant cannot restore a tool the organization or channel has disabled. Model policy is also checked at runtime, so a changed allowlist can stop a previously valid worker. Connectors let an agent read a ticket, query service health, prepare a customer reply, or request an infrastructure change. Connector writes require human review by default. The run pauses with the exact target and request for an authorized channel owner, channel admin, or organization admin to review. The run initiator cannot approve their own reviewed write. Approval covers that request only; editing it requires a new request and fresh approval. An organization admin can explicitly allow selected channel connector endpoints to run without approval. Those writes execute under the channel’s policy and are recorded in Activity. This setting applies to the permitted endpoint, rather than one ticket or one proposed message, so choose it deliberately for the actions the agent should own. Current tool, credential, target, and organization restrictions still apply. A public ticket reply, customer email, infrastructure change, and ticket closure are all writes, whether they require individual review or have an explicit channel exception. See Channel connector approvals. Under Setup → Connections, supply a worker-specific service credential or connect an OAuth account for that agent. Use an enabled organization connector in service mode; a member’s personal connector is not a worker connection. Keep tenant and target clear in the configuration and stage instructions. Revoked or unavailable credentials need reconnection or correction; the worker does not borrow a member’s personal session. Worker connector requests use permitted public HTTPS endpoints and reject private-network targets. When permitted, workers can use Org Brain to search organization-visible evidence only. Their bound channel must grant the search tool, but workers cannot retrieve channel-only or private member content, and they do not use answer synthesis. Completed and failed run reports can feed Org Brain within the same channel for authorized human members. Dream cycles can propose lessons from those reports as channel facts, which require human review. Neither the reports nor those channel facts become organization-wide knowledge or worker-search results automatically. A worker operates through its supported cloud tools and configured service credentials. It does not inherit your desktop, local terminal, or managed remote-desktop session. Cloud browser jobs are currently restricted to enabled staging deployments; use supported connector/API operations for production infrastructure work. Procedure steps follow the same cloud-tool restrictions. Route work that needs an operator’s local tools to a human step or question with the relevant evidence.

​

Review a run

Open a run from Tasks or its board card. The run panel keeps the task list available while you inspect the case; use Expand run when you need more space. Its header shows the current status and step, with pending decisions and recovery actions above two views:

• Activity — the agent’s saved messages, tool activity, step changes, human responses, and files in one history. Use Outputs to jump to an artifact and inspect or download it where permitted.
• Review — the recorded outcome assessment and its criteria. View run evidence returns to the activity supporting the assessment.

Runs can be Queued, Running, Waiting on a human, Waiting on a timer, Waiting on budget, Completed, Failed, or Canceled. Check the waiting or failure reason before acting. A waiting run may need an answer, a timer, or a corrected budget or policy condition rather than a fresh run. For a failed run, an organization admin can fix the cause and select Requeue. The agent must be active. Requeue continues from the last saved checkpoint; a tool loop that failed before saving can repeat read-only work and incur more usage. Existing runs keep the workflow version they started with, so changing the agent’s instructions is not a way to replace that run’s saved configuration. Under Activity → Technical events and audit verification, chain verification checks the recorded run events. Saved tool activity and files sit outside that chain, and a valid chain does not establish that the agent’s conclusions were correct.

​

Respond to a human task

Use Waiting for approval in the administration console, Work → My approvals in the member area, or the desktop waiting on you inbox. A task can ask for approval, rejection, an answer, a handoff, or an authorized budget override. The available actions depend on your channel role and assignment. After all open human tasks are resolved, Studio queues the worker to resume from its saved state. If it remains waiting, inspect the run’s timeline and current reason. The question below pauses the existing run. Answering it supplies context for the next step; it does not approve a later connector write. Use the administration console’s Tasks, an agent’s Tasks view, or Work → Boards to supervise runs from your channels. These are separate from the desktop chat board, which tracks conversation status. Desktop notifications can open the relevant task. Email preferences are available in desktop settings and Work → Notifications; turning off an email category does not hide its in-app task. If your organization configures Slack through Chat apps, link your Slack identity to Studio before using routed questions and approvals. Supported outcome notifications can also keep the team informed. Native Teams routing is not enabled in the current release. These human-task routes are distinct from customer replies sent through a ticketing or mail connector.

​

Budgets and paused work

A Waiting on budget status can mean a per-run cap, daily cap, organization spend limit, workers switch, plan, or model policy blocked progress. Open the run to identify which condition applies.

• A per-run cap belongs to the worker version the run started with. Raising the definition’s cap affects new runs.
• The daily credit cap covers all of the agent’s runs and applies as soon as you save it. Raise it or wait for the UTC day boundary, then resume eligible waiting work.
• An eligible channel owner, channel admin, or organization admin can grant an additional allowance through a budget-override task. The person who started the run cannot approve their own override.
• Other policy stops require the condition to be fixed before resuming; some usage-recording failures require an operator.

The daily item limit controls how much new triggered work the agent can accept per UTC day; it is separate from credit caps on execution. The default is 50 items when no value is saved. Credit caps are checked at checkpoints. A run can exceed its cap by an in-flight step, and concurrent runs can each add spending before the daily cap takes effect. Review actual usage and billing when setting limits.

​

Outcomes and improvement

Use Outcomes to inspect completion results, model judgments, human confirmations or overrides, and trends in success, duration, and cost. For support work, compare the run with the live service and external ticket: was the fix verified, was the customer informed, and was the case closed or escalated correctly? A completed run is not proof that an external ticket was resolved. Compare like-for-like cases before attributing a change in results to a workflow revision. The nightly worker-refinement pass proposes changes from recent outcomes. Review the proposed change, rationale, and available evaluation evidence before applying it. Some proposals are advice to review rather than an automatic edit. Applying a supported workflow change saves a new worker version; Revert restores prior stages as another version. Runs already in progress keep their pinned version. Worker refinements require human application. A regression can be flagged for review, but the system does not silently apply or revert workflow changes. This is separate from Org Brain’s dream-cycle fact publication and consolidation.

​

Troubleshooting

​

Related