The Agent Harness: A Platform Deliverable, Not a Workstation
- Abby Bangser
- 7 days ago
- 5 min read
Most organisations still treat the coding agent's harness, the tooling that wraps and directs it, as something an individual developer or team assembles. A config file here, an MCP connection there, a set of instructions pasted in from a wiki page, an arbitrary collection of skills, etc. I think that's the wrong model, and the fix is one that platform teams already know how to implement, just now applied to a new context.
The idea crystallised for me at ThoughtWorks' Future of Software Engineering with AI retreat, which I wrote up more broadly a few weeks ago. One line from the notes stuck with me: harnesses are expected to be treated like platforms because they are platforms. I would go a step further. A harness shouldn't just be treated like a platform. It should come out of one, produced and versioned by the platform team and configured on-demand by whoever needs it, the same way a database or a queue already is.
Agent harnesses: From personal setup to platform deliverable
In the world of DevOps, before self-service platforms existed, developers obtained infrastructure, such as databases, by installing and configuring them themselves as they saw fit. This provided high autonomy but also high responsibility, cost, and risk, i.e. “you build it, you run it” We are recreating this same experience with harnesses assembled per team, from whatever configs and instructions someone happened to combine together; it is the same pattern one layer up.
A harness has versions. It breaks when the underlying model changes. It needs testing, and where deterministic testing isn't possible, it needs evals, which one attendee at the retreat neatly summarised as a way to "check the checker." It needs an upgrade path, because the harness that worked with last quarter's model won't necessarily behave the same way with this quarter's. Every one of those is a lifecycle property, and lifecycle properties belong to whoever produces the thing, not whoever happens to be using it that week.
A harness isn't a personal setup for platform teams to audit from the outside. It's a capability, in the same sense a database or a Kafka topic is a capability, and the platform's job is to produce a coherent baseline, enable configuration through the same self-service path as everything else it delivers, and maintain a catalogue of instances for easy fleet management.
Domain boundaries live in the harness you deliver, not around it
One of the most important principles to respect for success with AI is that an agent should operate within a domain boundary and cross boundaries through APIs, rather than being given free rein across the whole system. As Matthew Skelton recently shared at QCon London, you should aim to “avoid unbounded access to data and other resources by AI tools and agents.”
This is the same principle that has made Domain-Driven Design (DDD) and Team Topologies so successful within organisational structures, and it is not a policy to enforce from the outside once you accept that the harness is something the platform produces. It has to be something you build into the deliverable itself.
The natural safety net that occurs when a human developer wanders outside their team's boundary is that they usually slow down. They ask questions, they get confused, they eventually stop. An agent doesn't slow down the same way; it will happily generate a plausible-looking change to a system it has no business touching, and do it fast.
A harness handed to a team pre-scoped to their domain, with other domains reachable only through governed APIs, closes that gap before the agent gets a chance to wander. A harness assembled ad hoc, with whatever access the individual developer configured, doesn't. That's what platform orchestration delivers. A governed middle layer deciding what a consumer, human, or agent is actually allowed to access, baked into the thing that gets delivered rather than policed after the fact.
Agent skills are part of the deliverable, and they rot if nobody owns them
Skills, the instructions that steer an agent's behaviour, are already showing drift and decay in the same way documentation always has. Sites like agentskills.io are trying to bring some order to this, but nothing has settled yet.
Skills rot when nobody owns the update, and there's no lifecycle attached to the content, just like wikis. If the harness is a platform deliverable, its skills should be versioned as part of that deliverable, with an owner and a review point, rather than left as loose files a team pastes in and forgets.
It's the same problem as managing any other reusable capability, just applied to a different kind of artefact, and one more reason the harness belongs on the platform's side of the fence rather than the individual developer's.
Where harness management actually sits
Another question I've heard raised is how harness management relates to platform orchestration. Are they the same layer wearing different clothes? Is harness management a new layer sitting on top? Or does it fold entirely into the platform, with the agent treated as just another consumer alongside the developer portal, the CLI, and the CI pipeline?
My answer, for what it's worth: the last one, and the harness is the clearest evidence for it. If the platform is already producing, versioning, and delivering the harness the agent runs in, there's no separate layer left for harness management to occupy. An agent asking for a database or a new environment isn't fundamentally different from a developer asking for the same thing, and the tool it uses to make the request shouldn't come from a different place either.
Treating harness management as a standalone discipline risks recreating exactly the shadow-IT problem platform engineering was invented to solve, just with a faster, more prolific author behind the requests.
What this means in practice
If you're wondering where to start, three moves follow from treating the harness as something you deliver rather than something a team assembles:
Add the harness to your platform's catalogue as its own capability, defined, versioned, and requestable the same way a database or an environment already is, rather than leaving it as a per-team assembly job.
Version and test that capability with the same rigour you'd apply to any other piece of production software, including a defined plan for what happens when the underlying model changes underneath it.
Bundle skills into the delivered harness with an owner and a review cadence attached, rather than letting them accumulate as loose files nobody's responsible for.
Final thoughts
Every capability your platform delivers exists because leaving it to individual teams created costs, risks, or inconsistencies nobody wanted to own. Databases, environments, CI pipelines all migrated from personal assembly to platform delivery for the same reason. The harness is on that same trajectory, just earlier in the journey.
The organisations that treat it as a platform deliverable now will have a catalogued, versioned, governed capability by the time the next model shift lands. The organisations that don't will have hundreds of bespoke harnesses, each with its own drift, its own blind spots, and its own idea of what the agent is allowed to touch. When something goes wrong (and something will), the second group will spend weeks working out which harness, which skill version, and which access boundary was in play. The first group will already know.
That's not a hypothetical cost. It's the shadow-IT bill platform engineering already paid once, arriving again with a faster, more prolific author behind the requests.
If you're keen to learn more about why we built Syntasso Kratix Enterprise (SKE) and Syntasso Kratix Agentic (SKA) to address these challenges, check out the rest of the website or reach out to us.
Comments