You perfect your Claude setup. You save some memories, add some skills, wire up hooks, and write a CLAUDE.md. You build a harness that works for you.

Then Anthropic changes their pricing. Or OpenAI ships a better model. Or you just want a second agent. These are not exactly theoretical problems anymore.

And then you discover that everything you set up is locked inside one product. Your CLAUDE.md and custom skills aren't picked up by Codex. The memory the agent built up over weeks of working with you is invisible to every other tool. Nothing transfers smoothly.

The setup that matters is not the one inside Claude Code, Codex, or any other tool. It's the portable layer around them: the knowledge, memory, plugins, validation, and workflows that survive when the tool changes.

This matters for teams too. If one developer uses Claude Code, another uses Codex, and a third prefers Copilot, they should be able to share the same knowledge, skills, and workflow instead of rebuilding the harness inside each tool.

In this issue, I'll break that layer down into concrete components and walk through how to set up your own.

First, I want to recommend a related article from Chris Parsons. He argues that the senior engineer's job has shifted from writing or reviewing code to "training" the AI to write it better - in other words, improving the harness.

The part that connects directly to this issue is his distinction between vibe coding and agentic engineering: deciding which diffs need human eyes while tests and automated gates verify the rest. His advice lines up with the portable harness idea: invest in durable, tool-agnostic scaffolding, reset when an agent drifts, and treat verification, not generation, as the bottleneck.

In Harnesses Explained, I split the coding agent harness into two layers: the inner harness (Claude Code, Codex, etc.) and the outer harness (everything you bring to it). This time I want to get more concrete about what the outer harness actually contains.

First, you have a global harness: the machine-level setup for a broad context of work, like your work projects, personal projects, or both. It contains:

Inner harness - one or more agent tools you're using: Claude Code, Codex, Gemini CLI, a local model runner. The outer harness chooses, configures, and surrounds them.

Knowledge - a durable reference layer. Intentionally maintained notes and docs the agent can consult.

Memory - a shared recall layer across agent sessions. Compact, durable facts: preferences, conventions, tool quirks, project setup details, pointers back into the knowledge base.

Plugins - skills, hooks, MCP servers, slash commands. Plugins are where much of your proactive shaping of agent behavior lives.

Workflow - a reusable structure for task execution. E.g. plan → implement → verify → fix → review. The sequences, loops, and gates that make agent work repeatable.

Then each project gets its own harness overlay. Usually that means a git repo, but it could also be a knowledge vault, a research effort, or another bounded area of work. The project overlay includes instructions and skills (how to operate here), validation rules (what "correct" means), and specs (what the work was supposed to do). More on these below.

Whether you're new to coding agents or already using them for coding, knowledge work, or personal assistant workflows, the goal is the same: put the durable parts outside the agent. This section walks through what you need so you can switch the inner harness at any time.

Start with access to both frontier model families through a Claude subscription and a GPT subscription. This won't last forever, but right now both companies are giving away too many "free" subsidized tokens to pass up. The models are good at different things, and cross-agent review is one of the easiest ways to catch blind spots.

Other good options: Copilot or Cursor for multi-model support, Gemini when the price makes sense, or local models when privacy or cost matters more than frontier quality.

The key phrase is right now. Claude and GPT keep leapfrogging each other. Gemini is getting stronger. Use the best one or two available today, and expect that to change.

Knowledge is the structured source of truth for substantial context: company knowledge, project architecture, decision records, research notes, runbooks, operating docs. For coding, that might mean architecture notes, runbooks, RFCs, and decision records. For knowledge work, it might mean research notes, source material, drafts, meeting notes, and reusable context.

This is not just a docs folder inside your code repos. The knowledge layer here is global: either in the cloud or backed by its own repo. Agents should be able to reach the same information through MCP, a CLI, or plain files from whichever repo they're working in. It should live somewhere you control and can export.

I use Obsidian backed by git. Local Markdown is ideal here: portable, searchable, version-controlled, and readable by any agent. Other tools can work too, as long as agents can reach them through MCP or a CLI.

If knowledge is the full reference library, memory is the compact operational recall layer: preferences, conventions, project decisions, and pointers back to source-of-truth notes. The distinction is not black and white, and best practices are still evolving here.

A shared memory layer should give every agent access to the same durable recall. If one agent learns a convention, another can use it later. The service should handle the lifecycle around that recall: save durable facts, retrieve the relevant ones, scope them by global/project/session context, and keep the whole store inspectable, editable, deletable, and exportable.

I use agentmemory as that shared memory service. Claude Code, Codex, and my assistant agent all hit the same local REST daemon through MCP or native integration. It stores long-term memories, session-derived observations, audit history, and search indexes. Recall is not just text matching: agentmemory can combine keyword search, semantic search, and graph traversal over extracted entities and relationships. This setup is still new for me, but I expect it to grow more useful as memories accumulate.

Skills, hooks, MCP servers, slash commands: plugins are becoming a de facto standard across coding agent tools. Claude Code pioneered the pattern, and Codex is finally catching up. The common shape is a repo with a plugin manifest that bundles skills, hooks, and whatever else the plugin provides.

Skills are one type of feedforward control, a term I introduced in Harnesses Explained: they shape how the agent behaves before it acts. A debugging skill, a code review checklist, a release process: these are reusable procedures that steer the agent without relying on the model to figure everything out from scratch.

Which plugins you install depends on the work. For spec-driven development and TDD, I use Codagent Agent Skills. It packages reusable procedures for planning, test-driven development, code review, debugging, and validation so the agent has a workflow to follow instead of improvising from a prompt.

For other use cases, look for plugins that encode repeatable behavior: research capture, document review, email triage, release checklists, formatting enforcement, whatever you want every agent to know how to do. You can browse the Claude plugin marketplace, and compatible plugins can be installed with the Codex CLI as well. [claude|codex|copilot] plugin marketplace add org/repo works in most agents now. In general, install plugins at the global level so they're available across projects.

This is the layer I'm personally most interested in, and it's the one most people don't have yet.

A workflow is the reusable structure for task execution: plan → implement → verify → fix → review; research → synthesize → draft → edit; or triage → classify → route → follow up. It is the sequences, loops, checks, and handoffs that make agent work repeatable. Workflow is also where feedback controls live: the things that catch issues after the agent acts, like tests, validation commands, review agents, and verify/fix loops.

You can describe a workflow in a prompt. The agent might follow it. It might skip a step. It might stop early and ask if you're "ready to proceed." I covered why prompt-based workflows break down two issues ago, and last issue I showed what happens when the workflow runs the agent instead.

For the workflows that matter - multi-step implementations, spec-driven development, anything with nested loops - external orchestration is not optional. That's why I'm building Agent Runner, launching this month.

Here's one real workflow definition from Agent Runner, slightly modified for this article. It normally does not run on its own; it is embedded as one step inside larger workflows.

Once the global harness is in place, tailor it to the specific needs of each project.

A "project" is typically a git repo, but it could also be a knowledge vault, a research effort, or a client engagement: any bounded area of work with its own context, constraints, and artifacts.

Instructions tell the agent how to operate here. Architecture boundaries, coding standards, preferred libraries, domain vocabulary, "don't touch" areas, local setup notes. These live in CLAUDE.md, AGENTS.md, .codex/, or whatever the agent loads automatically. Project-specific skills go here too: procedures that only make sense in this project's context.

Validation defines what "correct" means. Test commands, type checks, lint rules, security scans, CI requirements, manual review criteria. Cross-agent review belongs here too, especially for catching issues deterministic checks miss. This is where Agent Validator fits: a configurable feedback-loop runner for deterministic checks and LLM-based reviews, scoped to the project.

Specs are durable artifacts that define intent for specific work. Feature specs, implementation plans, architecture designs, acceptance criteria, test plans. Even with every other harness component in place, if you're not doing spec-driven development, you're still mostly vibing. Specs reduce reliance on chat history and give humans and agents a shared object to review.

Once your agent setup is portable, you should be too. The point is not to carry the agent, the context, and your laptop everywhere. Run the agent on hardware you control - a Mac mini, VPS, old laptop, whatever - and connect to it from wherever you are.

Claude and Codex mobile apps can remotely control agent sessions. You can also use a mobile SSH client, chat gateway, or even email. The phone is only the control surface. The harness is comprised of the knowledge, memory, and skills that any of your devices can reach, wherever you are.

Do you really need to check in on work from the gym, or is that just a novelty? Sometimes, sure. But the gym, the walk, or the ballgame is often where good ideas show up. When that light bulb goes on, you want a thinking partner and assistant that can reach your full context and tools, not just a chatbot.

That is the real portability test. Can you capture the idea, ask the agent to research it, connect it to your notes, turn it into a spec, or queue the next workflow without sitting down at your main machine?

The coding agent tool should not be the center of your system. The portable harness should be.

Use multiple frontier agents. They're good at different things, and cross-agent reviews catch blind spots self-reviews miss.

Access them from anywhere. Run agents from infrastructure you control. When the runtime is yours, the harness is yours too.

Own the important information. Keep knowledge in exportable files, memory in a shared service, plugins in git, and workflow in deterministic orchestration.

The future is not one agent to rule them all. It is a portable harness that can use whichever agent is best today.

I'm giving a talk at SREday NYC on June 6 at Datadog's office: "Agent Harnesses: From Slot Machines to Safety Nets." If you've read this newsletter, you'll recognize the themes: what a harness is, why the outer coordination layer matters, and how to become the engineer in the loop instead of the agent babysitter.

I'm also joining a harness engineering panel organized by Stellans during NYC Tech Week (date TBD). The panel focuses on what it takes to move AI agents from impressive demos into dependable enterprise work. If you're in the NYC area, hit me up.