To build an AI agent for production, decide first whether the task needs one, then give it a short list of typed tools, check every step that changes state against the system it changed, stop after a bounded number of retries, and keep a trace of each run that a person can read. We have built agents this way against a live AWS account, on an executive's desktop, and on our own research pipeline. The AWS agent gave us the rule we start from: nothing in the system depends on the model being correct.
Key facts
Definition
A production AI agent is a loop that observes state, chooses an action, acts through typed tools, reads the result, and repeats until a stopping condition or a person takes over.
How Bigcircle does it
- Bigcircle checks first that the task needs an agent, because a workflow takes the same path on every run and is easier to test.
- Bigcircle gives the agent purpose-built tools with no general shell, keeps credentials in the tool layer, and checks every step that changes state against the system it changed.
- Bigcircle bounds the retries, hands a stuck step to a person with its trace attached, and puts the approval where a reviewer can judge it, such as an architecture diagram on its AWS agent.
Comparison
A tool list written into the prompt worked up to roughly thirty tools on Bigcircle's desktop agent, while a registry the model queries took the same product past a hundred registered tools.
Key number
On Bigcircle's desktop agent, plans completed with no human intervention rose from roughly 55% to 80% once local retrieval and planner memory grounded it in the user's workspace, by Bigcircle's own measurement.
The first decision is the shape of the loop. The table sets five common shapes against the place each one appears in our own work.
| Criterion | Workflow | ReAct | Plan and execute | CodeAct | Computer use |
|---|---|---|---|---|---|
| When it fits | The steps are known and can be written down | The next step depends on what the last one returned | The task can be planned up front and checked before it runs | The work is data or a calculation the model can write code for | The system has a screen and no usable API |
| Main risk | Too rigid when the path is not known | One bad observation carries into every later step | The plan goes stale when the environment changes underneath it | Generated code can reach anything the interpreter can | Slow, and the end state is hard to check |
| How Bigcircle handles this | FinSight runs reconciliation as one governed path with versioned matching rules and no agent loop. Built and tested, not deployed | The Solarpunk agent thinks, acts and observes one step at a time, and a critic decides after each step whether to continue, retry or escalate | Skionis turns a request into a structured spec and an explicit chain of tool calls, and a validation loop checks it before AWS runs anything | Solarpunk does spreadsheet analysis by writing and running code, and hands back a notebook that can be rerun | Solarpunk drives signed-in browser sessions for systems behind SSO with no usable API, and checks the claimed result against the application's own state |
How do you build an AI agent, step by step?
This page gives the short version of each step, with the guide that covers it in full, and the sections below take them in this order:
- Check that the task needs an agent rather than a workflow.
- Pick the model by measuring it on your own cases.
- Give the agent a short list of typed tools, and no shell.
- Keep credentials out of the model's context.
- Check every step that changes state against the system it changed.
- Bound the retries, and hand a stuck step to a person with its trace.
- Put the approval where a reviewer can judge it.
- Add memory, caching or more agents only where each one pays for itself.
Does the task need an AI agent at all?
An agent earns its loop only when the next tool call depends on a result you could not name in advance. Everything else is a workflow, and a workflow is easier to test because every run takes the same path. Agentic workflows vs AI agents gives our test in full.
FinSight, a fund-operations reconciliation system we built, shows what a known path looks like. Each custodian gets its own mapping, and the matching rules are explicit and versioned because they are the domain knowledge. Every break becomes a record that a person resolves. We kept it one governed path because every hand-off through something outside the system is a place the audit trail breaks. When the steps are that well known, they belong in code.
Which model should the agent run on?
Pick the model by measuring it on your own cases, after the eval set exists. The AWS agent's design rule is the reason the choice weighs less than it does in a demo: nothing in the system depends on the model being correct. An engineer then does not have to form an opinion about model quality to decide whether to run it, because every step is checked by a machine or reviewed by a person.
Set the baseline on the most capable model you can use, then try smaller ones where they still meet your accuracy target, because the smaller model is only worth having if the eval says it holds. That only works if the cases exist before the swap, which is why LLM evaluation comes before the model choice. When the model under a live agent changes, LLM model migration covers the retest.
What should the agent be allowed to touch?
Give the agent narrow, typed tools and nothing broader. On Skionis, a DevOps agent that runs against a real AWS account, the action surface is a set of purpose-built tools that wrap the provider's APIs. There is no general shell, and no path by which a plan step becomes an arbitrary API call. The agent also reads the account's quotas, limits and existing resources before it plans, because a template can pass schema validation and still be refused by the account.
A tool list written into the prompt stops scaling early. On Solarpunk, an AI chief of staff that runs on the user's desktop, putting every tool in the system prompt worked until roughly thirty tools. Past that the model began choosing plausible but wrong tools, and nothing in the output showed it. We changed the design so the model is never given the full list of tools. It searches a registry of them and chooses among a handful of relevant tool contracts, and the product now has more than a hundred tools registered.
Treat our thirty as a measurement on one product, not a limit, because overlap between tools matters more than the count. OpenAI's practical guide to building agents gives the same warning with numbers: some systems handle more than 15 distinct tools while others struggle with fewer than 10 that overlap. Measure selection on your own tool list. MCP tools makes the case for fewer, larger tools that do not overlap.
How should an AI agent handle authentication?
Keep credentials out of the model's context, and let the agent act only through tools that hold them. Solarpunk keeps credentials in an encrypted vault on the user's machine and injects them into the tool adapter when the call runs. The agent drives a signed-in session without ever reading a password, and it can act only through systems that were registered for it, so it cannot invent access it was not given.
The same rule protects your own monitoring. If no registered tool reaches the alert path or its configuration, the agent cannot switch it off, whatever the prompt or a tool result tells it. AI agent permissions covers binding each action to a user, a target and an approval, and AI agent security covers what the agent can still reach if it ignores a permission.
Give tools served over MCP the same contract, and check which revision of the protocol your SDK targets. As of October 2026 the current one is the 2026-07-28 revision, which dropped the session a server used to hold open for each client, so a tutorial built around MCP sessions predates it. The token, the check before each call and the audit line are in MCP authorization.
How does the loop check its own work?
Every step that changes state needs a check that does not come from the model. Without one, the agent claims success on work it never finished, and one bad observation carries into every step after it. The loop below is the shape we build, with the permission gate in application code rather than in the prompt.
On Skionis the check is a validation loop of structural and semantic tests that revises the template until the provider will accept it. Most errors are caught there, before AWS is asked to start anything. Template errors before deploy fell from around 10% to 4% across the loop's introduction. That is our internal measurement. On Solarpunk a critic reads the raw result of each step, not a summary of it, and decides whether to continue, retry or escalate.
The critic judges one step at a time, so Solarpunk also compares the agent's claimed completion against the actual state of the target application. That comparison catches work that never took effect. Read AI agent verification for that expected-state check, and score whole runs offline before a change ships, as LLM evaluation covers.
What breaks once it is live?
Once an agent is live, the failures we see are about the environment it works in. On Skionis they are provider and state failures. A change set fails partway, a resource the plan depends on changes after the account was read, or a quota moves between plan and apply. On Solarpunk they are a login that fails, a page that moved since the plan was made, an action the application does not support, or a partial tool result. We file these as failures of the environment rather than of generation, and that is where the retry and escalation design has to point.
Retries need a limit and a place. Skionis retries in two places, inside the validation loop and around execution, because one recovers from a malformed template and the other from a transient or partial provider failure. A template that will not come clean after a bounded number of revisions goes to a person as a request the agent cannot safely fulfil. On Solarpunk an agent that retried forever against a broken vendor would burn cost and time while looking busy. It stops instead, and hands back the unresolved step with its trace attached.
That trace is the record you debug from. On Skionis one record links the request, the account facts, the generated template, every validation failure and revision, the provider's response and the resources created. The validation failures are the part worth keeping, because they are the system's own log of what the model gets wrong. AI agent monitoring splits observability into quality and infrastructure, and AI audit trail covers the record a challenged decision needs.
Where does a person approve?
Put the approval where a reviewer can judge it. On Skionis the human gate is an architecture diagram of the planned change. The alternative was raw template diffs, which engineers do not read carefully at the tenth change of the week. Engineers who had refused to let an agent near production came to let it own routine cloud changes, and the review surface earned that, not the model.
An agent is a budget of autonomy in one practical sense: each action it takes without a person is one a reviewer has agreed to stop checking. The staged rollout in AI agent governance is the method we use to move one. Human in the loop AI agents covers the smallest authority the next release should ask for.
Where do memory, cost and multi-agent designs fit?
Memory moved the only completion rate we have measured on an agent. On Solarpunk, plans completed with no human intervention rose from roughly 55% to 80% once local retrieval and planner memory grounded the agent in the user's own workspace. That is an internal measurement from before and after those two pieces were added. Agent memory that improves the next plan also carries one user's data into it. AI agent memory and a semantic layer for AI cover keying it to the right person.
Repeated work is the cost line we have numbers for. On Prospex, our own prospect research engine, cache-first execution cut repeated external API calls by an estimated 50 to 60 percent. That is an estimate from our own usage rather than a benchmark, and the cache hit rate is the cost metric we watch on it. AI agent cost splits the bill into the build, the run and the keep-alive, with a worked token calculation.
Split work across several agents only when the slices can run without reading each other, or the roles need different tools or authority, because each hand-off is one more place a partial result can read as a finished one. The fit test is in multi-agent systems. Prompt injection travels with the text one agent forwards to another, and prompt injection in multi-agent systems covers re-checking trust at each hop.
Common questions
How do you build an AI agent?#
Check that the task needs an agent rather than a workflow, pick the model on your own eval cases, and give the agent a short list of typed tools with no shell. Keep credentials in the tool layer, check every step that changes state against the system it changed, bound the retries, and put the approval where a reviewer can judge it. Keep a trace of every run.
When should we build an agent instead of a workflow?#
Build a workflow when you can write the steps down, and an agent only when the next tool call depends on a result you could not name in advance. A workflow takes the same path on every run, so it is easier to test and to audit. Bigcircle built the FinSight reconciliation system as one governed path with versioned matching rules for that reason.
What has to sit outside the model?#
Permission checks, credentials, spend limits, the approval for anything you cannot undo, and the alert path that watches the agent. The model may request a tool call, and application code decides whether the call is allowed and whether a person must approve it first. If no registered tool reaches the monitor or its configuration, the agent cannot switch it off.
How do AI agents handle authentication?#
The agent should never hold the credential. On the Bigcircle desktop agent, credentials sit in an encrypted vault on the user's machine and are injected into the tool adapter when a call runs, so the model drives a signed-in session without reading a password. It can act only through systems registered for it, so it cannot invent access it was not given.
How many tools can one agent choose from?#
On the Bigcircle desktop agent, listing every tool in the system prompt worked up to roughly thirty tools. Past that the model began choosing plausible but wrong ones, with no sign of it in the output. Letting the model query a tool registry, and choose from a handful of relevant tools, took the same product past a hundred registered tools. Overlap between tools matters more than the count, so measure selection on your own tools.
How do you know an agent run actually finished?#
Compare what the agent says it did with the actual state of the system it changed, using a read that does not come from the agent. A successful API response is not a finished task. Bigcircle's desktop agent checks its claimed completion against the target application's state, and work it cannot finish comes back as a flagged exception rather than as done.
What is a safe way to give an agent more authority?#
Give the reviewer something they can judge, then widen one action at a time with evidence from the traces. On the Bigcircle AWS agent the approval step is an architecture diagram rather than a template diff. Engineers who had refused the agent came to let it own routine cloud changes. Store the prompt, the tool schemas and the model version with every run so a regression can be traced.
Sources
- OpenAI, A practical guide to building agents, April 2025. The tool-overlap figures.
- Model Context Protocol, 2026-07-28 specification changelog.