Remove the human turn-taking and an agent becomes a worker: triggered by events, pursuing goals, taking actions at machine speed. The design discipline is bounding what it can do between human checkpoints.
The flow — what actually happens
Plain-language first; the packet-level
view underneath each step is what you'd see in a Wireshark trace, and what healthy looks like.
-
A trigger fires
An email arrives, a record changes, a schedule ticks. No human asked anything — the agent's run begins because the world changed. This is the moment that separates autonomous from conversational: nobody is watching THIS run.
On the wire Trigger event -> agent runtime invocation, logged per run with the triggering context — run history is your only witness, which is why it must be retained and reviewed.
-
The reasoning loop
The agent plans against its instructions: read the invoice, check the PO, draft the response, decide next steps. Each iteration can call actions. The loop is where capability lives — and where a bad plan compounds unattended.
On the wire Action calls to registered endpoints, each with the agent's identity (Agent ID) on the wire — per-action telemetry under that identity is your audit trail and your anomaly detector.
-
The checkpoint (if you designed one)
Well-designed autonomy escalates at consequence boundaries: draft-for-approval instead of send, propose instead of execute beyond thresholds. The checkpoint is a design artifact — its ABSENCE is a decision too, one someone should have made consciously.
On the wire Approval steps appear as human tasks (Teams/Approvals) in the run — a run history with zero human touchpoints on consequential actions is the red-flag pattern to hunt.
-
Completion — or the kill switch
The run ends, results logged. When something is wrong AT SCALE (a loop misfiring on every record), the question is 'who can stop it in one minute?' — disable the agent identity (CA/Entra), pause the agent, or kill the trigger. All three paths should be documented BEFORE enablement.
On the wire The disable event and the run-rate falling to zero — your incident's closure evidence, and a drill worth running once before production.
The bounding checklist (per autonomous agent, before enablement)
- Trigger scope: exactly what starts it; volume ceiling expected.
- Action allowlist: what it may do, with WRITE actions enumerated
separately — reads inform, writes commit.
- Consequence thresholds: above X (money, external comms, deletions),
a human checkpoint — explicit, tested.
- Identity least-privilege: the Agent ID's permissions match the
allowlist (governance concept) — not the maker's own god-rights.
- Kill paths: the three stop mechanisms named, with WHO may pull them.
- Run retention: history kept long enough to reconstruct any dispute.
An agent that can't produce this one-pager isn't ready for triggers —
that's the promotion gate.
Failure patterns to design against
| Pattern |
Bound that prevents it |
| Loop storm (trigger feeds its own output) |
Trigger filters + run-rate ceilings |
| Confident wrong actions at scale |
Consequence thresholds + draft-mode defaults |
| Scope creep after go-live |
Change-review on definitions (audit alerts) |
| Orphaned autonomy (owner left, agent kept running) |
Ownership lifecycle + periodic re-attestation |
What to watch (proofs)
- Run-rate baselines per agent: normal volume graphed — the storm is a
spike you can alert on within minutes, not a month-end surprise.
- Human-touchpoint ratio: consequential actions with vs without approvals
in run history — the checkpoint design, measured in production.
- The kill drill: one rehearsed disable, timed — 'who can stop it' as a
tested number, not an org-chart guess.
- Write-action audit: everything the agent COMMITTED (sent, changed,
posted) under its identity — the weekly review that keeps autonomy
boring.
Discussion
No messages yet — start the thread.
