What is an AI agent? is the meeting test: goal, tools, steps, and a refusal boundary. This page assumes you passed that test and now want the thing on a roster.
How it actually works
Strip the product names. The loop is short.
- A goal is still true after one prompt (“chase unpaid invoices this week”).
- The host shows the model a list of tools.
- The model calls one. A server runs it. A result comes back.
- The model observes the result and either calls again, stops, or should refuse.
That is the whole machine. MCP is how a tool is allowed to touch the building. HITL is who sits on the irreversible call. Neither is optional once the tool can send, spend, or delete.
Notice what is missing from that loop unless you add it: nothing in step four says when to stop.
First, check you need one
An agent is the expensive answer. It is worth it when the path cannot be known in advance.
If you can draw the steps on a whiteboard before the run, write the script. A script is cheaper, faster, and fails somewhere you can point at. An agentic workflow is not an automation is the longer split.
Use an agent when the branch depends on what a tool returns: which invoices are actually disputed, which of these forty pages is the one with the clause, what to do when the export has a new column. Judgment inside the loop is what you are paying for. If there is no judgment in the loop, you are paying a language model to be a for loop with worse error handling.
One job per agent
Leverage is not “add agents.” Leverage is one worker who cannot wander.
Bad: an agent that reads mail, edits the CRM, posts Slack, and “just handles ops.”
Better: an agent whose purpose is “draft reminder emails for overdue rows in today’s sheet.” Inputs, outputs, and a send that a named person must pass. That is the charter from the definition page, used as a roster card, not as theory.
If you cannot say the job in one sentence that excludes other jobs, you do not have an agent. You have a pile of plugins.
Give the loop a ceiling
An agent with no stop condition does not fail loudly. It fails deep in a retry loop, still spending.
Write four numbers before the first run, and write them where the run can enforce them, not in a doc.
- Max steps. How many model turns before the run halts and asks. Start low enough that you will inspect every halted run. If the job routinely hits the cap, revisit the job boundary.
- Max calls per tool. Especially anything that costs money or sends. “One send per row, ever” is a real constraint you can implement.
- Spend cap. Tokens and any tool that touches an account. Per run and per day.
- Wall-clock. A run that has not finished in its window is not close to finishing. It is stuck.
Then decide what happens on error, because the default is worse than you think. A tool returns a 500, the model reads it as messy input, tries a variation, and now you are in a retry loop that looks like progress from the outside.
The rule that holds: an unfamiliar error stops the run. Retry only error classes you have seen before and decided are safe to retry, and only a fixed number of times. Everything else escalates with the trace attached. You will loosen this later, from evidence, on specific errors. Start closed.
Prefer writes you can take back
Rank every write tool by how hard it is to undo, and buy the reversible version first.
- Draft, not send. The mail sits in a folder. A person presses send.
- Propose, not merge. A pull request, not a push to main.
- Stage, not commit. A row in a review table, not a mutation of the customer record.
- Soft, not hard. A flag, not a delete.
That single design choice moves risk into a place where human review is cheap. It also makes the first ten reviews possible at all; you cannot review a send that already went.
Where irreversible is genuinely required, that is where the named reviewer sits. Not everywhere. A gate on every read creates approval fatigue; reserve it for irreversible steps.
How to optimise it
The model you run this quarter is weather. Optimise the objects that survive a model swap.
Tighten the charter. Purpose, inputs, outputs, authority, success, review, escalation. If success is “be helpful,” you will get send-happy drafts. Write success as something a reviewer can fail: “every draft names the invoice number and the true amount.”
Split standing context from run input. The charter, the refuse-list, and the house facts are versioned standing context; they change on purpose, with a diff. Today’s sheet, today’s rows, today’s window are run input. Mixing run input into standing context is how stale data survives into later runs.
Shrink the tool list. Prefer a read-only server before a write server. Allowlist tools on the host. Do not take “all tools from this server.” MCP explained for founders is the permission page.
Write the refuse-list. Override doctrine is what the agent may never do even when the charter is silent. Start with three categories: money (spend above a ceiling, issue a discount, promise a refund), identity (speak as the company, commit on your behalf, contact a customer unprompted), and irreversibility (change production data, delete, publish). Anything in those three is a refuse or a gate, never a default.
Put a person on the irreversible step. Send, spend, delete, speak. Review the first ten writes in full. Then use the log to decide whether any reversible gate can be relaxed. Irreversible steps remain gated. No log, no write tool.
Read the trace, not the paragraph
A common review failure is grading the English.
Open one run and score the calls, not the prose. Four questions per call:
- Was this tool allowed for this job?
- Were the arguments right, and where did each argument come from? A plausible invoice number the model produced from nothing is a serious failure in this class of system.
- Did the model read the result, or continue past it? Continuing after an error is a failure even when the final output looks fine.
- Did it stop when the charter said stop?
A tidy paragraph that used the wrong invoice is a miss. A blunt draft with the correct number and a clean refusal is a pass. Evaluate reasoning, not fluency is the longer version of this argument.
Keep the failures. Ten real traces where the agent got it wrong form a more relevant regression suite for your system than a generic benchmark. They are the tests that know your data.
Walk one week
Monday: one agent, one sheet, draft-only mail. Step cap set. A named reviewer rejects anything that invents a fee.
Wednesday: read the log. If a call tried to send without a draft step, the permission design is wrong. Fix the host or server controls, not the prompt. A prompt patch on a permission bug lasts until the next model.
Friday: if the drafts are usable and the log is reconstructable, you have leverage. If you “added three more servers” and cannot say who owns send, you have a demo with extra fuses.
The next week is the same agent with one constraint relaxed, on evidence. Not a second agent.
What effective is not
It is not autonomy theatre. An agent that cannot refuse is a fuse.
It is not a bigger context window. More memory without a charter is a longer mood.
It is not a multi-agent graph. Why multi-agent systems fail is next door. Coordination is a different job from connection, and adding a second agent to fix a charter problem gives you two charter problems that now talk to each other.
Put the definition in the meeting. Put this page on the roster. Then give the worker one drawer, a lock on the rest, a number that makes it stop, and a log on the frame.