> ## Documentation Index
> Fetch the complete documentation index at: https://altostrat.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Run the full support loop

> Design an AI support agent that reads the request, investigates, coordinates people, executes approved work, verifies recovery, and responds to the customer.

Build an agent around a support outcome: **the request is understood, the right work is done, the result is verified, and the customer knows what happened**. Studio's digital workers provide the staged cloud workflow. Connected systems provide ticket and infrastructure access. Human tasks bring your team into decisions, and Org Brain supplies permitted organizational knowledge.

This guide uses a stopped customer service as an example. Adapt the same loop to internal IT, customer operations, access requests, incident response, and other support work. The stages and connectors are configuration choices, not a preinstalled integration with every help desk or infrastructure platform.

```mermaid theme={null}
flowchart LR
    accTitle: The full support loop
    accDescr: A request enters investigation, then coordination and approval, followed by action and verification. Verification leads to a customer update and closure or escalation. Outcomes improve future investigations.
    A[Intake] --> B[Investigate]
    B --> C[Coordinate<br/>and approve]
    C --> D[Act and<br/>verify]
    D --> E[Respond<br/>Close or escalate]
    E -. Review and learn .-> B
```

## Before you start

Enable [Digital workers](./digital-workers#before-you-start) for an eligible organization, create a shared channel for the support workflow, and assign a responsible owner and responders. Decide which customer or internal environment the agent may act on.

Connect the ticketing and operational systems through supported cloud tools. Provision credentials specifically for the agent, choose its models and budgets, and define what requires an escalation. Org Brain has its own owner activation and consent; it is useful grounding when enabled, rather than a substitute for the ticket or live system.

## Follow one support case

<Steps>
  <Step title="Receive and understand the request">
    A help-desk event starts a worker through a configured webhook. Configure the trigger mapping to supply the ticket identifier and trusted customer/account mapping when the run is created. The agent uses the configured account to fetch the ticket and read its history and affected service.

    Treat ticket text as context, not permission to select another customer account. If the trusted mapping, target, or requested outcome is missing or ambiguous, ask a human or prepare a clarification through the ticket system before taking action.
  </Step>

  <Step title="Investigate with knowledge and live evidence">
    The agent checks service status and relevant diagnostics through its permitted tools. It searches organization-visible Org Brain evidence for approved operating knowledge when available, then verifies the relevant details against the live system.

    For a stopped service, this might mean checking the current health, recent change history, dependencies, and the approved recovery method. Separate observed facts from the agent's hypothesis.
  </Step>

  <Step title="Bring in the right people">
    If a detail is missing, the agent creates a human question. If a system-changing request is needed, it presents the exact proposed connector request for approval. Your team responds in **Work → My approvals**, the desktop inbox, or a configured Slack route.

    The run keeps its state while it waits. Connector-write approval requires an independent authorized manager; the person who started the run cannot approve that write. After all open human tasks resolve, Studio queues the run to continue.
  </Step>

  <Step title="Carry out the approved work">
    The worker executes the approved connector request with its own configured credential against the intended customer or internal service. Capture the service's response before deciding what to do next.

    Define the action narrowly: for example, restart one named service through its management API. An agent does not gain an operator's SSH session, local network route, or remote desktop simply by belonging to the same channel. If the required action is outside its tools, hand the case to an operator with the evidence collected so far.
  </Step>

  <Step title="Verify recovery">
    Read the service state again and perform the workflow's success check. A successful API response is evidence that a request was accepted, not proof that the customer's problem is resolved.

    Use a durable wait for a later check when recovery takes time. Bound retries and further actions. If the check fails, preserve the evidence and escalate instead of closing the ticket as resolved.
  </Step>

  <Step title="Respond and close the loop">
    Prepare an accurate customer update: what was found, what changed, what was verified, and any remaining action. Send the approved reply through the ticketing connector or a configured mail-service endpoint. Keep internal notes distinct from the public customer reply.

    Closing or changing the ticket is another external write and follows the connector's approval path. If the case needs further work, record the findings and next owner in the support system. A worker run marked Completed does not itself close an external ticket.
  </Step>

  <Step title="Learn from the outcome">
    Review the result, human decisions, time, and cost in **Outcomes**. Save durable lessons with the intended audience and inspect proposed workflow improvements before applying them.

    Worker reports remain channel-scoped evidence for authorized people. They do not automatically become organization-wide knowledge available to worker search. Publish only the facts that should be shared more broadly.
  </Step>
</Steps>

### Decide whether the case is ready to close

Use the observed result to choose the next step. A successful action, a sent reply, and a closed ticket are separate outcomes; the workflow needs evidence for each.

```mermaid theme={null}
flowchart LR
    accTitle: Resolve the case or hand it off
    accDescr: After an approved action, check live state. If the success criteria pass, send an approved customer reply and make an approved ticket closure. If verification or a later step fails, preserve the evidence and hand the case to a named owner.
    Check[Read back<br/>live state] --> Passed{Verified?}
    Passed -->|Yes| Reply[Approve and<br/>send reply]
    Reply -->|Sent| Close[Approve and<br/>close ticket]
    Close -->|Confirmed| Resolved[Case resolved]
    Passed -->|No| Handoff[Save evidence<br/>Hand off to a named owner]
    Reply -->|Failed or blocked| Handoff
    Close -->|Failed or blocked| Handoff
```

Bound any retry path you add. Missing approval or a failed customer update must not become an unsupported claim that the case is resolved.

## Connect the systems that complete the loop

| Part of your operation | Current integration path |
| - | - |
| **Ticket intake** | Configured worker webhooks, manual runs, or schedules that use permitted connector reads. Map the incoming request to the correct worker and customer. |
| **Ticket replies and status changes** | Named help-desk connector endpoints using the agent's credential. Writes require exact-request approval. Define internal notes, public replies, and close/reopen actions separately. |
| **Slack** | Configured human-task cards for supported approvals and questions, plus supported outcome notifications. Members link their Slack identity to Studio. This native route does not provide a general free-form teammate conversation. |
| **Microsoft Teams** | A configured Microsoft 365 connector can expose permitted Graph chat or channel operations using the agent's connected account and scopes. Native Teams approval routing is not enabled; use Work or Slack for required decisions. |
| **Customer email** | A configured mail-service or help-desk API endpoint, with the recipient and message reviewed through the connector-write path. Outlook and Gmail presets include send operations; they need an eligible worker connection and scopes. |
| **Notification email** | Studio's member notifications are a separate service whose unrestricted delivery remains subject to SES production access. Keep an available in-app decision route. |
| **Native email intake** | A preview for enabled non-production deployments. Production workflows should use enabled webhooks, schedules, or manual intake. |
| **Internal or customer infrastructure** | Permitted operations on public HTTPS management APIs using scoped service credentials. The worker connector path rejects private-network targets; local access requires an operator handoff. |
| **Cloud browser jobs** | Staging preview only. Do not make a production workflow depend on these jobs or assume an agent can take over a desktop or managed endpoint. |

Use [Connectors and MCP](./connectors-and-mcp) to define the external operations. Confirm that each operation is supported by the cloud worker runtime; availability in desktop Copilot alone is insufficient.

### Example: connect the customer response to the ticket

The HubSpot preset includes ticket and conversation reads, a customer-visible thread reply, an internal note, and a ticket update. Configure the agent to read the conversation and recipient, send an approved reply, and select the correct closed pipeline stage after verification. Discover the pipeline stage from the connected account rather than inventing an identifier.

Zendesk similarly provides ticket reads and updates with comment and status fields. Keep a public customer reply distinct from an internal note. With either system, the preset supplies API definitions; you still configure the worker's connection, endpoint grants, approval steps, and workflow, then test the complete case in your environment.

## Turn the loop into an agent workflow

In **Administration → Channels**, open your channel and create an agent. A useful starting description is:

> Handle stopped-service support requests for the configured customer environment. Read the ticket and live service state, gather evidence, ask for missing information, request approval for the exact recovery action, verify service health, and prepare an accurate customer update. Close only after the success criteria pass; otherwise escalate with evidence and the next required decision.

Review the generated workflow before activation. Make the expected input, permitted tools, completion evidence, and failure path clear at every stage. A default support template can help with triage and drafting; it does not come with authority or integrations to send replies and change infrastructure.

Separate stages for investigation, approved action, verification, and response make mistakes easier to detect. Use **Verify, then advance** where a stage needs acceptance criteria. Place a configured human review before the next stage's consequential work; connector writes retain their exact-request approval requirement.

See [AI support agents](./digital-workers#create-an-agent) for the UI steps, connections, triggers, budgets, and run controls.

## Keep customer boundaries explicit

The ticket's customer name is context, not authorization. Scope the credential, tenant, tool, target, and channel deliberately. Use separate organizations when customers need an organization-level trust boundary.

Workers search organization-visible Org Brain evidence only. A channel does not turn organization-wide knowledge into a private customer partition. Keep restricted customer details in the appropriately scoped support or operational system instead of publishing them organization-wide to make them searchable.

When handing work to another agent or person, include the authorized target, observed evidence, action already taken, and remaining decision. Transfer only the information needed for that work.

## Test the whole case before scaling

Use a controlled ticket and environment. Activate the saved agent for manual testing before enabling unattended triggers, then exercise these outcomes:

| Test case | Evidence to inspect |
| - | - |
| Recovery succeeds | The correct target changed, live verification passed, and the approved response and ticket update reached the intended customer. |
| Proposed action is rejected | The external write did not run; the case retains its reason and an escalation or next decision. |
| Information or approval is missing | The run waits with the correct responder and resumes only after its required human tasks are resolved. |
| The action succeeds but recovery fails | The agent reports the failed verification and follows the escalation path rather than claiming resolution. |
| A connector fails or the budget is exhausted | The run exposes the failure or waiting reason and does not claim that a response was sent or a ticket was closed. |

Review your help desk and target-system records alongside the run's timeline and artifacts. Expand to another support category only when the existing loop has clear ownership, reliable evidence, and acceptable outcomes.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.