Why capable agents still fail in operations
The models are not the bottleneck. An agent asked to chase a late invoice can write a perfectly good email. What it cannot know from a prompt is that the invoice is in its second approval loop, that this customer disputed three of its last five invoices, that the account is on a payment plan agreed last month, and that external communication to this tier of customer requires a person's approval. Without that context the agent is confidently generic. With it, the same model becomes useful.
Operational context, bounded
Operational context is the case's neighborhood: the process it belongs to, the events so far, the objects it concerns (customer, supplier, order, invoice), the current process state, the applicable policies, prior decisions and their outcomes, and the actions permitted at the current autonomy level. Giving an agent that neighborhood — and only that neighborhood — is what makes its reasoning relevant and its scope safe. A process graph, derived from events rather than hand-modelled, is the natural source.
Agents are one executor among several
Not every intervention needs an agent. Fully specified, high-volume work belongs to deterministic automation. Atomic operations in a system of record belong to an API call. Actions with material consequences belong to a person. Agents earn their place where the work is ambiguous, the action is reversible and contextual reasoning helps — drafting, triaging, assembling evidence, proposing. Executor routing makes this choice explicitly, from factors such as predictability, value at stake, regulation, cost, confidence, judgment required, reversibility and customer impact.
Autonomy is earned, one level at a time
The safe way to introduce agents is to grant authority per action type, not per process, and to increase it on evidence. A ladder from observe, through predict and recommend, to prepare, execute with approval and bounded autonomy lets a risk committee sign a policy it understands. Promotion happens when the record shows the actions were approved, rarely edited and moved the KPI; demotion is automatic on drift or breach. The same agent step may run at different levels for different action types.
What every agent action needs
- An identity and a scope, like a service account — never a shared credential.
- A bounded context and a permitted tool set.
- A schema for its output, so downstream steps and people can check it.
- A cost budget.
- A policy check before anything leaves the system.
- An audit entry linking the prediction, the recommendation, the action and its result.
Inside the process, not beside it
The failure mode of most enterprise AI is the floating assistant: a chat window beside the work, disconnected from the case, the queue and the policy. Agentic orchestration puts the agent inside the process as a step in a governed playbook — triggered by a prediction, bounded by context, routed by fit, checked by policy, approved by a person where it matters, and measured afterwards. That is the difference between a demo and an operation.
Give an agent the case's neighborhood and a level of authority it has earned. Everything else is a prompt.