How to build production AI agents

An AI agent is not a model with a better prompt, it is a loop in which the model observes state, decides what to do, acts through tools, reads the result, and repeats until it reaches a stopping condition. That loop is powerful because it can adapt when the path is unknown. Bigcircle builds these loops on client systems, where the open question is how much of that path the model is allowed to choose.

It is dangerous for exactly the same reason, so the practical question is not "can we make it autonomous?" but "which decisions should the model make, which decisions should code make, and where do humans approve risk?" Useful agents are controlled loops around tool calling, memory, plans, permissions, evals, and observability.

What makes something an agent

An AI agent chooses the next action from what it just observed, while a workflow follows steps the code already listed. That choice is why agents cost more, fail along longer trajectories, and need tighter controls. You need a model that selects actions, tools that perform them, a loop that returns each result, and a stopping rule for success, failure, budget, timeout, or a human handoff.

Use a workflow when the steps are known, and use an agent when the task path has to be discovered. Invoice extraction, support triage, and document classification are usually workflows. Debugging a failing integration, investigating a metrics anomaly, or reconciling a messy data room can be agent-shaped, which is when tool calling becomes the way the model acts. When not to build an AI agent is the test for whether you need that loop, a retrieval app, or the workflow you can already write down.

The loop: observe, reason, act, verify

The production agent loop is observe, reason, act, and verify, and each turn that can change state has to finish the set. Observation brings ground truth in from files, traces, API responses, browser state, or database rows, and reasoning selects the next move from that evidence. The action changes state through a tool, and verification checks the result before the loop treats the step as progress.

Verification is the part demos skip, and the part production cannot. A coding agent can run tests, a data agent can compare row counts, a browser agent can inspect the page, and a support agent can check whether the answer cites permitted evidence. Without verification an agent is just a model taking repeated guesses.

Tool calling is the contract

Tool calling is the contract between an AI agent and any system it can change. The schema says what the model may request, and the application decides whether that request is valid, allowed, and safe to execute. Good tools are narrow and typed, and they return structured results the loop can use. A broad escape hatch, such as open SQL, email, a shell, or a browser with no scope, skips that contract.

refund_payment should require an account id, amount, reason code, and idempotency key. It should enforce policy outside the model, and it should return structured results the agent can use. That is tool calling as an API, not as decoration on the prompt. Bad tools are broad escape hatches: run_sql, send_email, execute_command, or use_browser without scopes, dry-run modes, or approval gates.

MCP matters because it standardizes how tools are exposed to agents. Standardization helps integration, but it does not decide permissions for you. A dangerous tool remains dangerous when served through a standard protocol.

ReAct, CodeAct, and plan-and-execute

Agent patterns are ways to manage the same loop, chosen by how much of the path is already known. A workflow fits a fixed sequence, and ReAct keeps each decision next to a fresh observation. Plan and execute helps on work with milestones, provided the plan is revised when evidence changes. CodeAct fits data and automation. Computer use is the fallback when the software exposes only a screen.

The ReAct pattern is the default because it keeps reasoning close to observation. Plan and execute helps when the task needs decomposition, but plans should be revised as evidence arrives. CodeAct is powerful when the agent can write small programs to inspect data or automate work. Computer use is the last resort for systems that only expose a graphical interface.

Memory and context engineering

Agent memory is several stores, and they should not share one context window. A run needs short-term scratch space, a task needs a record of files, tickets, and rejected guesses, and a user or a company needs longer memory with its own privacy, freshness, and retrieval rules. Pouring all three into the prompt raises cost, adds distraction, and can bring stale instructions back into force.

Agent memory should also be inspectable by the people who operate it. If an agent remembers a user preference, operators should know where it came from and how to delete it. If it stores a lesson from a failed run, the next run should see the evidence, not just a vague summary.

Permissions, prompt injection, and tool safety

Prompt injection becomes a production failure when an AI agent pairs untrusted text with tools that can act. A malicious page can ask a browser agent for secrets, a ticket can tell a support agent to ignore policy, and hidden text in a document can try to replace the task. The control has to sit in the application, so it still holds when the model goes along with the injected text.

• Give tools least privilege, and separate read tools from write tools.
• Require human approval for irreversible actions, and offer dry-run modes for the rest.
• Scope credentials to the task, and run risky tools in sandboxes.
• Never let retrieved or browsed text become authority over system policy.

The model can help classify risk, and the application must still enforce it. Guardrails against prompt injection belong in code. If a tool would delete data, move money, send external email, or change production configuration, the permission boundary should sit outside the model.

Multi-agent systems

Multi-agent orchestration pays off when the roles need different tools, different permissions, or different tests. One agent can research while another writes, reviews, or runs checks, and those jobs should not share one authority. More agents also mean more handoffs, more duplicated reasoning, and more chances for a partial error to sound like a finished recommendation. Split the system when the authority should differ, and keep one instrumented loop when it should not.

Use multi-agent orchestration when roles have different tools, permissions, or evaluation criteria. A security reviewer and a coding agent should not share the same authority. A researcher and a writer may benefit from separate context, but do not split a task just because it sounds sophisticated. A single well-instrumented loop is easier to debug.

Observability and evals

Observability lets you replay an AI agent instead of guessing why a run went wrong. Each trace should hold the prompt, the model output, every tool call and result, retries, approvals, cost, latency, and the signal from the verifier. Durable run state belongs in the same record, so a long task can resume without losing the context it already paid for, and so you can see which step to fix.

Agent evals, read from that observability trace, should score trajectories rather than just final answers: did the agent choose safe tools, did it recover after a failed action? Did it ask for approval at the right time, and did it stop when evidence was insufficient? Those are all behavioral properties of the loop rather than of the answer.

Start with offline evals built from real tasks, capturing a successful human path and then letting the agent attempt the same goal in a sandbox. Score whether it reached the goal, how many steps it used, which tools it called, whether it violated policy, and whether its final output can be verified. The trace matters more than the final text because the trace tells you where the loop broke.

Then add online monitors, watching tool error rates, approval rates, timeout rates, cost per completed task, user intervention rate and rollback rate. An agent that completes 80 percent of tasks but needs expensive human cleanup on 20 percent may be worse than a workflow that completes 60 percent cleanly and escalates the rest.

Human handoffs and stopping rules

Stopping rules belong in the agent design, covering success, uncertainty, missing permission or evidence, tool failure, a spent budget, and risk a person has to accept. Without that rule the loop will eventually take an expensive step just to keep going. The handoff should show the goal, the plan, the actions already taken, the evidence, the current hypothesis, and the proposed next action. A note that only says the agent needs help wastes the reviewer.

A structured handoff turns the reviewer into a verifier and gives the team a case for the next eval. A system that always tries one more step will eventually do something expensive or unsafe, which is the failure the stopping rule is there to prevent.

Approval design should match the consequence of the action. Low-risk reversible changes can be auto-applied with logs, medium-risk changes can require review after a dry run, and high-risk actions require approval before execution. Some actions should never be exposed to the model at all. That is not a lack of ambition, it is how reliable automation survives contact with production systems.

Rollout strategy

Roll an AI agent out as shadow, then assist, then act, and require evidence before each promotion. Shadow mode watches real tasks and proposes actions without running them. Assist mode lets a person accept or reject those proposals. Act mode executes inside a narrow permission boundary and escalates everything outside it.

Each stage should have exit criteria of its own before the next one opens. Shadow mode should prove the agent can identify the right next action. Assist mode should prove users accept its proposals and corrections are declining. Act mode should start with reversible tasks, small accounts, or internal users. Expanding scope should require evidence, not optimism.

Versioning matters too, because prompts, tools, model versions, memory policies and guardrails all change behavior. Store every one of them with each run, because when a regression appears you need to know whether it came from a new model, a changed tool schema, a memory retrieval update, or a prompt edit. Do not roll out all tools at once.

Start with read-only tools, then reversible writes, then narrowly scoped irreversible actions after the agent has earned trust. Each new tool should come with a schema, examples, permission rules, dry-run behavior when possible, and eval cases for misuse. The tool surface is the agent's real product surface, and expanding it casually is how a helpful assistant becomes an unreliable operator.

Cost rollout needs the same discipline, because long agent runs can burn tokens through repeated observations, large tool outputs and verbose self-reflection. Set per-run budgets by task class, summarize large observations before placing them back into context, and keep raw artifacts available through tools instead of pasting everything into the prompt. An agent that is reliable but economically unbounded will still fail as a product.

Production takeaways

Build the workflow first, and promote to an AI agent only when the path cannot be scripted.

• Make tools narrow and typed, and put permission checks outside the model.
• Use guardrails that constrain actions, not just language.
• Treat agent memory as data with provenance.
• Trace every step through observability.
• Use multi-agent orchestration only when roles and permissions justify it.

An agent is a budget of autonomy, so spend it where adaptation is worth the cost and make every loop prove what it did.

Common questions

When should we build an agent instead of a workflow?#

Build a workflow when you can write the steps down, such as classify, retrieve, draft, and send, and build an agent when the path has to be discovered, such as debugging an integration or investigating a metrics anomaly. Agents can adapt, and they also cost more, fail over longer trajectories, and need stronger permissions, evals, and logs. When that path is already written down, leave it in code.

What has to sit outside the model?#

Permission checks, spend limits, and anything you cannot undo sit outside the model, even though the model may request the tool call. Application code decides whether that call is allowed, whether a dry run is required, and whether a person must approve it before it runs. A protocol that standardizes how tools are exposed does not make a broad tool safe.

How should agent memory be stored?#

Keep scratch state for the current run, task state, and longer user or company memory in separate stores, because each has different privacy, freshness, and retrieval needs. Summarize observations, pin the facts that must persist, and retrieve only what the current step needs, rather than pasting every store into the prompt. If the system remembers a preference, an operator should be able to see where it came from and delete it.

How do you know an agent run actually finished?#

Check an expected state outside the model's own claim, such as tests that pass, row counts that match, a page that shows the change, or an answer that cites evidence the policy allows. Score the trace as well as the final text: which tools ran, whether a failed step was recovered, whether approval happened at the right time, and whether the agent stopped when the evidence was missing.

What is a safe way to give an agent more authority?#

Move through shadow, assist, and then act, and require evidence before each step. In shadow the agent proposes and does not execute. In assist a person accepts or rejects, and act starts on reversible work, a small scope, or internal users. Store the prompt, the tool schemas, the model version, and the guardrails with every run, so a regression can be traced to the change that caused it. Add tools one at a time. Start with read-only tools until the traces look right.