Every time a new model ships, we go back through our agent code looking for logic we can delete. That's the actual metric we optimize for. Not "how many tools does the agent have" or "how many edge cases does the harness handle," but how much of our own scaffolding can we throw away because the model just got better at the thing we were scaffolding around.

This runs against the instinct most engineers bring to agent-building. You watch a model fail at something, and the natural move is to write code that catches the failure: a regex to parse its output more forgivingly, a retry loop with a slightly different prompt, a state machine that boxes the model into a narrower decision at each step. Each fix feels reasonable in isolation. Six months later you're maintaining a brittle pile of special cases, and the model underneath has quietly gotten good enough that none of it is necessary anymore. Except now it's load-bearing, and nobody wants to touch it.

Scaffolding is a bet against the model's future

Every piece of deterministic scaffolding you build around a model is an implicit bet that the model won't get better at that specific thing before your scaffolding rots. In pharma workflows that bet is tempting to make, because the workflows are genuinely intolerant of ambiguity. A mis-extracted dosage or a wrong assumption about a trial protocol isn't a cosmetic bug, it's a trust problem. The instinct is to compensate for model uncertainty with code certainty: hardcode the decision tree, enumerate the valid paths, make the harness the thing that actually reasons and demote the model to a slot-filler.

We think that instinct is backwards, and we've paid for believing otherwise. Early on we wrote fairly elaborate orchestration logic to route between sub-tasks: classify the request, dispatch to a hand-picked chain of prompts, stitch results back together. It worked, but it also plateaued immediately. When we swapped in a stronger model, our routing logic became a ceiling on top of it rather than a floor underneath it. The model was now smart enough to do the routing itself, better than our heuristics did, but our harness didn't let it. We ended up ripping most of it out and replacing it with a single well-specified prompt and a handful of tools, and quality went up.

‍

The lesson wasn't "our routing code was bad code." It was that we'd built determinism to compensate for a capability gap that closed out from under us, and the code outlived its reason for existing.

‍

What actually belongs in the harness

None of this means "no harness." A model with no scaffolding at all is not an agent, it's a chat window. The question is which decisions belong in code and which belong in the model's judgment, and we've settled on a rough rule: the harness owns things that are true regardless of how smart the model is (permissions, data access boundaries, audit logging, retry and backoff mechanics, sandboxing) and the model owns everything that requires judgment about the actual task.

Concretely, in our stack the harness enforces which systems an agent is allowed to touch and what gets logged for every action, because that's a compliance requirement independent of model capability. A smarter model doesn't need less audit trail. The harness manages tool execution and error surfaces so a flaky API doesn't take down a whole run. It does not decide how to interpret a messy clinical query, which tool to reach for first, or how to phrase a clarifying question back to a user. Those are exactly the things models keep getting better at every generation, so we don't want code frozen in place making that call.

The tell for "this belongs in the harness" is durability: would this logic still be correct if we swapped in a model three generations ahead? Access control: yes, obviously. A hand-tuned prompt chain encoding today's model's blind spots: almost certainly not. When we catch ourselves writing an if-statement that's really just a workaround for the model being confused, we treat that as a signal to improve the prompt or the tool description, not the code path.

‍

Reliability without ossification

The pharma context makes it tempting to think reliability and thin harnesses are in tension, that if you care about correctness you should constrain the model more, not less. We've found the opposite works better in practice: constrain the blast radius, not the reasoning. Sandbox what the agent can affect, log everything it does, make failures visible and recoverable, and then let the model actually think, rather than forcing it through a decision tree we designed under yesterday's model's limitations.

The payoff compounds. A harness with hard boundaries and a light touch on reasoning gets better every time a new model drops, often with zero code changes on our end. A harness that encodes today's workarounds as permanent architecture gets worse, quietly, until someone has to go dig it out. We'd rather spend our engineering effort on the boundaries that don't change than on box-checking around capabilities that will.

‍