Autonomy should be earned, not assumed.
Agent orchestration is fundamentally about controlling state and access around uncertain decisions. The tool catalogue is less important than what happens when a tool call is repeated, fails or carries an instruction from an untrusted document.
What has to be true before the next action is allowed?
Put authority in explicit state transitions and narrow tool contracts. Model confidence and instructions inside an attachment cannot grant a permission.
Authority changes at the approval boundary.
An illustrative service-adjustment workflow separates reading, proposing, approving and committing. Each transition has an independent condition; repeated delivery must not repeat the business effect.
Read
A scoped identity may read the current service case and permitted account fields.
- Transition condition
- Reject unrelated account identifiers and treat attachments as untrusted data.
Propose
The model may draft an adjustment within the task's bounded inputs.
- Transition condition
- Validate the target, amount and reason. Proposal creation performs no write.
Review
An authorized reviewer sees the exact target, proposed change and evidence.
- Transition condition
- Approval binds the reviewed payload; an edited payload requires a new approval.
Commit
A narrow tool executes the approved action with a stable operation key.
- Transition condition
- Verify current authorization and record the authoritative result before reporting completion.
Reconcile
On an unknown result, inspect destination state before retrying.
- Transition condition
- Reuse the operation key. Escalate a conflict rather than creating a second adjustment.
Illustrative state model. No account is read and no adjustment is made by this page.
Inspect the action boundary.
- A state-transition table and a tool/identity permissions matrix.
- Repeated-action, hostile-tool-output and changed-approval test traces.
- An audit trail linking proposal, reviewer, approved payload, operation key and destination acknowledgment.
Use less autonomy when it solves the task.
A deterministic workflow with one classification step may be the better system. Add autonomous decisions only where their benefit survives explicit permissions, evaluation, recovery and operating cost.
The agent orchestration argument
For CTO, CIO, CPO, COO
The situation behind the request
An assistant can open a service ticket, look up account data and propose an adjustment. An untrusted attachment could contain instructions to access unrelated accounts or change the amount.
Where the obvious solution falls short
Prompt boundaries are not authorization boundaries. Excessive tool permissions, hidden state and non-idempotent actions can turn an otherwise useful workflow into a serious operational risk.
How we would approach the work
Use a state machine or explicit workflow orchestration to define allowed steps, permission scopes, approvals and recovery. Give models narrow tool interfaces and read-only access by default.
What the engagement may include
- Tool and identity permissions matrix.
- State machine, action gates and human-review interface.
- Retries, idempotency, compensation and audit mechanisms.
- Prompt-injection, data leakage and failure evaluation.
The choices worth making explicitly
The right design may use zero autonomous agents and one classification step. Multi-agent collaboration is a means, not the objective.
What we would test before calling it ready
Test repeated actions, partial failure, malicious tool outputs, conflicting instructions, false confidence, authorization bypass and rollback feasibility.
A sensible first step
Take one bounded task and define what the agent may not do. A permission list is more useful than a demo video.