Sam Witteveen, one of the sharper practitioners in the agent space, recently published a video breaking down the difference between single-user and multi-user agent systems. It's worth watching. One concept he introduces — the distinction between agent core and agent harness — cuts to the heart of what most enterprise deployments get wrong.
The core is what most frameworks focus on: planning, reasoning, tool calling, memory. The harness is everything that makes it survive real users: identity, isolation, cost controls, observability, policy enforcement.
His point is precise: single-user systems are core-heavy and light on harness. Multi-user systems need to be harness-first. The harness isn't an add-on. It's the foundation.
For enterprise deployments, we'd go further. The harness isn't just a foundation. It's the product.
What the demo doesn't show
Every impressive agent demo runs in a controlled environment. One user. Clean data. One set of API keys. The agent reasons well, the tools execute, the output looks right.
None of that tells you what happens at scale. And the gap between demo and production isn't a performance problem — it's an architecture problem.
Here's what actually breaks when you move from one user to many:
State and isolation. A single-user system can store state in a markdown file. Memory is personal and deep. In a multi-user system, that same approach means sessions contaminate each other — one user's context leaks into another's retrieval, one user's learned preferences surface in another's responses. This is not an edge case. It's the default failure mode of single-user architecture deployed at scale.
Cost attribution. A single user tolerates inefficiency. They know when they prompted wrong, when a tool chain took three attempts, when the agent over-ran. In a multi-user system, one user who triggers expensive chains affects every other user on the platform. Without hard budget limits per agent and per role, cost becomes structurally unpredictable.
Observability. In a single-user system, nobody needs traces. The user is the operator. They know what they asked for. In enterprise deployments, observability isn't a feature you add later — it's table stakes. When something goes wrong across a fleet of agents, you need a complete, attributable record: which agent, which identity, which action, which cost, in what sequence. Without it, post-incident review is guesswork.
Authentication surface. Single-user systems handle auth informally. One service account, broadly scoped. In multi-user deployments, every tool access needs to be traceable to a specific identity. Not because it's best practice — because when something goes wrong, the investigation demands it.
The enterprise version of this problem
Witteveen is describing what happens when developers move from personal agent projects to production systems. In enterprise environments, the same dynamic plays out at a different scale — and with regulatory consequences.
Enterprise deployments are multi-user by definition. Multiple agents, multiple roles, multiple teams, multiple compliance frameworks — all running concurrently, all subject to audit. The harness isn't optional. The only question is whether you build it yourself, as a custom engineering project that needs rebuilding every time you add an agent or change a provider — or whether you deploy it as infrastructure.
Infrastructure that sits outside the agent. That covers every agent automatically. That doesn't require code changes. That produces a tamper-evident record of every action, every identity, every cost attribution — before you need it.
The demo works without the harness. Production doesn't. And in regulated industries, neither does your compliance posture.
Watch Sam's original breakdown of single-user vs. multi-user agent architecture:
Single User Agent vs Multi User Agent ↗↳ KYDE
Kyde is the governance harness for enterprise agent fleets — identity, cost controls, policy enforcement, and tamper-evident audit trails across every agent, every provider, without touching agent code.