AI Agents in Production: Tools, Authority and Recovery
AI Agents in Production: Tools, Authority and Recovery
An AI agent becomes interesting when it can do more than produce an answer. It may choose a tool, retrieve a record, inspect the result and decide which action is needed next. That flexibility can help with work that has several possible paths, but it also creates a new question: who has authorized the software to take each step? A capable language model can suggest a reasonable action; a dependable production system must establish whether the action is permitted, whether it succeeded, and what happens if the attempt is interrupted.
The most useful distinction is between model reasoning and operational authority. A model may propose creating a support case, restarting a service or changing a delivery address. The application must still validate the caller, check policy, constrain tool arguments, manage transaction state and record an audit trail. An agent that writes a convincing summary after an unauthorized action has failed its task, however fluent the summary sounds.
Building reliable agents therefore resembles designing distributed software with an additional probabilistic decision-making layer. The agent needs context, well-defined tools, guarded execution, observability and a way to recover from errors. Choosing an impressive model is only one part of that design.
Know when an agent is better than a workflow
A deterministic workflow follows a known sequence: validate a request, call Service A, transform the response, call Service B and return a result. It is usually the stronger design when the steps are fixed and need strict guarantees. An agent is useful when it must choose between several approved paths based on ambiguous information, ask clarifying questions, or investigate unexpected intermediate results. It should not replace conventional code simply because a tool-based workflow sounds more modern.
Imagine a help-desk assistant receiving “I can no longer access my project dashboard.” The next step may depend on whether the issue is identity, network access, an expired subscription or a service outage. An agent can gather evidence through distinct read-only tools, compare their results and suggest an appropriate response. Creating a new permission grant, however, should remain a controlled business operation, not an unrestricted model command.
The design becomes clearer when the agent’s choices are bounded. The model may decide which diagnostic tool to call, but the tool catalog, caller permissions, maximum request count and allowed arguments come from the application. A conventional orchestrator may still handle the predictable portions, leaving the agent to interpret information only where it adds value.
| Situation | Likely better starting point | Why |
|---|---|---|
| Three known approval steps in a fixed order | Workflow engine or ordinary application code | Predictable transitions and clearer audit controls |
| Diagnosis across several possible systems | Bounded agent with read-only tools | Evidence may determine the next approved query |
| Updating an account or issuing a refund | Deterministic transaction service | Strong permission, validation and idempotency requirements |
| Drafting a report from approved evidence | Model-assisted workflow, possibly agentic retrieval | Language synthesis helps after source selection |
| Unrestricted self-directed changes to infrastructure | No automatic production execution | Unbounded consequences outweigh the claimed flexibility |
Define every tool as a permissioned contract
A tool should have a narrow, well-documented purpose, typed arguments and meaningful errors. “Look up a case” is different from “change case status,” even when both access the same backend. Expose those actions separately. The lookup can operate under read permissions and return only fields the caller may see. The update should require its own validation of current state, caller role, policy and any approval threshold.
Do not rely on the model to validate its own arguments. If a tool accepts a customer identifier, the backend must check that the authenticated user can access that customer. A model-generated customer ID is input, not proof of entitlement. Reject out-of-scope resources and record a safe error without leaking whether a restricted account exists. For sensitive actions, require explicit confirmation through a trusted user interface or the responsible human approval process.
When multiple AWS accounts or services participate, distinguish the workload’s role from the end user’s identity. IAM determines what the service can invoke; application authorization determines which request the specific caller may make. A shared integration role with broad administrative rights cannot safely substitute for user-level rules. The IAM and multi-account design boundary becomes especially important when agents can invoke systems managed by different teams.
Tool output is also untrusted input. A retrieved web page or ticket comment may contain an instruction to ignore controls, send data to an outsider or execute a different tool. That content should be treated as data from the source, not as a new command with authority over the agent. Validate tool responses and keep tool permissions independent from any instructions embedded in retrieved documents.
Separate conversation state, memory and external knowledge
Agents may need short-lived task state: which tools were called, what evidence was found, which arguments were confirmed and which step is pending. That is not the same thing as a persistent memory about the user, and neither replaces a current knowledge base. Mixing all three can produce strange failures. A previous conversation summary might be useful context but should not prove that a customer’s access permission remains valid today.
A reliable state store records enough information to resume or reconcile work after interruptions. For a multistep support request, the application may need the job identifier, the validated user and account scope, approved tool results, completed actions and pending confirmations. Sensitive state should be access controlled, retained for a defined period and not copied indiscriminately into every new model prompt.
External knowledge should come from governed source systems. If the agent needs a current refund policy, retrieve the approved version using the caller’s rights; do not rely on an old summary cached in the model’s context. If a document has changed, the retrieval layer and its permissions must reflect the change. An agent can be very effective at choosing questions, but the source-of-truth rules still determine whether its evidence is appropriate.
Memory can improve continuity for permitted tasks, but automatic learning is not a default property of every agent. Persisting a note, updating a prompt, fine-tuning a model and changing a workflow are separate operations with different reviews. A system should not silently convert every user correction into a production rule without checking provenance, scope, privacy and regression risk.
Choose the runtime and gateway without confusing them with autonomy
There are several valid ways to run an agent. A service may orchestrate tool calls directly in application code, use a framework to manage model/tool interactions, or rely on a managed runtime for part of the execution environment. The choice should follow requirements for state management, deployment, identity, traces and failure recovery. A managed service reduces some operational work but does not inherit authority over the business systems being called.
AWS’s 2026 product changes matter here. Amazon Bedrock Agents, launched in 2023, is now Bedrock Agents Classic and stopped accepting new customers on July 30, 2026. Existing supported customers can continue using Classic in maintenance mode. AWS recommends Amazon Bedrock AgentCore for new or migrating workloads requiring comparable agent infrastructure. That change concerns Agents Classic, not the availability of Bedrock foundation models, Knowledge Bases or Guardrails.
AgentCore Gateway can expose approved backend capabilities through a common tool interface, including supported MCP patterns, but it has separate inbound and outbound authorization choices. A gateway that merely authenticates a caller without enforcing authorization at the gateway can leave decisions to a downstream service. AWS explicitly warns that such configurations require strong target-side policy. A valid token and a valid tool schema are not enough if any authenticated caller can invoke a sensitive backend without an entitlement check.
A migration from older orchestration must inspect behavior, not just service names. Map how prompts are constructed, which tools can execute, how identities are propagated, what state is retained, and what happens after a timeout. Confirm each capability against the actual currently supported AWS documentation and Region. An agent that runs successfully in a sandbox is not automatically equivalent to the original governed production workflow.
Make retries safe before allowing the agent to write
An agent can call a service and lose the response just as any distributed application can. Suppose an authorized support agent creates a replacement order, but the HTTP connection fails after the database commits. The model sees a timeout and tries again. Without an idempotency key or equivalent reconciliation mechanism, the backend might create two orders. A prompt telling the model “don’t repeat actions” cannot provide the guarantee.
Business actions should use stable operation identifiers, validation of current state and durable outcome records. On retry, the backend can return the earlier result rather than performing a second write. A function or queue may deliver an event more than once, and a long-running agent may resume after an interruption. The application should therefore distinguish “not attempted,” “attempted but unresolved,” “completed” and “failed.” An agent should not announce success until the authoritative system confirms it.
Bound tool-call volume and cost. A model that repeatedly searches for the same information or retries a denied action can consume resources without improving the outcome. Distinguish transient throttling from validation or permission errors, set maximum attempts, and enforce a total task deadline. When the task cannot continue safely, return the known state and route the remaining work to a controlled human or system process.
Recovery planning should include irreversible outcomes. Reverting a prompt or redeploying a previous agent version will not undo an email already sent or a financial transfer already committed. Compensating actions, approvals and transaction reconciliation belong in the business workflow itself. Those guarantees can be harder to implement than the initial model-driven choice of a tool.
Evaluate trajectories and outcomes, not only final prose
A user may receive a correct-looking answer even when the agent called the wrong tool, exposed unnecessary data or took a costly detour. The complete trajectory matters: which evidence was retrieved, which action was proposed, which arguments passed validation, which tools were invoked, and what the backend actually recorded. Good evaluation does not only ask whether a judge model liked the final sentence.
Build a test set from realistic tasks, including a simple read-only question, an ambiguous request requiring clarification, an unavailable tool, a revoked user permission, a tool returning malformed data, and a state-changing request that experiences a lost acknowledgment. State the expected permitted path for each case. Some tests can check exact records or tool calls deterministically; others require expert review of the reasoning and usefulness of the answer.
For high-risk operations, incorrect authority is a hard failure even if the final summary is helpful. For information retrieval, evidence quality and the response’s support in sources should be assessed separately. A useful agent evaluation and incident investigation connects model output to retrieval and tool effects, then verifies the business outcome rather than accepting a self-reported success.
Monitoring should reveal the source of an agent’s problem. Record correlation IDs, application and model versions, policy version, safe tool arguments or references, authorization decision, call duration, retries, errors and terminal state. Protect sensitive values in logs. Aggregate metrics such as correctly completed tasks, denied actions, unresolved jobs, tool errors, p95 latency and cost per successful case help determine whether an agent is genuinely improving operations.
Add multiple agents only when responsibility is clearer
Specialist agents can divide a large task: one gathers evidence, another checks a rule, and another composes a final explanation. That separation may help when roles, tools and outputs can be defined precisely. But multiplying agents also increases model calls, context transfers, permission paths and the chance that a partial conclusion is repeated as fact. A single well-constrained agent or conventional workflow may be easier to operate for most small tasks.
Use multi-agent patterns when there is a meaningful division of work, not as a substitute for a clear specification. Each component needs an input contract, an output contract, a permitted tool set and a method for handling disagreement or missing evidence. If two specialists offer conflicting conclusions, a coordinator should surface the conflict or request authoritative data rather than select whichever answer sounds confident.
Shared state should identify the owner of each action. If one agent submits an update, another should not repeat it merely because it lacks visibility into the first result. The same idempotency and business-permission rules apply across multiple agents. More autonomous components do not create more authority; they make the boundaries between decision, execution and audit even more important.
Roll out useful autonomy in controlled stages
A safe first release can be read-only. Give the agent narrow retrieval and diagnostic tools, and make it cite the evidence that supports its answer. Evaluate what users actually need, which sources are missing and how often the system escalates appropriately. Only after the evidence path works should the team consider draft-producing tools or low-impact actions.
The next stage can allow reversible, scoped operations. For example, the agent may prepare a support-case draft that an employee approves before submission. This exposes issues with argument schemas, user confirmation and state recovery without granting unilateral control over consequential systems. Add more privileges only after tests show that authorization, logging and recovery work under realistic failures.
When the application uses a managed model platform, combine agent-specific controls with ordinary software boundaries. The updated Bedrock Guardrails policy design helps distinguish content screening from action authorization, while a production Bedrock integration shows how requests, retrieval, tools, timeouts and transaction state fit together. Neither resource replaces the requirement to verify the permissions of the actual user and workload.
An agent is worth deploying when its flexibility produces a measured improvement over a simpler alternative. Compare correctly completed tasks, review effort, incident rate, latency, expense and the consequences of errors. The engineering objective is not maximal autonomy. It is a system that uses model reasoning where uncertainty makes it valuable, keeps authority inside explicit software controls and can explain and recover from mistakes when real work does not follow the happy path.
- Category: All Certifications Amazon
- Tags: Agentic Shift
