A reusable agent harness gets more useful every time it absorbs a repeated integration problem. That is also how it can quietly become a second product without anyone deciding to build one.
Imagine a shared booking engine used by several hotels. It can persist a task, call services, stream progress, retry a failed request, and pause when staff approval is needed. Those are useful mechanisms to standardize.
The hotel still has to decide which room record is authoritative, who may waive a charge, what counts as a valid cancellation, which guest data may be shown, and whether a booking is actually confirmed. If the shared engine starts owning those decisions because it already handles the workflow, the abstraction has crossed a line. It now carries one hotel's business rules inside machinery that was supposed to be reusable.
That is the distinction I find more useful than arguing about whether an agent loop should be thin or feature-rich.
A capable harness can own a lot. The host application should still own what the work means, what it may affect, and who remains in control.
A harness can be substantial without owning the product
The easy version of this argument is "keep the agent loop small." I do not think that is precise enough.
OpenAI's App Server architecture is a useful counterexample to an overly thin definition. The reusable layer described there handles substantial generic machinery: thread lifecycle and persistence, configuration and authentication flows, tool execution, the core loop, event translation, and an approval-request protocol.
Its newer Codex platform framing makes a complementary split visible. The harness can provide the reusable execution layer while the surrounding application supplies product context, business rules, capabilities, interface, and consent around consequential actions.
I am using those as concrete implementations, not as a universal agent-architecture standard. The useful part is the ownership distinction they expose.
A component can implement a mechanism without becoming the authority behind that mechanism.
An approval system makes this obvious. A harness can detect that a tool call needs approval, pause, emit a request, receive allow or deny, and resume. None of those mechanics tells it whether refunding a customer should require approval, which employee may approve it, or whether a second approver is required above a threshold.
The mechanism is reusable. The consequence policy is not.
The hotel analogy stops there. Real agent systems do not have to mirror this split as separate processes, packages, databases, or services. Semantic ownership and physical code placement are different questions. A host-owned policy can still be enforced by harness code.
The same concern can be split across both layers
This is why labels like "the harness owns tools" or "the application owns context" are too broad on their own.
The same concern often contains a reusable mechanism and a product-specific authority decision.
| Concern | Reusable harness can own | Host application should remain authoritative for |
|---|---|---|
| Context | thread history, message structure, context-window accounting, compaction, attachment transport | which business object is in scope, which source is authoritative, what the user may see, which version is current |
| Tools | discovery and invocation protocol, argument transport, sandboxing, progress events, structured results | which capabilities exist, who may use them, preconditions, side effects, business semantics |
| Approvals | request, pause, resume, enforcement mechanics | which actions require consent, who may approve, what the decision means |
| State | conversation or session persistence, runtime checkpoints | system-of-record records, authoritative workflow transitions, business history |
| Interface | typed events, requests, diffs, progress and result primitives | domain labels, selected objects, consent wording, review surfaces, recovery experience |
| Verification | generic hooks, test execution, result transport | the authoritative success criteria and real-world gates for this product |
The important question is not where a function happens to execute. It is which layer is allowed to define the meaning of the decision.
If changing a refund rule requires changing the generic runtime, business semantics have leaked downward. If changing the runtime requires migrating the product's customer records, authoritative state has leaked downward. If two layers can independently decide whether an action is allowed, authority has become ambiguous.
Those are architecture problems even when the software is currently working.
Context is where the leak becomes hard to see
"Context" sounds generic until the product has to answer a real question.
A harness can reasonably manage a durable thread, compact old messages, track token budget, carry attachments, and reconstruct enough execution history to resume a session. None of that makes it the owner of which customer, incident, shipment, repository, or document the user is actually operating on.
That second class of context belongs to the application because it carries domain authority.
The application may need to decide:
- which record is canonical for the task;
- whether the current user may expose a field to the model;
- whether one document supersedes another;
- whether information may cross a tenant, client, or workspace boundary;
- whether state has changed since the agent last saw it.
A larger context window does not answer any of those questions. Neither does a better summarizer.
Dream Atlas has a narrower interface-side treatment of the same failure in The User Can See It. The Agent Cannot.: an interface may display a selected object that the agent has no stable way to identify or recover. The state exists. The missing piece is an address and an owner for the mapping.
That is exactly the kind of detail that can look like "agent context" while actually being a product contract.
Durable thread state is not business state
A reusable runtime may need durable state. That is not a concession; it is often necessary.
A thread can survive a restart. A tool call can be resumed. An interrupted turn can keep enough history to continue later. The harness needs state to do those things well.
The trouble starts when nearby business records are copied into the same layer and gradually become a second source of truth.
harness state
= what the runtime needs to execute and resume agent work
application state
= what the product considers authoritative about the real workflow
A harness can cache or reference application state. It can even persist a representation of it when that is useful. The application should remain able to say which record is current and which transition actually happened.
Otherwise a debugging session eventually reaches the worst possible question: which of these two databases did the product mean?
The loop should not own the definition of success either
Liquid AI's production-loop experiment is useful here for a different reason. Its argument is that autonomous work became useful on the real task when the loop iterated against production-scale data and external verification rather than treating the agent's own checks as sufficient.
I am not taking that article as a specification for host-application ownership. It supports a narrower point: the loop does not have to be the authority that decides whether the work succeeded.
Depending on the product, success may be established by a database constraint, a business-rule engine, a production response, a reconciled ledger, a policy check, a human approval, or an independently owned verifier.
The harness needs access to the signal. It does not need to own the rule that gives the signal meaning.
That becomes especially important when the agent can change the environment it is testing. A verifier or system of record that lives outside the loop gives the product somewhere else to anchor truth.
Two tests expose most bad seams
1. The replacement test
Imagine replacing Runtime A with Runtime B. Event formats may change. Tool adapters may change. Thread semantics may need translation. Rich provider-specific capabilities may create real switching cost.
But the product should not have to rediscover what a refund means, migrate its approval policy, move its customer records, or redefine who is allowed to change a shipment because those rules were stored inside the old harness.
This is diagnostic, not a promise that agent runtimes are interchangeable. It asks a narrower question: did we put product authority inside the component we intended to be reusable infrastructure?
2. The debugging test
Suppose an agent rebooks the wrong shipment. A useful investigation should be able to assign the important questions to an owner.
The application should be able to establish which shipment was selected, which capabilities were exposed, which user had authority, what approval policy applied, and what the system of record contained.
The harness should be able to establish which thread ran, which context it received, which tool call it emitted, what events occurred, and how execution progressed.
That separation does not prevent the failure.
It makes the failure attributable.
The expensive failure is a shadow application
Boundary drift is rarely dramatic. It is usually a pile of reasonable local decisions.
A product-specific permission check lands in generic tool middleware because that is where the tool call already passes. Domain approval rules move into agent configuration because the harness already pauses for approvals. Customer state gets copied into a runtime database because the agent needs it frequently. One interface's event assumptions become the default event contract for every application using the runtime.
Eventually the host and the harness both partially own the same workflow.
Reuse did not remove complexity. It distributed authority across two places.
The opposite mistake is real too. If every application has to rebuild thread lifecycle, streaming, tool-call orchestration, sandboxing, interruption, compaction, retry behavior, and generic approval protocol, the shared layer is not doing enough.
Feature count is the wrong test.
A better one is semantic dependency: can this concern be implemented correctly without understanding this application's business objects, user contract, or consequence model?
If yes, it is a strong candidate for reusable harness ownership.
If no, the host application should remain the authority even when the harness supplies hooks, storage, transport, or enforcement machinery.
Five questions before moving something into the harness
When another responsibility starts looking reusable, I would ask five things before moving its ownership downward:
- Does the answer depend on business meaning? If the rule only makes sense after understanding concepts unique to this product, the application probably needs to own it.
- Does it decide authority or consequence? Permissions, approval policy, canonical state, destructive actions, and human intervention belong close to the product's authority model.
- Can another host reuse the mechanism without inheriting our assumptions? If reuse requires importing one product's state machine, labels, permission rules, or recovery semantics, the abstraction is not as generic as it looks.
- Can the harness be replaced without moving the product's source of truth? If changing runtimes means migrating business records or approval history, the reusable layer has absorbed more than execution machinery.
- Can a failure be assigned to one layer? If both layers can choose the same context, mutate the same authoritative state, or decide the same permission, the seam is already ambiguous.
None of these questions produces one required diagram. That is the point.
The boundary is about ownership, not topology.
A reusable harness can keep getting better at running agents. It can become stateful, tool-rich, event-driven, sandboxed, resumable, and deeply integrated. The host application can use all of that without surrendering its system of record, business capabilities, consent semantics, or user contract.
The loop can own execution. The product still has to own the job.
// End of transmission. Ask who decides. — ZYANE