Customer Zero Is an Agent

When Claude Opus 5 dropped, the developer world split into two camps within a week. One camp called it a downgrade — verbose, over-engineered, worse at the same work than the model it replaced. The other camp's advice was to delete your CLAUDE.md, your skills, your accumulated prompt scar tissue, and start from scratch — and that camp swore it was the smartest model they'd ever run.

Same weights. Same API. The difference was the harness: one camp was porting last year's assumptions into a new model, the other was re-characterizing from zero. Which camp you landed in wasn't about talent, and it wasn't about which lab you bet on. It was about who you thought your customer was.

If agents are how work gets done, your product's first customer is the agent. If harnesses are how agents run, your codebase's first customer is the harness.

This is the companion to my post on agent trajectories — the goal-scoped unit of agent work. That post argued the unit; this one is about the surfaces the unit runs on.

1.Agents are a user class, not a feature

I made a version of this bet about support: customers start inside an assistant, and the assistant becomes the front door. The general form is stronger — the primary user of your APIs, docs, and error messages is increasingly software.

An agent-as-user has needs a human forgives you for ignoring: structured truth it can cite, actions with contracts, failure modes it can parse, permissions it can hold, an audit trail someone can check. Design for the median session: no patience, infinite literalism, zero tribal knowledge. If a human has to translate your product into agent-speak, you didn't ship an interface — you shipped homework.

2.Your codebase's user is the harness

The same inversion, one layer down. A harness — the loop that runs a coding agent against your repo — cares about things your senior engineers stopped noticing years ago: how fast a cold context orients, whether names are greppable, whether tests give a verifiable signal, whether the docs say where things live or merely that things exist.

So measure the repo like a product, with an agent as the test user:

1. Time-to-orient — fresh session, no hints: how long to the right module?
2. Time-to-localize — given an issue: how fast to the offending function?
3. Steers-per-goal — how many corrections does a known task class cost, this month versus last?
4. Recovery — after a wrong turn, does it re-anchor or spiral?

These are KPIs, not vibes. When time-to-orient regresses, that's a bug; the fix is usually a better map, a renamed module, or a test that actually asserts something. And the harness is not a future user: at Sainapse, 78% of all PRs over the last ninety days — human-opened ones included — carry an agent co-author footer. The agent is already the median contributor. A codebase only humans can navigate is already legacy infrastructure.

3.Internal tools, external tools, one customer class

Software companies have always run two stacks: the external product customers pay for, and the internal machinery of shipping. The external stack got polish; the internal stack got jank, and jank was fine because humans bridged every gap with tribal knowledge.

Agents end the truce. An external agent needs callable, verifiable product surfaces — and the internal agents building that product need exactly the same qualities from your tooling. Internal jank used to cost onboarding time; now it caps how many agents you can usefully deploy.

Internal tools were always the real leverage. Agents just made the tax visible.

The compounding move is convergence. Sainapse sells support agents, and we run our own support motion on them — which means every product pain shows up in our own queue within hours, and every internal fix is a product improvement by construction. One feedback circuit instead of two. The same logic pushed us to give our internal ops agents product-grade surfaces rather than a shadow stack of scripts. The recurring processes they now run — founder briefings, meeting follow-through, shipping digests, competitor monitoring, knowledge ingest — used to consume somewhere between 30 and 50 human-hours a week. That's not a demo; that's a department. Divergence would have been a translation tax paid on every one of those runs, forever.

4.Loop engineering stops one ring too early

The discourse caught up to half of this in 2026. Peter Steinberger said stop prompting coding agents — design loops that prompt them. Boris Cherny described no longer writing prompts, just coordinating the Claude that does. Addy Osmani named the pattern "loop engineering": the engineer owns the outer loop.

All correct — and one ring short. There are three nested loops, and most teams industrialize only the innermost:

• L1 — the agent loop. Model and tools iterate until the task is done. This is what loop engineering optimizes.
• L2 — the trajectory loop. Sessions, PRs, and artifacts bound to one goal, every steer captured.
• L3 — the company loop. You use your own product to ship your own product.

L2 is the trajectory post. L3 is where dogfooding stops being soft advice: not "the founders click around on Fridays," but running one real company goal end-to-end on your own product every week and instrumenting the run like you'd instrument L1 — where did it stall, and which stall became a product change. If you aren't a user of what you're building, you can't gauge your product or your loops, and taste dies quietly first.

5.Model release velocity is a product constraint

New models arrive on a cadence measured in months, and each is a package of intelligence you unlock only as fast as your surfaces absorb its nuances — tool-calling quirks, context behavior, cost curves. The Opus 5 split was exactly this constraint playing out in public: the start-fresh camp had a re-characterization loop, and the downgrade camp had a migration tax. The winners don't "support models"; they characterize them, before production does it for them: a frozen suite of golden goals, re-run on every model swap, scored on pass rate, steers, latency, and dollars. Days when your surfaces were built for agents; quarters when they weren't.

If adopting a new model takes longer than the model's half-life of advantage, you don't have an AI strategy. You have a migration tax.

6.Big tech is one decision away from its inflection

Here's the take that follows from all of this, and it cuts against the startup-triumphalist mood: the organizations best positioned for agent-scale work are the biggest ones.

A company built around ten thousand developers has already industrialized the hard part. Code review as a gate, presubmit CI, staged rollouts, blast-radius controls — all of that validation infrastructure exists precisely because production had to survive a firehose of changes from thousands of imperfect humans. None of it cares who authored the diff.

The gates were built for scale already. Swapping the workforce is the small change.

The early numbers say the swap is underway: Sundar Pichai says AI now generates 75% of new code at Google, up from 50% a year earlier; Satya Nadella put Microsoft at as much as 30% back in April 2025 and climbing every quarter. Those percentages grew inside existing gates — the review and rollout machinery absorbed an AI-authored firehose without being redesigned.

The inflection comes when the workforce behind the gates turns elastic. Today those companies convert headcount into validated production changes; the moment they point the same machinery at agent sessions instead of (or alongside) employees, they convert token budget into validated production changes — and they can turn that dial faster than anyone, because the expensive part was never the authoring. It was the trust infrastructure, and they've spent two decades building it. Big tech's inflection isn't a new capability. It's a permission bit.

The catch — and the reason startups still have a window — is the layer above the gates: the goal layer. Validation infrastructure verifies changes; it doesn't name goals. That's trajectory literacy, and nobody's org chart has it yet.

The playbook

1. Name your primary non-human user: an agent persona for the product, harness constraints for the repo.
2. Ship callable, verifiable surfaces before prettier human chrome.
3. Measure fresh-session orientation weekly; treat regressions as bugs.
4. Maintain a golden trajectory suite — 10 to 30 real goals with success criteria.
5. Re-run it on every model release; ship the delta in days.
6. Log every steer; promote repeated steers into goal templates and pre-flight questions the agent asks you.
7. Promote multi-PR work into named trajectories; review them like incidents.
8. Mark every human-only bridge between your internal and external stacks; make it agent-callable or delete it.
9. Run one real company goal end-to-end on your own product every week.
10. Raise goal abstraction — then fleet size — only when steers-per-goal says you've earned it.

The companies that win this decade won't have the smartest single agent. They'll have the shortest path from model intelligence to trajectory completion to company goal — because they treated agents and harnesses as customer zero.