You Can't Reproduce What the Vendor Changes Under You

Reproducibility is the floor under every debugging loop. A pattern spreading across AI-agent tooling removes that floor — and doesn't tell you.

Reproducibility is the contract that makes debugging possible: same input, same code, same output. You reproduce a bug, you bisect it, you fix it, you confirm the fix by reproducing its absence. Remove reproducibility and the whole loop becomes guessing. A pattern now common in AI-agent tooling does exactly that.

The mechanism

Modern AI agent tools ship a static-looking client, but not all of the instructions that steer the model live in that client. A chunk of the operating context is fetched from the vendor's servers at runtime, merged into the model's behavioral instructions, and refreshed on a short timer — on the order of once a minute — from a feature-flag service the vendor controls.

So the effective program your agent runs is: your code, plus your config, plus a server-supplied instruction block whose contents can change between one request and the next, decided by someone who is not you, for reasons you will not see. In one well-documented case this shipped in a release whose changelog called it internal infrastructure work with no user-facing changes — while it injected behavioral instructions into an agent with shell access. The public bug thread ran to a couple dozen comments and no fix.

Three properties, one reproducibility-killer

• Remote — the steering comes from the vendor's side, so you cannot pin it the way you pin a dependency. There is no lockfile for someone else's server.
• Fast — a ~60-second refresh means two runs of the identical prompt, minutes apart, can execute against different effective instructions. The reproducibility contract is silently void.
• Invisible — the injected block is typically not written into the session transcript. When you go back to a recorded run, the instructions that shaped the model's behavior are missing from the record. You are debugging with a redacted log you did not know was redacted.

Put them together and you get a bug you cannot reproduce, cannot see in the logs, and cannot attribute. Your agent behaved differently on Tuesday. Your code did not change. Your config did not change. Under a reproducible system, "all inputs identical, output changed" is a contradiction that points at a gap in your understanding. Under remote injection, it is just Tuesday — and the contradiction is real, but it is not yours to resolve.

What to actually do

You cannot make someone else's server hold still. You can stop being blind to it and shrink the surface it touches.

1. Capture the assembled request and diff it. If your tooling lets you record the whole instruction set on the wire — not just your part — store it every run. When behavior drifts, diff today's assembled context against last week's. The block that was invisible in the transcript is visible on the wire; making the change visible is most of the battle.
2. Pin what the vendor lets you pin; enumerate what you cannot. Some steering behaviors expose a documented switch or an environment override; others are server-only. For each layer you depend on, write down who can change it, how you would find out, and what you would do the day it changes.
3. Move your guarantees to ground you hold. If a behavior must be stable — a safety guard, a delegation policy, a refusal boundary — do not trust a rented, remotely-steered layer to hold it. Put the guarantee in your own orchestration and your own deterministic checks around the model's output. Let the model drift; do not let the guarantees drift with it.
4. Monitor behavior, because you cannot monitor the instructions. The only reliable signal that the steering block changed is the agent's behavior changing. Instrument the outcomes you care about — delegation rate, refusal rate, task-completion shape — and alert on drift. You will see it in the numbers before you see it anywhere else.

Why it matters beyond one tool

This is not one vendor's bad release; it is a structural consequence of renting your foundation. As more of the stack becomes server-steered and remotely mutable, more of it becomes non-reproducible by construction — and reproducibility was never optional. It is the precondition for root-cause analysis, for honest incident reports, and for promising a customer that the thing they paid for behaves the same tomorrow as today.

Most of us will keep renting, because owning the foundation is expensive and renting is genuinely the right call for most workloads. Go in with eyes open: record what you send, pin what you can, move your guarantees to ground you hold, and watch the behavior because you cannot watch the instructions. A rented foundation is not a stable one, however good it is today — and the day it moves, you want to hear it from your monitoring, not from a customer.

The full source-cited version lives in the companion gist.

If you're building agent systems that have to behave the same way tomorrow as today — or you want to see what owning the whole infrastructure stack looks like on purpose — I run support and infrastructure at Pulsed Media. Seedboxes and storage on our own hardware in our own datacenter in Finland. Open-source platform (PMSS, GPL v3), 1Gbps or 10Gbps, EU jurisdiction, 14-day money-back.