AI Agent Architecture: Tools, State, Approvals, and Safe Execution

Begin with a constrained job, not a general assistant

An agent becomes useful when it can observe a situation, choose an allowed action, and verify the result. That does not require unrestricted access. Define one job in operational language: which event starts it, which records it may read, which decisions it may recommend, and what successful completion looks like. A support triage agent, for example, can classify a ticket and prepare a draft without being allowed to refund an order or send a message.

Write the boundaries before selecting a model. If the team cannot state what the agent must never do, the workflow is not ready for autonomous execution. The NIST AI Risk Management Framework is a useful structure for mapping risks, owners, measurements, and controls rather than treating safety as a prompt-writing exercise.

Turn integrations into narrow, typed tools

A function such as request(url, body) gives the model an unnecessarily broad capability. Prefer business-level tools such as get_order(order_id), draft_reply(ticket_id) and request_refund(order_id, amount). Validate identifiers, enums, maximum amounts, tenant ownership, and destination addresses on the server. The model proposes arguments; trusted code authorizes them.

Read tools and write tools should have different permissions. Credentials should be scoped per integration and environment, stored outside prompts, and rotated. Tool responses must also be treated as untrusted input because documents, web pages, and emails can contain instructions intended to redirect the agent.

Keep durable state outside the conversation

Chat history is not a transaction log. Store the workflow identifier, current step, approved inputs, tool attempts, returned identifiers, and final outcome in a database. Give every side-effecting action an idempotency key. If a payment call times out, query its recorded status before trying again; a timeout means the outcome is unknown, not necessarily that nothing happened.

Model context should contain only what the current decision needs. Retrieve authoritative records again before execution so an old conversation cannot overwrite a newer customer choice. Use version numbers or conditional updates when two workers may act on the same object.

Make approval specific and reviewable

An approval screen should show the exact action, target, important fields, expected cost, evidence, and expiry time. “Allow the agent to continue” is too vague. If any material input changes, invalidate the approval. Low-risk steps can proceed automatically while high-impact steps pause, so autonomy is assigned per capability rather than per agent.

Record who approved, what they saw, and what code version executed the action. Redact secrets and sensitive message contents from logs while preserving correlation IDs and decision metadata needed for an incident review.

Evaluate outcomes and failure behavior

Build an evaluation set from real, sanitized cases: ordinary requests, missing information, conflicting instructions, prompt injection, revoked access, retries, and downstream outages. Score task correctness, unsupported claims, tool selection, policy violations, latency, cost, and recovery. A high average score must never conceal a permission bypass or duplicated payment.

Release changes against the same versioned evaluation set and canary a limited share of traffic. A production-ready agent is not one that always acts. It is one that acts inside a clear authority boundary, stops when evidence is insufficient, and leaves enough state for a person to understand and recover the workflow.