In Building the Plane While Flying It, I wrote about building Dap at a speed our processes weren't ready for. This is the other side of that speed: what happens when you try to take what you built and run it somewhere else.
The most comfortable cockpit
There's something dangerous about getting good at something. You stop noticing what you're actually doing and start attributing the results to yourself.
We've been using Claude Code for a while now. It's an incredible harness. It handles context management, tool orchestration, file operations, conversation continuity—things that, when they work, feel like breathing. You don't think about them. You just think, and the thing happens.
That's the trap.
When the harness does so much so well, you start to believe the intelligence is all in the agent. The prompts you write feel like suggestions, not instructions. The tools feel like utilities, not architecture. The system prompt feels like context, not infrastructure.
And then you try to run the same agent somewhere else.
Different cockpit, same pilot
Moving an agent from one harness to another should be straightforward, right? Same prompts, same tools—just a different surface to interact with.
It isn't.
Every harness has opinions. About how context is managed. About how tools are described. About how errors are surfaced and recovered from. About what the agent "knows" by default and what you have to tell it explicitly. About how conversation history is preserved, truncated, or summarized.
Claude Code has a particular way of making the agent feel autonomous. The harness does so much of the scaffolding that the system prompt can focus on intent. You write what you want, and the harness figures out a lot of the how.
Other harnesses don't work like that. Some give the agent less default structure. Some surface tool calls differently. Some make the agent's implicit knowledge visible in the wrong places. The agent that was thoughtful and deliberate in one environment becomes scattered and unsure in another.
Same pilot. Different cockpit. The controls are in different places, some instruments are missing, and the radio works on a different frequency.
The system prompt you didn't know you needed
Here's what we learned the hard way: the system prompt isn't context. It's the closest thing to source code an agent has.
When Claude Code handles so much for you, your system prompt can be lean. Direction, tone, maybe a few constraints. The harness fills in the gaps. But when you move to a harness that gives the agent less handholding, those gaps become chasms. The agent doesn't know how to recover from errors because the old harness handled recovery implicitly. It doesn't know when to ask for clarification because the old harness made that decision for it. It doesn't know how to prioritize tasks because the old harness had a built-in sense of workflow.
So you start adding things to the system prompt. Recovery strategies. Clarification triggers. Priority rules. Tool usage patterns. Decision frameworks. Things that were never written down because they were never needed—they were handled by the invisible machinery of the harness you left behind.
The system prompt grows. And grows. Until you realize: this isn't a prompt anymore. This is an operating manual. This is the documentation of how your agent actually thinks, not just what it thinks about.
Goliath's armor
Let's stop pretending: Claude Code is Goliath.
It's the biggest, most polished harness out there. The armor is thick—the context management, the tool orchestration, the way it makes everything feel seamless. When you're inside it, you feel invincible. And why wouldn't you? The infrastructure is doing most of the heavy lifting.
We're David. A smaller harness, faster and cheaper, with less scaffolding and fewer safety nets. On paper, it shouldn't compete. Goliath has the scale, the resources, the brand. David has a slingshot.
But here's what the story gets right and most people miss: David didn't win despite having less. He won because he knew how to use what he had. The slingshot isn't a lesser weapon—it's a precise one. It requires skill, practice, and an understanding of trajectory that you can't buy. You have to earn it.
That's exactly what happens when you build agents on leaner harnesses. You can't rely on the armor. You have to understand every decision the agent makes, because the harness won't make those decisions for it. You have to craft the system prompt, refine the tools, test the edge cases—the hard, deliberate work that Goliath's armor lets you skip.
And when you've done that work, something surprising happens: you can run circles around Goliath. Not because your harness is better. Because your knowledge of how to build is better. You've earned the precision that comes from not being able to hide behind infrastructure.
This is the real cost of depending on a single harness. Not that it might go away—though it might. Not that it might change—though it will. The real cost is that you stop building the muscle that makes you portable. You stop writing the system prompt that makes your agent truly self-sufficient. You stop refining the tools that work everywhere, because the tools that work everywhere are harder to build than the ones that work in one place.
The refactoring nobody asked for
If you want your agent to work across harnesses—to not be locked into a single provider, a single model, a single way of doing things—you have to sit down and do the unglamorous work.
You have to extract every implicit behavior from the harness and make it explicit in your system prompt. You have to design tools that carry their own documentation, their own error handling, their own fallbacks. You have to test your agent in environments where the safety net is thinner and the defaults are different.
This isn't fun work. It feels like refactoring code that already works. But it's the difference between an agent that works because of its environment and an agent that works regardless of its environment.
The first one is faster to build. The second one is actually useful.
What we're building toward
We're not anti-harness. A good harness is a genuine advantage. Claude Code earned its place in our workflow through quality, not through lock-in.
But we don't want to live inside Goliath's armor. Not because it's not comfortable—it is, dangerously so. Because comfort comes at a price: pricing structures we don't control, rate limits we can't negotiate, feature decisions we can't influence. When your entire workflow depends on a single provider's terms, you're not a customer. You're a hostage.
And it's not just about us. When we build agents for our clients, they need to know that the quality they're getting isn't tied to a single vendor's ecosystem. Tomorrow, if a client needs to switch harnesses—because of cost, because of compliance, because of strategy—they should be able to do it without the agent falling apart. The intelligence should travel with the agent, not stay embedded in the harness it was born in.
That means treating the system prompt as a first-class artifact—not a README, but a runtime contract. It means building tools that are self-documenting and self-contained. It means testing across environments the same way you test across browsers.
In Building the Plane While Flying It, I said that when everything moves faster, the basics aren't optional anymore. This is the same principle at a different level. When you stop relying on a single harness to do the thinking for you, the fundamentals of agent design aren't optional anymore. They're the only thing that holds.
Goliath had a great harness. David had a slingshot and a really good system prompt.