How we build AI agents that actually work in production

Every week someone shows off an AI agent doing something that looks impossible. Booking travel, fixing a codebase, running a whole sales workflow with nobody touching it. And every week a founder forwards us the video and asks for "something like that."

The thing they don't see is that the video is the easy part. Getting an agent to look impressive once is not hard. Getting one reliable enough that you'd let it near a real customer or a production database is a different job entirely, and it's where most of these projects fall apart.

So here's what an agent actually is, why they break, and what we do differently.

What an "AI agent" really is

Underneath the marketing, an agent is three things bolted together.

There's a language model that decides what to do next. There are tools it can call to do actual work — read from a database, send an email, hit some API. And there's a loop that lets it act, look at what happened, and decide again instead of answering once and stopping.

That loop is the whole game. A chatbot replies. An agent chases a goal: take a step, check the result, take another, until it's done or it gives up.

The loop, minus the mystique

Underneath the buzzwords, the core of almost every agent is a loop that looks like this:

async function runAgent(goal: string) {
const history = [systemPrompt, userGoal(goal)];

for (let step = 0; step < MAX_STEPS; step++) {
// 1. Model decides: respond, or call a tool?
const decision = await llm.complete(history, { tools });

if (decision.type === "final") {
return decision.answer; // goal reached
}

// 2. Run the tool the model asked for
const result = await tools.run(decision.toolCall);

// 3. Feed the result back in, and loop
history.push(decision, toolResult(result));
}

throw new Error("Agent hit step limit without finishing");
}

Planning, memory, RAG, multi-agent setups — it's all variations on this. Once you've seen it, "agentic AI" stops being magic and turns into a normal engineering problem. Which is good news, because engineering problems fail in predictable ways.

Why most agents break in production

The demo works because the demo is forgiving. Production isn't. Here's where they fail:

1. Reliability compounds the wrong way. If each step is 95% reliable, a ten-step task is only about 60% reliable end to end. Agents that take many steps are exponentially fragile unless you engineer against it.
2. Unbounded actions are dangerous. A model that can call delete_records() or send_email() will eventually call it at the wrong time. Without guardrails, one hallucination becomes a real-world incident.
3. Cost and latency spiral. Every loop step is another model call. A task that takes fifteen steps is fifteen times the cost and the wait of a single response — and users feel every second.
4. No evaluation = no idea if it works. Most teams "test" an agent by trying it a few times and eyeballing the output. That's not testing. When you change a prompt, you have no way of knowing what you broke.

How we build agents that hold up

The patterns below are what move an agent from "cool demo" to "you can put it in front of a customer":

• Narrow the job. The most reliable agents do one thing well, not everything badly. We scope an agent to a specific workflow with a clear definition of "done" — then let it be excellent at that.
• Design tools like APIs, not magic. Each tool gets validated inputs, predictable outputs, and clear error messages the model can recover from. Good tool design does more for reliability than any prompt trick.
• Put guardrails on consequential actions. Anything irreversible — payments, deletes, outbound messages — runs behind validation, rate limits, and often a human-in-the-loop approval step. The agent proposes; a guardrail decides.
• Build evals from day one. We assemble a test set of real tasks and score the agent automatically on every change, so we catch regressions before users do.
• Make it observable. Every step — every tool call, every decision — is logged and traceable. When something goes wrong in production, you can see exactly which step did it instead of guessing.

A reliable agent isn't a smarter model. It's a smaller job, better tools, and the guardrails to fail safely.

Single agent or multi-agent?

"Multi-agent" is having a moment, but more agents usually means more ways to fail. Our rule of thumb:

• Use a single agent when the task is one coherent workflow. It's simpler, cheaper, and easier to debug, start here.
• Use multiple agents only when the work genuinely splits into independent specialties (e.g. one agent researches, another writes, a third reviews) and the coordination cost is worth it.

Most problems that look like they need a team of agents are better solved by one well-scoped agent with good tools.

When you don't need an agent at all

We'll say the unpopular thing: a lot of "AI agent" requests are just automation.

If the workflow is the same steps every time, you don't need a model deciding anything. A plain pipeline is cheaper, faster, and far more reliable. We only bring in an agent when the work needs judgment you can't write down in advance.

Knowing which is which is most of the value. It's the difference between something that works every time and something expensive that works most of the time.

If you've got a workflow you think an agent could take over, or you're not sure whether it needs an agent, basic automation, or something else entirely — that's the conversation we like. Tell us what you're trying to automate and we'll tell you what it really takes to make it hold up.