Build the Harness That Outlives the Agent

I use Codex every day. I assume it is temporary.

I do not mean that Codex will disappear. I mean that no model, interface, or agent tool should become the permanent home of how my company works. Models improve. Tool boundaries move. The useful interface this quarter may feel confining by the next one. A system that depends on one agent's private memory, command format, or permission model becomes expensive the moment another agent is better at the job.

So I try to keep a separation.

Codex is one place where work runs. Claude Code can be another. A CLI agent, an IDE agent, or a scheduled worker can be another. The harness is the operating system they enter: the sources they may trust, the operations they may call, the permissions they cannot cross, the checks that judge the result, and the learning left behind for whoever runs next.

The agent should be replaceable. The work around it should accumulate.

The switch test

Imagine that tomorrow you move one workflow to another agent.

What has to move with it?

If the answer is a short adapter and a small instruction file, you have built something portable. If the answer includes your customer history, document templates, permission rules, quality checks, business logic, and the only copy of what happened last time, the agent tool has quietly become your operating system.

This is the first test I would apply to any personal or company setup:

Could a second agent perform this work without rebuilding the company around itself?

Portability does not mean every agent receives identical instructions or uses the same tool protocol. Codex and Claude Code have different strengths and different ways of loading local guidance. MCP, APIs, and CLIs expose different interfaces. Some adapter work remains.

The goal is narrower and more useful: changing the agent should not require you to migrate the truth, rewrite the business operation, or loosen the boundary.

A wiki is a library

Most people begin with context. They create a personal wiki, organise project notes, collect transcripts, write careful instructions, and give the agent a directory it can search.

This is good work. A model without context must reconstruct the person or company from the conversation in front of it. The wiki gives it language, history, and useful material to reason from.

The limit appears when the agent has to act.

A wiki can say which roadmap is current. It does not define what happens when the roadmap and Jira disagree. It can say that an agent may prepare an email but never send it. It does not remove the send method. It can describe how a client deck should look. It does not inspect the finished object for an old client name, an off-page element, or a missing source.

Stored context answers, “What might the agent need to know?” A working harness must also answer:

• Which source wins?
• Which operation is allowed?
• Which part needs judgment?
• Which failure stops the run?
• Which result returns to the next one?

The wiki remains valuable. It becomes one part of a larger system.

The durable parts

I now think about a portable harness as 7 durable parts surrounded by thin runtime adapters.

1. Authoritative state

The harness needs more than files it can retrieve. It needs rules for authority.

A meeting transcript, a Jira issue, an account record, and a roadmap can all describe the same piece of work differently. The system must know which source owns the decision, which source owns delivery state, and where disagreement is surfaced rather than averaged away.

Keep this state outside the agent conversation. A chat is a place to reason over state, not the only place state exists.

2. Contracts

A contract names the input, output, side effects, and stopping condition of an operation.

“Prepare a roadmap update” is an instruction. “Read approved initiatives from this source, return this schema, leave the result as a draft, and surface these exceptions” is a contract.

Contracts make the rest of the system replaceable. One agent may reason through the request differently from another, but both can produce the same inspectable shape for the next operation.

3. Tool adapters

The outside world is full of opinionated interfaces: APIs, CLIs, MCP servers, browsers, databases, file systems, and provider SDKs. A portable harness gives agents stable commands over those differences.

The adapter may translate a stable operation such as create-reviewed-draft into today's Gmail API calls. It may expose an MCP tool to one runtime and a CLI command to another. The provider details remain real, but they stop leaking through every workflow.

4. Reusable operations

When settled mechanics recur, encode them.

We create the same families of documents repeatedly: statements of work, contracts, briefs, and presentations. The words and decisions change. Copying selected slides, filling approved layouts, exporting PDFs, checking text fit, and scanning for forbidden terms should not require fresh reasoning each time.

A model can perform those mechanics. That does not make model attention the right place to spend them. Small programs are cheaper to inspect, easier to test, and available to every agent that can call them.

5. Policy gates

Instructions explain a boundary. Policy enforces it.

Google's gmail.compose OAuth scope authorises both draft management and email sending. Those are separate jobs in my operating model. I want an agent to prepare a complete draft while remaining technically unable to send it through the approved route.

Our public zgws wrapper places a policy layer in front of the Google Workspace CLI. The profile used by agents may create and inspect drafts. Gmail send methods are rejected before the underlying command runs. Codex can call this wrapper. Another agent can call the same wrapper. The boundary belongs to the harness, not to either agent's memory.

This is a strong local guardrail. It becomes a complete security boundary only when the runtime cannot reach raw credentials or another client. Portability must not become an excuse for imprecise security claims.

6. Verification and recovery

Every repeatable operation needs an acceptance path and a failure path.

Use deterministic checks when the condition can be stated exactly: a schema is valid, text stays inside its box, expected placeholders are gone, links resolve, and forbidden names do not appear. Use model review where language and meaning need interpretation. Use a person where accepting the result carries responsibility.

Recovery is part of the contract. Name whether a failed check blocks the work, routes it to review, retries a bounded operation, or restores a previous state.

7. Write-back and learning

The work must leave more than an output.

Record the source used, the decision made, the exception that required review, the artifact created, and the observed result. If a failure is likely to recur, turn it into a test or a revised operation. If a customer response changes the decision, connect it to the work it changed.

The next agent should inherit the result through the system, not through an old chat transcript.

Keep the adapters thin

Each agent still needs local guidance. Codex may read an AGENTS.md file. Another tool may use skills, projects, rules, or a different instruction format. These files should explain how that runtime enters the harness. They should not contain the only copy of the harness.

A thin adapter answers questions such as:

• Where are the authoritative sources?
• Which stable commands are available?
• Which role should this run claim?
• Which checks must pass before returning the result?
• Where should the receipt be written?

If changing one business rule requires edits across several agent-specific instruction trees, the adapters have become owners. Move the rule down into the shared operation or policy layer.

This is also how a harness survives better models. When a model can perform a mechanic reliably on its own, you may remove an old utility. When a provider adds a finer permission, you may simplify a wrapper. The contract and boundary remain while the implementation gets smaller.

Put each kind of work in the right place

I use 4 defaults when deciding what belongs where:

• Model: language, ambiguity, comparison, interpretation, and proposal.
• Code: exact transformations, schemas, templates, and repeatable checks.
• Gate: external, destructive, expensive, or difficult-to-reverse actions.
• Person: decisions that carry accountability, taste, or a consequential trade-off.

The point is not to automate the maximum number of steps. It is to stop spending uncertain reasoning on settled mechanics while preserving the uncertainty that deserves judgment.

This division also keeps the system portable. Code and gates remain callable. People retain ownership. A different model can take over the uncertain portion without inheriting accidental authority.

Personal and company harnesses share an anatomy

An individual contributor does not need to settle for a flat context repository until somebody grants them a company system.

A personal harness can have an authoritative project state, stable tool commands, draft-only permissions, reusable operations, checks, and write-back. It has one owner and a smaller blast radius.

A company harness adds identities, shared ownership, versioned schemas, change review, service expectations, audit, and explicit disagreement. Those additions make the system harder to maintain. They do not create a different species of system.

This matters for teaching. Giving people a list of personal workflows shows them what somebody else needed last month. Teaching the architecture lets them work backwards from their own outcomes and build the parts that should survive.

Where Zentrik fits

An execution harness can repeat work safely and still begin from weak product intent.

Client requests arrive through calls, support tickets, research, product data, and conversations that use different language. Delivery systems record what a team plans to build. They rarely preserve the full path from customer evidence to the decision, through delivery, and back from the observed result.

We use Zentrik as the product learning layer. It keeps client requests and their source evidence connected to insights, opportunities, ideas, initiatives, delivery, and subsequent learning. People still decide what to build. An agent can inspect the same product record through whichever approved interface the harness gives it.

That is the useful connection. Zentrik does not need Codex to be the permanent agent. It gives Codex, another agent, and the product team a shared place where the reason for the work can survive the handoff.

Build from one outcome

Begin with work you expect to repeat. Then answer 8 questions:

1. What must be true when the work is complete?
2. Which source owns each fact or decision?
3. Where does interpretation change the result?
4. Which mechanics can become stable operations?
5. Which actions need a technical boundary or approval?
6. Which checks can stop or redirect the run?
7. What state and learning should be written back?
8. If the agent changed tomorrow, which parts would have to move?

That last question catches the coupling the other 7 can miss.

Build the smallest shared core that answers them for one workflow. Add a second runtime before you believe the architecture is portable. You do not need to run production work through both. The exercise will show whether your stable interfaces are real or merely names inside the first tool.

Models will keep improving. Agent products will keep competing over the best way to plan, remember, browse, code, and act. Let them.

Your advantage is not choosing the final agent. There will not be one. Your advantage is building work that becomes easier to carry into the next one.

If you want to compare this architecture with the operating stages teams move through, read The AI Adoption Ladder. If the missing part is the relationship between source evidence and a product decision, continue with Why Flat Context Isn't Enough.

I write these as I build them. If you run the switch test on one workflow, tell me what refused to move. LinkedIn is the easiest place to find me.