TL;DR
Your agent harness architecture is a bundle of eight decisions, and most teams made all eight by default rather than on purpose. Four of them break first: control, context, the permission boundary, and evaluation. Walk your own setup through the eight and you come out with a named weak point. Since May, buying a harness became a real option, and sometimes renting is the right engineering call.
The harness you never designed
One of your agents burned a day's token budget in twelve minutes last month. Another one is still not allowed to run unattended, because nobody could reconstruct what it had done if it went wrong. A third shipped a change on Tuesday that the team believes is better and cannot prove.
So the conversation turns to the model. It always turns to the model.
Ask instead who set the iteration cap. Who chose what leaves the context window when it fills. Who decided the agent would run on a developer's own credentials, and who can show, six weeks later, which files it wrote.
You will get a shrug, or a tutorial somebody followed in March. Neither one was a decision, and both are load-bearing now.
The agent harness architecture you are running was inherited, not chosen.
A source-code audit of eleven production coding harnesses put the shape of it plainly. Most of the mass in those systems addresses concerns orthogonal to task completion: safety, user experience, extensibility. The task is the small part. Everything wrapped around the task is the system.
That matches what I find on every build I get called into. The harness is the single highest point of leverage in an agentic system. The model is not, and it stopped being the interesting question a while ago.
Agentic AI architecture sounds like something you draw. It is something you decide, eight times.
Each of those eight has a place it lands when nobody decides it. The tutorial decides, or the vendor default decides, and the result holds up fine at demo volume. Then the volume arrives, and each default fails in its own particular way: the budget, the trust, the change nobody can prove.
Your setup made all eight of those decisions. Four of them are where the damage is, and they are not the four anybody argues about.
The AI harness layers you inherited are eight decisions
You cannot audit what nobody has described. So start with what a harness actually is.
A harness is the software around the model. The model is an engine: it turns an input into a plausible next output and then it stops.
The harness is the car. It decides when to call the engine again, what information to hand it, and which tools it may touch.
It also decides what the agent may do without asking, when to stop, and what gets written down afterwards.
None of that is a model capability. All of it is engineering, and all of it is yours even when you are renting it. The long version of that argument is in what an AI harness is.
Two studies have now looked at real code rather than at principle. Hu Wei's single-author preprint reads seventy agent-system codebases and maps five recurring design dimensions: subagents, context, tools, safety and orchestration. Barbaste and colleagues audited the source of eleven production harnesses, Claude Code, Codex CLI, Gemini CLI, OpenHands and Aider among them, mapping seven canonical subsystems and finding an enormous spread between the minimal and maximal version of each.
Five dimensions. Seven subsystems. Neither count is wrong, and neither is a settled taxonomy.
Read from the outside, both are describing a set of agent harness design decisions. Eight recur often enough to audit, and the AI harness layers your system already has are those eight with an answer filled in. Each one has a default, and each default has a characteristic failure that only arrives with volume.
Your agent harness architecture is the column of answers you already have.
| The decision | Where it lands when nobody decides | What that default costs in production |
|---|---|---|
| Control | No iteration cap, no spend ceiling, retry on failure | One run takes the month's budget before a dashboard shows it |
| Permission and isolation | Same process, on a developer's own credentials | Nothing can be reconstructed afterwards, so it never gets unattended work |
| Evaluation | A human reads the output and it looks fine | No change can be proven safe, so the system freezes or regresses unnoticed |
| Context management | Append everything, truncate at the limit | The instruction that matters leaves the window, and behaviour changes with no code change |
| The agent loop | Whatever the tutorial's while-loop did | The loop runs past the point where the task was done, or recoverable |
| The tool interface | Functions hand-wired one at a time | Every integration is a code change, and the tool list outgrows what the model picks from |
| Persistence | Nothing, or a transcript file | The agent re-derives the same context every run and cannot be resumed or audited |
| Orchestration | One agent with more tools bolted on | That agent's context and permissions become the union of every job it does |
Four of those rows carry most of the failures. The other four are no less real: state persistence across sessions is the difference between an agent that resumes and one that starts from nothing every morning.
Note what neither study examined. Neither one measured control. Neither one measured evaluation.
The rows are in failure order rather than taxonomy order. Control comes first because control is the one that bills.
Control: the decision with no study behind it
Control sits first on that list, and the two studies behind the record skip it entirely. It fails fastest because an agent without a ceiling does not degrade. It bills.
On 10 July 2026 a developer's interface-validation prompt in Codex spawned a cascade of child tasks from a single root task. The run escalated itself across model tiers. It ended in a bill of $79,664.88.
Two things were absent, and neither is exotic. A limit on how many children one task could spawn, and metering the operator could see while it ran.
An unbounded loop is a decision nobody made.
The deliberate version of this decision can be very small. At the minimal end of the eleven audited harnesses, a cost limit and a step limit are the entire safety mechanism. Minimal is still deliberate: a number, written down, in a place where it fires.
Nobody can hand you the number. It is yours, and it comes out of your own baseline. Take the task the agent already does well. Measure what a normal run costs in steps and in tokens, find the worst normal run in the last month, and set the ceiling above that.
Then decide what happens when it fires, because it will fire on a legitimate run eventually.
That is the part teams skip. A cap with no handler is a dead end with a user on the other side of it. A cap with a handler is a queued retry, an alert, and somebody looking at a trace in the morning.
Price both sides before you argue about the cap. A cap that fires wrongly costs you a failed run, a confused user, and ten minutes of an engineer's afternoon. The absence of a cap costs whatever the agent can reach before someone notices, and that number is not bounded by anything in your system.
Almost nobody sets the cap wrong. They just never set one.
Context management for AI agents is where the default hides
At least you can point at a cap in a config file. Context management for AI agents is the opposite case: the best-evidenced decision in the record, and the hardest one to see in a running system.
Hu Wei's seventy projects split three ways and never reach a majority. Hybrid strategies come in at 27.1%, file persistence at 22.9%, hierarchical approaches at 17.1%. The eleven-system audit finds memory and context implemented across the same enormous range, from almost nothing to deeply engineered.
There is no dominant strategy. Nobody has earned the right to tell you to copy theirs.
The default, meanwhile, is append and truncate. Every turn goes in, and when the window fills the oldest text falls off the end.
Nothing errors. Nothing logs. The line that said never write to production is three thousand tokens back, and now it is gone.
The agent did not change its behaviour. Its instructions changed underneath it.
That is what makes it expensive to find. No deploy to roll back, no diff to read: the code is identical to the version that worked last month. Context compaction is the usual answer: summarise what has happened and carry the summary forward instead of the transcript. It buys room by trading fidelity, and the detail it drops is the one nobody knew was load-bearing.
Start small on the knowledge side of this. You do not always need retrieval, a cache-augmented setup, or a vault full of notes. Plenty of systems I have built started with the relevant documents in the prompt and grew from there. What I would not skip is designing for knowledge adapters from day one, so the retrieval layer can be replaced without touching the agent.
The cache layer belongs in the same conversation. It is one of the cheapest performance levers I know, on one condition: the use case has to tolerate a cached output. Where it does, you pay for an answer once and serve it many times. Where it does not, a cache is a correctness bug with good latency.
What each strategy costs is knowable.
- Truncation: free and loses the oldest thing.
- Summarisation: keeps the shape and loses the specifics.
- File persistence: keeps everything and makes the agent go and fetch it, at the cost of a step and a tool call.
- Hierarchy: keeps the important things close and requires you to say what important means.
Your workload decides that, and nobody else's distribution does. What all four leave behind is a window whose exact contents nobody can reconstruct afterwards.
The permission boundary you cannot prove
Then somebody asks what the agent actually did. On Monday that gap was a context problem. By the time the question arrives it is an evidence problem, and this decision settles whether you can answer it.
The starkest number in the cross-project record is a gap. Across Hu Wei's seventy projects, 45% isolate the agent at the process level and 31% run it in a container. Just 5% carry tamper-evident audit logging.
Nine to one. Nine projects bother to contain what an agent can touch for every one that can prove afterwards what it touched.
Sandboxing and permission boundaries are the half teams actually make. The failure they prevent is easy to picture: the agent runs the destructive command and the container absorbs it. The other half has no picture, so it gets skipped.
The default has two forms and both are tired rather than reckless. The agent runs in the same process as the application, on credentials that belong to a named person. And it got write access to the whole store because enumerating the six things it genuinely needed would have taken an afternoon. Read and write on everything took four minutes.
That second one is the decision most teams would recognise in their own repository. It is also the hardest to walk back, once four other things depend on the wide grant.
You can rebuild a sandbox in a sprint. You cannot reconstruct a log you never wrote.
The audit half is what decides whether the agent is ever allowed to work alone. Somebody outside your team eventually asks: an auditor, a client's security reviewer, a customer who wants to know why a decision went the way it did. The answer has to be a record with a retention window behind it. An engineer's recollection and a log that rotated out in August will not do.
An agent nobody can account for stays on a human leash forever, and never pays for itself.
There is also the case where the agent's reach changes how people are measured at work. Then the people being measured get a say, through a body that has to agree before anything ships. That is a date in the plan, and it belongs in the design rather than the week before launch.
The deliberate version is expensive and the audited systems show how much. The maximal one runs four layers: an execution policy, lifecycle hooks, a model-driven approval reviewer, and native operating-system sandboxing across three platforms.
That is the work. It is also the only reason anyone lets it run unattended.
Evaluation is an architecture decision, not QA
Run that same test forwards. Can anybody on the team show a change to the agent is safe before it ships?
Evals and monitoring are not optional, and you do not want to learn that the way I have watched teams learn it. A prompt change goes out on a Thursday. Three weeks later a customer complaint surfaces a quality drop, and by then eleven other things have changed. Nobody can say which one did it, so the team reverts the whole month and loses the four improvements along with the regression.
Evaluation is the one decision in an agent harness architecture that governs whether the other seven can ever be changed again. Without a score, every edit to the loop, the context strategy or the tool list is a guess with a deploy attached.
A harness with no eval set is finished. Nothing more will be done to it.
An eval set and scored regression is less exotic than it sounds. It is a fixed set of real inputs, the outputs you already agreed were good, and a number you can compare against last week's. It runs on every change. It does not need a person to read the results.
The gap here is normal rather than exceptional, and LangChain's practitioner survey puts numbers on it.
The one that matters: 29.5% run no evaluations at all, and among organisations with agents already live that only falls to 22.8%.
They are all still operating. That is the trap in this decision, and it is why it gets deferred: a missing eval set produces no incident, no alert, and no bill. It produces a system that slowly stops being touched.
The eval set is what makes every other decision in the harness reversible.
Agent harness vs agent framework: what the code says
So what is the thing you are keeping reversible? Agent harness vs agent framework is the contested answer now, and the vendors got there first with the tidy version.
TrueFoundry puts it in a line: frameworks are for building agents, harnesses are for running them. Arize AI reads the same split as a move in where engineering effort goes. It calls the harness the real product surface now that the work is loops, tools, traces and evals. Both companies sell runtime infrastructure, which is worth holding in mind when a distinction arrives that clean.
The empirical version is stronger anyway. Of the eleven production harnesses in the source-code audit, not one imports a general-purpose agentic framework. Not LangChain, not AutoGen, not CrewAI. Every one of them runs a hand-rolled agent loop.
The same study states the line independently of any vendor. A framework is a library the developer imports to build an agent; a harness is a runtime the developer works inside of.
That is the sentence to carry into your next architecture review. A framework is a library you import. A harness is a runtime you work inside.
The counterweight comes from the people reading the code rather than selling against it. The seventy-project read never claims the term as a formal category.
Both of those hold at once. The label is loose and the thing underneath it is concrete: either you write the control flow or you configure somebody else's.
The distinction earns its keep in one place. It tells you what you own when the agent misbehaves. Import a library and the loop is yours to debug at two in the morning. Work inside a runtime and the loop is somebody's product, with a version number, a changelog and a support queue.
What changed in agent harness architecture
Five months on, that distinction decides more than it used to. Four things changed, and two of them overturn what we recommended at the time.
Start with the number the original argument rested on. In May it was a wide scaffold gap reported by one of the creators of CORE-Bench, a coding-agent benchmark scored per scaffold rather than per model. Princeton's own Holistic Agent Leaderboard now declares that benchmark solved for the Claude Code scaffold, and has paused updates. A follow-up from several of the same authors, published on 23 June 2026, widened the grading and found the two scaffolds level.
The gap is gone, and what replaced it is harder to put on a slide. The scaffolds still disagree task by task, and a router that always picked the better one per task would beat both. Harness choice still decides outcomes. It stopped arriving as one headline number and started showing up as per-task variance.
MCP's governance moved and its adoption did not. Anthropic donated the protocol to a Linux Foundation directed fund. On 28 July 2026 its maintainers shipped the largest change since authorization: the protocol went stateless, sampling and roots were deprecated, and Tasks moved to an optional extension.
Adoption is a separate story. MCP-first tool systems are a minority of Hu Wei's corpus, and registry-based ones run well ahead of them. The eleven-system audit treats MCP as one extensibility mechanism among config, hooks, skills and plugins rather than the load-bearing one. MCP and tool registries are not the same bet, and the registry is still the bet most production systems have made.
A platform vendor then turned the word into a product. On 11 September 2026 Salesforce announced a Trusted Enterprise AI Harness. It bundles six capabilities plus an AI Control Plane for watching agent performance and inference cost across an organisation. The rollout is still ahead of it.
TrueFoundry and Arize, neither of them a framework vendor, now publish harness-versus-framework material to sell runtime infrastructure. In May, harness was a word practitioners used with each other.
The fourth change I noticed in my own calendar. I used to clear a week when a frontier model shipped. Now a launch is a configuration change and an eval run, and the harness around it absorbs the difference. The improvements I see between releases are smaller than they were at the start, and the fear of waking up obsolete went with them.
One corner of that is worth saying out loud. You do not need a frontier model for everything, and when a smaller one is the better call is a decision with its own arithmetic.
Buy, assemble, or own: one condition decides it
Something appeared on the shelf that had not existed before. That reopens a decision rather than answering one. In May the choice was two-way: rent an interface, or build the thing behind it. There is now a middle option, and at the top end there is a product with a delivery date attached.
One condition sorts all three. Is the agent's own behaviour your product?
Own it when the behaviour is the product. Every one of the eleven audited harnesses is a system whose agent behaviour is what its makers sell. Every one runs its own loop instead of importing somebody's framework.
That is not tribal preference. When the way your agent retries, recovers, asks and stops is the thing customers pay for, you cannot buy it. Buying it means shipping your competitor's judgement with your name on it.
Buy it when the behaviour is not the product. Most business automation sits here.
An agent that reconciles invoices, triages a support queue or drafts a first reply has a job with a right answer. Nobody chooses your company for how gracefully it recovers from a timeout. Rent the runtime, configure it, and spend your engineering on the process it runs instead.
No hedge on that one. If you are automating your own back office, you should probably not be building a harness.
That is the decision maturing rather than anyone going soft on ownership. In May there was nothing credible to buy. Now there is a named enterprise product with a rollout horizon, and the vendors selling runtime infrastructure have organised their marketing around exactly this comparison. A real option appeared where there had been a gap.
Assemble when the behaviour matters in two or three places and nowhere else. This is the common middle and the one teams talk themselves out of. You want your own control over the loop and the permission boundary, and you have no interest in writing a tool registry or a trace viewer. So you take the parts, wire the loop yourself, and keep the decisions that matter in your own repository.
You should be able to say which of the three you are in one sentence, with the condition in it. A team that cannot say it has a gap upstream of the architecture.
Start with one process, not a rebuild
One sentence settles that choice. The eight rows are less tidy, and you may come away from them with four problems.
Fix one.
A team that finds four broken defaults on a Friday does not need a replatform. It needs the one that is costing it most, fixed properly, and the other three written down with a date against each.
The same holds if you have no agent running yet. You do not have to automate the whole company at once. Pick a single process, however small, that solves a problem the business actually has.
The report somebody rebuilds every Monday morning. The inbox that gets sorted by hand. The three systems a person copies between all day.
Build that one with a cap, a boundary, a record and a scored set. Then join it to the next one.
Waiting is the expensive part. I have watched companies hold out for a full budget and a finished plan while a competitor shipped something small and unglamorous and started learning from it. The plan arrives eventually. By then the competition is two processes ahead and has an eval set.
Book an architecture review with Athru IT. Bring the agent you already have running, or the one small process you would most like off your team's plate. You will leave with the decisions it makes by default, the one costing you reliability, and a roadmap your own team can execute.