An answer and an action are different products
A system that explains an overdue account is not the same as a system that emails the customer. A system that suggests a meeting time is not the same as one that creates the booking. Once software can change external state, the design has to cover authority, identity, repetition, partial failure and recovery—not only the quality of generated text.
This is where broad claims about autonomous agents become unhelpful. Authority is not a single switch. A system may read some records, draft certain work, automatically take a small set of reversible actions and require approval for everything else. The boundaries should be visible to users and enforced by application code.
Design an authority ladder
A useful rollout gives the system only the authority it has earned. It can begin by observing a workflow and producing a recommendation. It can move to draft mode, where a person accepts or edits the proposed work. Later, low-risk actions with clear rules may run automatically while high-impact or unusual cases still pause.
The ladder can vary by action, customer, value, environment and confidence. Sending an internal summary may have a different boundary from contacting a customer. Updating a note may differ from changing a financial status. The objective is not maximum automation. It is the right balance of speed, control and evidence for each action.
- Observe: read state and compare a proposed result with current work
- Advise: explain options without changing anything
- Draft: prepare an action for a person to approve or edit
- Act with approval: execute only after explicit authorization
- Act within policy: run a narrow, low-risk action automatically
- Escalate: hand uncertain or sensitive cases to the right person
Identity has to reach every tool
The system needs to know which user, service or agent initiated the task and on whose behalf it is operating. A shared API key with broad access makes it difficult to explain why a record was visible or who authorized a change. Identity and scope should travel from the interface through the agent runtime to the tool or domain service.
That does not mean every external product supports perfect delegated authorization. It means the integration should create the narrowest practical credential and preserve the initiating identity in policy and audit. The agent should not gain access merely because a model asks for a tool. Application authorization decides which operation is available for the current task and resource.
Tools should express business operations
A tool named “run SQL” or “call API” gives the agent too much implementation detail and too little business meaning. Safer tools express bounded operations such as “read overdue invoices for this account,” “prepare a follow-up draft” or “create a provisional booking.” Inputs and outputs can then be validated against the domain.
Typed tools also make evaluation and change easier. The system can record which operation was proposed, which fields were supplied and which policy applied. The underlying provider can change without rewriting the agent’s idea of the job. Tools should return explicit not-found, forbidden, unavailable and conflict states rather than ambiguous prose.
Approval is a product workflow
A human approval gate is not complete because the backend waits for a boolean. The reviewer needs enough context to make the decision: the proposed action, relevant source records, what changed, why the system suggested it and the consequence of approval. The interface should make editing or rejecting as easy as accepting when appropriate.
Approvals also need ownership and expiry. A request should reach the right role, avoid sitting indefinitely and respond safely if the underlying state changes before approval. For example, an overdue reminder should be revalidated if payment arrives while the draft waits. The approval event should record who decided, when and what exact action they approved.
Prevent repeated side effects
Networks fail and requests are retried. An agent may also repeat a tool call after an unclear result. Without idempotency, the system can send two emails, create duplicate bookings or attempt the same payment operation more than once. Every material command needs a stable operation identifier and a clear record of its current state.
The tool boundary should distinguish a timeout from a confirmed failure. If the downstream result is unknown, the system may need to reconcile before retrying. Queues and workflow engines can help coordinate long-running tasks, but they do not remove the need for idempotent domain behaviour. Repetition safety belongs in the application, not in a prompt that asks the model to be careful.
Plan for partial failure and reversal
A multi-step action may succeed in one system and fail in another. The CRM can update while the email provider is unavailable. A booking can be held while payment confirmation is delayed. The workflow needs explicit states for partial progress and a person needs to see what remains unresolved.
Some actions can be reversed; others need a compensating action. Deleting a draft is easy. Recalling an external email may be impossible. Refunding a payment is not the same as erasing the original charge. Risk assessment should reflect reversibility, visibility and time sensitivity before the agent receives authority.
Audit the decision and the execution
An audit record should cover more than the final API request. The organisation may need to know the initiating identity, task, relevant context version, model or policy version, proposed operation, approval, tool result and resulting state. This does not mean storing every raw prompt forever. Privacy and retention still apply.
Separate decision traces from durable business events. Debug traces may have shorter retention and stricter access. Business events such as “follow-up approved” or “booking created” belong in the product record. Good audit design lets operators reconstruct a material action without turning logs into an uncontrolled copy of customer data.
Evaluation must include action outcomes
A model can choose the correct tool and still produce a poor business outcome because the context was stale or the action happened at the wrong time. Evaluation should cover the proposal, policy decision, execution and downstream result. The useful unit is the completed task, not only the model response.
Offline datasets help test classification and structured output. Staging exercises reveal integration behaviour. Production monitoring should measure rejection, correction, escalation, retry and rollback. Samples of successful-looking work should still receive review because silent errors can otherwise become the training examples for future memory or policy.
- Correct operation and arguments
- Grounding in current, permitted context
- Policy and approval compliance
- Execution success without duplication
- Appropriate escalation when tools or context fail
- Business outcome and human correction rate
Make cost and limits explicit
Action systems consume model, retrieval, integration and review resources. They can also create external spend. Define model budgets, request limits and action-specific spending or volume limits. A finance agent should not infer that a general business target grants authority to commit funds.
Cost controls belong beside permissions. The system can select a smaller model for routine classification, reserve a stronger model for difficult cases and refuse tasks that exceed the allowed context or tool budget. Operators need dashboards and alerts that connect usage to completed work rather than presenting an isolated token total.
Multiple agents increase coordination risk
Specialised agents can reflect real organizational boundaries: finance, support and sales may need different tools and permission. But adding agents also adds hand-offs, state, latency and failure modes. Free-form agent conversation is a weak substitute for an explicit work contract.
Connected agents should share structured task state and clear ownership. Each role needs an input, output, authority and evaluation. The orchestrator should know when work is complete, blocked or waiting for approval. One capable agent with several bounded tools is often easier to operate until those boundaries are proven necessary.
A controlled rollout
Choose one action and begin in observation mode. Collect real examples, define unacceptable outcomes and test the tool boundary under failure. Move to draft mode with a review interface. Use reviewer edits and rejection reasons to improve context, policy and evaluation rather than immediately changing the prompt.
Introduce automatic execution only for a narrow category with clear evidence, low consequence and reliable rollback or reconciliation. Keep monitoring and sampled review after automation begins. Authority should be reduced when the environment changes, an integration degrades or quality falls below the agreed threshold.
Controlled action is the product
The most valuable part of an action-capable system may not be the model. It may be the identity propagation, approval interface, task state, audit, tool design and failure recovery that make the reasoning usable. Those components are normal software engineering, and they determine whether a business can trust the system near important work.
Software taking action is a meaningful evolution, but it should not be presented as the disappearance of human responsibility. The organisation still owns the policy, data and outcome. A well-designed agent makes that responsibility clearer by exposing authority and evidence at each step.