How agents connect to AMC
How AMC starts, observes, governs and meters a run on your agent, and the terms the rest of these docs use.
AMC does not run your agent's logic. Your agent runs where you deploy it: in Microsoft Foundry, or behind your own HTTP endpoint. AMC holds a registration that says where the agent lives and how to authenticate to it. It then starts runs on it, watches them, routes its questions to people, and prices what each run cost.
Everything AMC does to an agent goes through an adapter. An adapter translates AMC's run model into one orchestrator's protocol. There are two you can register against:
| Adapter | Key | Talks to | Used by |
|---|---|---|---|
| Azure AI Foundry | foundry | A Foundry hosted agent or workflow, over the Foundry Responses protocol (streamed). | Claude skill on Microsoft Foundry, Microsoft Agent Framework |
| Flight Director / custom | flight-director | Any HTTP service that implements AMC's run contract: JSON over HTTP plus a Server-Sent Events stream. | Bring your own agent, Claude skill, self-hosted |
Key terms
| Term | Meaning |
|---|---|
| Workflow / Agent | The two registration kinds (workflow, agent). Both run the same way. The kind decides who may register it: an Agent Manager can register only agents. Kind can't change after registration. |
| Registration | AMC's record of one deployed resource: name, kind, adapter, department, endpoint, authentication, input contract and declared steps. AMC adopts resources that already exist. It never deploys or changes your agent. |
| Run | One execution of a registered resource. Your side issues a run id (orchestratorRunId); AMC keeps its own run record keyed to it. |
| Step | One unit of progress inside a run, with its own status, tokens, model and content. Steps are what people see on the run page. |
| Declared steps | The step plan you register up front (the golden path). AMC shows every declared step as pending from the moment a run starts, then swaps each for the real step as it reports. |
| Input contract | The parameters a run accepts. AMC validates every manual, scheduled and webhook start against it before calling your agent. |
| Intervention | A question your agent asks a person mid-run. The run waits at that step until someone replies in AMC. |
| Assignee | The person a run (and its interventions) belongs to. Set per workflow, per run at start, from an input marked as the assignee, or by the agent itself. |
| Outcome | The verdict on a finished run: success, partial, failure or cancelled. partial is a completed run whose agent reported that part of the work wasn't done; AMC shows it as Completed with issues. Separate from status, and an admin can change it. |
| Golden run | A completed run someone trusted and promoted as the reference. Failure diagnosis compares failed runs against it step by step. See Set and retire golden runs. |
| Budget | A department's spending cap. AMC checks it before every run starts and blocks the start when the cap is reached. See budgets and overrides. |
The run lifecycle
Trigger: Run now | schedule | webhook
|
v
AMC API
1. validate inputs against the input contract (400 on a bad input)
2. check the workflow type is enabled (409 if it is switched off)
3. pre-run budget gate (blocked at the cap)
4. adapter.StartRun ------------------------------> your agent
POST /runs (or Foundry Responses)
5. store the run as "running" <----------- { orchestratorRunId, status }
Status sync (every 60 s by default, per run)
6. GET /runs/{id}/status and GET /runs/{id}/tokens
- steps and current step -> run page
- status human_intervention -> Intervention: Review queue, bell, email
- tokens and cost -> ROI, department budget spend
- completed | failed | cancelled -> outcome, failure reason, notifications
On demand
7. someone watches the run -> GET /runs/{id}/events (SSE, live view only)
8. someone opens a step -> GET /runs/{id}/steps/{stepId}/content
9. someone answers -> POST /runs/{id}/messages
10. someone cancels -> POST /runs/{id}/cancelThe paths in this diagram are the custom adapter's. The Foundry adapter does the same jobs over the Foundry Responses protocol, reading status, steps and tokens from the streamed response and its markers.
Invoke
A run starts from Run now, a schedule, or a webhook (see Schedule workflows and set up webhooks). Whatever the trigger, AMC sends your agent the same thing: the resource id and a flat map of string inputs. A rejected start (bad input, disabled type, budget block) never reaches your agent and leaves no run behind.
Observe
AMC's status sync polls every live run. That poll is the source of truth: it records status, steps, tokens, cost, the assignee, the run's name and why it failed. The SSE stream only drives the live view for someone watching the run, so an agent with no working stream still records correctly, one poll behind.
AMC does not store step content. The step list and each step's content are read through to your agent when someone opens the run, so keep finished runs available on your side.
Govern
- Departments and roles: every registration belongs to a department, and only people with access to it see its runs. See Roles and permissions.
- Interventions: when your agent reports
human_intervention, AMC opens an intervention, routes it to the run's assignee, tracks its SLA, and delivers the reply back to your agent. - Golden runs and failure review: failed runs carry the reason your agent reported and are compared against the golden run.
- Sensitive resources: a registration marked sensitive hides its runs from people without a grant.
- Audit: registrations, runs, replies and overrides are written to the audit log.
Meter
Your agent reports tokens per step, split into input and output, with the model that produced them. AMC prices each run from that report, or uses the cost your agent computed itself when it reports one. The cost feeds the ROI views and the department budget the next run is checked against. See Report tokens and cost.
Related
Last updated 2026-10-21