Building agentic AI systems: the harness decides what survives production

Key takeaways

• Building agentic AI systems is harness work, not model shopping.
• Less supervision has to be bought with verification.
• Route review by blast radius, not by autonomy level.
• A correct run can still be a costly failure.

An agent is a model plus a harness. The model holds the intelligence, and the system built around it is what turns that intelligence into finished work. That equation, agent equals model plus harness, is the most useful thing you can carry into your next design review. It also has a cost. A harness takes engineering time before it hands back a single hour of autonomy, so a one-off script does not need one.

What breaks between the demo and the first real run

There has always been a gap between a demo and an application people depend on. With generative AI, that gap has widened into a gulf. The demo works because you were watching. The real run happens while you are in a meeting.

Here is the failure that surprises engineers most. In one reported application, the same task fired twenty searches on one run and five on another, with no discernible reason. Tool volume, not just tool choice, turns out to be non-deterministic.

That is one application, so treat it as a pattern to look for in your own logs rather than a rate you can plan against. It is also why we count tool calls per run as its own signal, kept separate from whether the output came back right. The two move independently, and only one of them shows up in a test suite.

Your instinct to read every diff is not conservatism. Language models are non-deterministic, they do not know your project's context, and they operate over tokens rather than understanding. The distrust is structural. You cannot train it away with a better prompt, and you should not want to. What you can do is build the things that make the distrust unnecessary on a given task.

Best practices for building agentic AI systems: the controls and what each removes

Here the controls are surfaces rather than topics, each paired with the failure it takes off the table and a test you can run this afternoon against the agent you already have.

Read that as a set of surfaces we build and test against, not as a validated build order. The rows sit in no particular priority, because priority depends entirely on what your agent can reach. A read-only research agent needs almost none of it. An agent with a shell and your production credentials needs all of it before Friday.

Two of the rows come straight from published guidance. Microsoft's guidance on developing in agentic AI systems treats agent tools, permissions, and MCP servers as things you configure explicitly within the development environment, which is the right instinct even if you never touch that stack. The same guidance argues that separating planning, reasoning, and execution into distinct stages improves reliability and control, and that is the row most teams skip. The rest of the table is ours.

Route by what the agent can break, not by how autonomous it is

Autonomy level is the wrong axis. A sophisticated agent editing a scratch branch is safer than a simple one sending email. Sort by reach instead.

That sorting is possible because reach is something you configure rather than something the model decides. Agent tools, permissions, and MCP servers are set up explicitly in the development environment, which means the tier a task lands in is a line you drew, not a property you inherited.

The three tiers below are our rule. Test them against your own recovery paths before you adopt them.

Reversible and local. A file edit on a branch nobody else has pulled. Let it run. Read the result when you feel like it, because git is your undo.

Shared and recoverable. A change to a branch other people build on, a schema migration with a written-down rollback, a config push to staging. Read the diff before it merges. The recovery path exists but it costs somebody an afternoon.

External and final. A payment, an outbound message to a customer, a deletion in a system with no soft delete. We gate every one of those on a human, and good behaviour last week does not earn an exception.

The tiers are not about trust. They are about what the environment can undo. And this is where reversibility stops being free: once a message leaves your system, no harness on earth pulls it back. That is the boundary you design around rather than through.

A correct run can still be a failed run

We score spend separately from correctness, because a run can be right and still be a failure. A run that produces the right answer after a pile of redundant retrieval loops satisfies every output assertion you wrote. Nothing in the test suite moves. The number lands on the bill instead.

Start from what orchestration actually is. It is control flow. Which parts of the flow the model decides, and which parts you decide in code, is an engineering choice, and handing the decision to the model is usually the expensive one. Separating planning, reasoning, and execution into distinct stages is the standard argument for reliability and control, and it does something else nobody advertises. Once the plan is an artifact, you can price it before you run it.

Two moves follow from that. Both are our own build defaults, and neither one needs a benchmark to justify it.

Move URL and link construction out of the model. A link is a deterministic function of its inputs, so an inference is the wrong tool for it twice over: it costs tokens, and a well-formed result is not the same as a working one. Assemble the string in code from validated parameters and the model never gets the chance to produce one that looks right and resolves to nothing.

Move fixed-format lookups out too. If a lookup is a deterministic function of an ID, write the function. Every lookup you hand to the model is another chance to pay tokens for a plausible answer you then have to verify.

Neither move will tell you whether you have the problem in the first place. The tests in the table above will.

One agent is the right default until the work genuinely splits

When we start building agentic systems, we default to one agent and split only under pressure. A single agent is simpler and cheaper, and simplicity is the only debugging advantage you get for free.

Three conditions justify a second agent. The work spans genuinely different domains. It needs real parallelism, not the appearance of it. Or it requires specialized knowledge one agent cannot hold in context at once. If you cannot point at one of those, you are buying coordination cost for nothing. Every agent you add is another non-deterministic node in a distributed system, and the quality you expect from specialization stays theoretical until you measure it, while the coordination cost arrives the day you ship.

That is an argument against reaching for multi-agent first, not against multi-agent. Two harness capabilities are exactly where the split earns its keep: planning tools that let an agent decompose an objective and track progress as it learns, and parallel delegation to subagents that each hold isolated context. On a long task with independent branches, that structure genuinely helps. It just is not where you start, which is the whole argument of our longer piece on agent orchestration tools.

Steering is the job that replaces writing the code

The strongest published account of what this looks like at full tilt comes from an engineering team that spent five months building and shipping an internal beta of a software product with zero lines of manually written code. They estimate it took roughly a tenth of the time hand-coding would have taken, under one explicit rule: humans steer, agents execute. Read that figure as what it is. It is one team's self-reported estimate, from one project, under a constraint they chose on purpose to force the tooling into existence, and nothing in it establishes that a tenth of the time is available to a team that has not already built that tooling.

So do not put it in a roadmap. If you are staffed to ship next week rather than to build tooling for five months, this is not yet a plan you can follow, and treating it as one is how a quarter disappears. It is a demonstration of what the split makes possible, not a benchmark to plan against.

What it does settle is the shape of the job. If you are asking what the core capabilities of agentic AI systems are, the honest answer is that most of them are not in the model. They belong to the environment: bounded tool access, a readable plan, progress the agent can track, isolated context for parallel work, and a verification step before anything ships. That list is also the practical answer to how to build an AI system you can leave alone for an hour. The model supplies judgment inside those walls. You supply the walls. That shift from authoring to steering is the one we work through in agentic engineering versus vibe coding.

How you know it works before you loosen the leash

Evaluating agents has grown into its own practice, with recognized best practices and recurring patterns.

Here is what we score, and it is not just the output. It is the trajectory: which tools the agent chose, how it recovered from a failed call, whether it retried sensibly, and whether it knew when to stop. Two runs can reach the same correct output and deserve very different scores.

That matters because evals are the currency you pay for autonomy. Less supervision has to be bought with mechanisms that raise confidence in the result, and a trajectory eval is the one we build first.

It is also the easiest one to fake. An eval you cannot tie to a specific failure is theatre with a dashboard, and building trajectory fixtures costs real engineering time you could have spent on a permission boundary instead. So calibrate against your own blast radius rather than against whatever the field is doing. Start with the tasks you already refuse to leave alone.

Where this argument runs out

Two fair objections.

The first: does a framework do this for me? Choosing between raw Python and a framework changes who writes the control flow, not whether you need one. A framework gives you retries, state, and a topology. What it does not give you is the reliability property that comes from separating planning, reasoning, and execution against your own actions, because it does not know which of your actions are reversible. That mapping is your domain knowledge and it stays your job.

The second: is review the bottleneck to remove rather than the control to keep? Engineers disagree on that, and this page does not settle it. Take the blast-radius rule as our position rather than the answer. Review is not a fixed tax you pay on all agent output, and it is not something you graduate out of. It is a per-action decision about what the environment can undo. That position is untested against the thing that made it necessary: the gulf between a demo and a dependable application is exactly where a rule this simple could turn out to be too simple. If you have never had to reconstruct what an agent did after the fact, the rule will read as pure overhead, and you should not adopt it on our say-so. Run it against one job you would hate to lose. If your recovery path is genuinely instant and complete, review less. If it is a support ticket, review more.

Where to start this week, and where Rifty fits

Ask how to build agentic AI systems and you get a topic list. Ask how to make an agentic AI system you can actually leave running, and the answer starts with what your agent can reach today. Pick the line that matches.

If it is read-only, do almost nothing structural. Add a tool budget and compare repeat runs of the same task. That is the whole first sprint.

If it has repo write access, enumerate its tools and cut the list to what you can name and justify. Then make the plan a readable artifact before execution, so a wrong inference costs you a glance instead of a revert.

If it has external side effects, put a sign-off gate in front of every action that leaves your system before you improve anything else. Then work backwards to the plan and the budget.

Rifty builds one thing: harnesses for operators running agents across companies, designed so the system is legible, steerable, and reversible at every step by default. The bet behind it is that leverage means carrying your judgment forward intact, not generating more output for you to review. If you are running agents across more than one company and the reversibility question is the one keeping you up, request an introduction.

If you want maximum unattended throughput and you are comfortable with irreversible actions, a reversibility-first harness will feel slow, and you should build the other thing. Either way, take the control table to the agent you already have and run the six tests. You will know within a day which row you are missing. Our research on autonomous AI agents picks up from there.