For the past stretch I've been building an agentic application — an agent with real work to do, real tools to do it with, and real users counting on the result. The application itself turned out to be the easy part. The interesting engineering showed up somewhere else entirely: the moment I accepted that this product has to live in two places at once. It has to distribute into harnesses I don't control — Claude and its peers, wherever users already work — and it also has to run natively, in a harness I build and own. The closest analogy is one every mobile team already knows: you ship an iOS version and an Android version of the same app, not because you're competing with Apple or Google, but because those are the operating systems your users live in. Harnesses are the operating systems of the agentic era, and your agent has to perform in both the ones you don't control and the one you do. Same product, two build targets — and the physics of each are different enough that if you architect for only one of them, the other will quietly break you.
I've started calling this discipline cross-harness agent development, and it's what I want to work through here: what stays constant across every harness, what a third-party harness gives you and takes away, why the first-party harness is non-optional even when distribution clearly runs through other people's front doors, and how to design the product so you only have to build it once.
The common fabric is the part of your product that travels
Start with what doesn't change. Underneath any harness — mine or anyone else's — sits what I've come to think of as the common fabric: the harness-agnostic core of the product. For an agentic application, that's the MCP server and the tools it exposes; a canonical set of skills that encode the right way to use those tools — the workflows that carry the product's actual expertise; the underlying APIs the tools call into; and the data model and auth that everything rests on.
The fabric is the product, in the sense that matters. It's the layer where your domain expertise actually lives. A tool is just an endpoint until a skill encodes the judgment of how and when to use it, and a skill is just advice until the tools give it hands. Get this layer right and the product means the same thing everywhere it shows up. Get it wrong and no harness — however good — can save it, because a harness can only orchestrate what the fabric makes reachable.
The discipline this forces is worth naming: anything that belongs to the product goes in the fabric, and only things that belong to a specific surface go in the harness. Every time I've been tempted to fix a product problem at the harness layer — a prompt tweak here, a workaround there — it's been a sign the fabric was missing something. The harness is where the product is experienced. The fabric is where it's defined.
A third-party harness lends your product a life you didn't build
Now watch what happens when that fabric gets pulled into a harness like Claude. Your product inherits a foundation you didn't build and couldn't build — not at any reasonable cost, and in some cases not at all.
The tool orchestration alone is the product of years of heavily researched, heavily evaluated work: figuring out which tools compose with which, when to reach for yours versus someone else's, how to recover when a call fails. Your tools don't arrive alone — they arrive alongside the user's calendar, their email, their CRM, their notes, and the harness composes across all of them without you writing a line of integration code. The harness knows the user in a way you don't: a longer and deeper history than your product will ever accumulate on its own. And in the enterprise, it sees the organization's memory — the context of the company itself — and your product gets to stand on all of it.
This is the piggyback, and it's genuinely wonderful. A user's first session with your product inside a mature harness can feel like their hundredth, because the harness fills in everything your product doesn't yet know. The agent that composes its work with the user's CRM, their inbox, their history — features you never shipped — isn't your feature at all. It's something the harness assembled out of your fabric and someone else's.
And it takes the instrument panel away
Here's what the piggyback costs you. Inside a third-party harness, you see your tool calls — and almost nothing else.
You don't get rich spans and traces. You don't see the reasoning between the calls, the turns where the user asked for something and the harness decided not to reach for your tools, the context that was assembled around your product before it was invoked. You can't tell whether a bad outcome was your fabric failing or the orchestration around it. The data you'd want to make the product better — the full arc of how it's actually being used — belongs to the harness, not to you. You get the outcome without the observability.
For anyone who has run production software, this should feel deeply uncomfortable. It's operating a service where someone else holds the logs. And it's not a flaw in any particular harness — it's structural. The harness's obligations run to the user and their privacy, not to your telemetry. But it means the environment where most of your users may live is also the environment where you can learn the least.
Your own harness is where the product has to stand on its own
Which is why the first-party harness isn't a vanity project or a hedge. It's where you find out what your product actually is.
In your own harness, the borrowed foundation is gone. There's no deep user history to lean on, no sibling tools to compose with, no enterprise memory filling in the blanks. It's a lower-context environment — and that's precisely its value. This is the product with the makeup off. If the agent can deliver for a user it barely knows, with only its own fabric to draw on, the fabric is strong. If it can't, every success inside a third-party harness was the harness's success, not yours — and you'd never have known.
And your own harness is where the instrument panel comes back. Full spans, full traces, every turn observable. It's the only environment where you can run the real feedback loop — evals against actual behavior, not inferences from tool-call logs. The first-party harness is simultaneously your lowest-context environment and your highest-observability one, and that combination is exactly what a feedback loop needs: hard conditions, fully measured.
Ship it the way mobile teams ship iOS and Android
To be clear about what I'm not saying: none of this is a call to go build a competitor to the harnesses that distribute you. The right mental model is far more ordinary. A mobile team doesn't build an Android version to spite Apple; it builds one because that's where half its users are, and because the same app has to perform inside each operating system's memory model, lifecycle, and conventions. Two build targets. One product.
Harnesses deserve exactly that discipline. The third-party harness is one operating system: rich services, deep user context, its own rules about what your product can see and do. Your first-party harness is another: leaner services, full visibility, your rules. So the two versions belong in your CI/CD pipeline the way platforms belong in a mobile team's — every change to the fabric builds for both targets, runs the same test suite against both runtimes, and ships to both. Not two products, and not a primary version with a side project. Two builds of one product, each tuned to the operating system it has to perform in.
The analogy also carries a warning mobile teams learned the hard way: an app tested on only one platform is broken on the other in ways nobody notices until users do. An agent that's only ever exercised inside a rich third-party harness has exactly that problem — except the breakage is invisible even after it happens, because that harness is the environment where you can't see.
Design it so you only build the product once
So how do you architect for both without building everything twice? A few principles have held up:
- The fabric is canonical, and there's exactly one. One MCP server, one set of tools, one skill library, one API layer. Both harnesses consume it. The moment you fork the fabric per surface, you're maintaining two products that will drift apart.
- Your own harness is a customer of your own fabric — not a bypass. The temptation in the first-party harness is to cheat: reach around the MCP server, call the API directly, special-case what the tools can't express. Resist it. Every bypass you allow is a capability your distributed product silently lacks, and you'll discover the gap in someone else's harness, where you can't see it.
- Assume floor context; treat inherited context as progressive enhancement. Design the skills so the product works in the lowest-context environment — your own harness with a new user — and gets better when a richer harness fills in history, memory, and sibling tools. If the product only works at the ceiling, it doesn't work.
- Instrument the fabric, because the fabric is the only layer that goes everywhere. You can't put tracing in someone else's harness, but every harness has to come through your tools and APIs. Whatever signal can be captured at that layer, honestly and with the user's trust intact, is the only telemetry that follows your product across every surface.
- Let the first-party harness be the eval environment. Its job isn't to win on traffic. Its job is to be the place where the full feedback loop runs — where behavior is observable end to end, and where improvements to the fabric are measured before they ship to every harness at once.
None of this makes the two architectures identical, and that's the point. They're similar the way an iOS build and an Android build are similar: same product, different physics. The design goal isn't symmetry — it's a fabric strong enough that the differences stop being dangerous.
The harness you own is where you find out what you've built
Here's the conclusion I keep arriving at. If your product only works when it inherits someone else's context — someone else's memory of the user, someone else's orchestration, someone else's foundation — then you haven't built a product. You've built a feature of their harness.
The common fabric is what keeps that from happening: the portable, canonical core that means the same thing on every surface. The third-party harness is where that fabric will meet most of its users, elevated by a foundation you could never build alone. And the first-party harness is where you go to meet the product without the borrowed intelligence — the low-context, high-observability room where its real strengths and real gaps are visible.
That's cross-harness agent development: one product, two operating systems, built accordingly — because the harness you own is the only place your product will ever tell you the truth.
AgentGraph designs agentic systems and places forward-deployed engineers with teams building exactly these architectures — the common fabric of MCP servers, tools, and skills that distributes into any harness, and the first-party surfaces where the feedback loop runs. If you're figuring out how to ship one product across many harnesses, let's talk.