990 posts tagged with "insider"

When a dependency breaks, your build fails. When a workaround becomes unnecessary, nothing happens at all. That asymmetry is why every production LLM system older than a year is carrying scaffolding it no longer needs — retry choreography, output-repair parsers, forced chain-of-thought, elaborate task decomposition, chunking heuristics — each one built as a compensation for a specific model's specific weakness, and each one silently outliving the weakness it compensated for.

The uncomfortable part is that this isn't a hygiene problem, like stale feature flags. Obsolete scaffolding doesn't just sit there costing you latency and tokens. In the worst case it actively constrains the new model to the old model's ceiling: your decomposition logic chops a task into six steps because the 2024 model couldn't hold the whole thing, and the 2026 model — which could have one-shotted it — now inherits six opportunities to lose context at the seams you built.

Somewhere in your company there is a slide with one number on it. "AI quality: 87." Last quarter it said 85, so the slide is green. Meanwhile, your on-call channel is full of screenshots of the assistant confidently inventing refund policies for your largest enterprise customer. Both things are true at once, and the slide is the one lying.

The executive request behind that slide is completely reasonable: give me one score I can track, so I know whether the thing is getting better or worse. It works for revenue. It works for uptime. It does not work for an AI feature, because an AI feature's quality is not a scalar — it is a distribution over inputs, users, and time. Averaging that distribution into a single number doesn't summarize it; it destroys precisely the information a decision-maker needs.

This post is about the gap between those two facts: why the mean of your eval suite hides the regressions that actually hurt you, what to report instead, and how to present a legitimately noisy metric to a board-deck audience without torching your credibility the first week it moves down.

Somewhere in your company, an engineer has wired an agent fleet to a SaaS product licensed for fifty human seats. The fleet runs a thousand concurrent sessions overnight, authenticates through one service account, and does the work of a department. Nobody asked legal. Nobody asked the vendor. And if you read the contract carefully, there's a decent chance that entire workload is unlicensed — not because anyone intended to cheat, but because the contract was written for a world where "user" meant a person with a keyboard.

This is the quiet compliance problem of the agent era. Per-seat licensing, terms-of-service automation clauses, fair-use rate limits, and per-user analytics were all designed against a single assumption: usage scales with headcount. Agents break that assumption in every direction at once. A customer running agent fleets doesn't just stress the vendor's pricing model — they often violate the letter of the agreement, the economics behind it, or both.

Pull up your request logs from the last time you hit sustained 429s. You will probably find something odd: the errors don't arrive as a steady stream. They arrive in waves — a burst of 429s, a quiet gap, a bigger burst, another gap. The provider's quota didn't change between waves. Your traffic didn't spike. What you are looking at is your own retry logic, synchronized against itself. Every client that failed at second zero computed the same backoff delay, slept the same duration, and woke up at the same instant to fail together again.

This is the thundering herd, and the punchline is that the standard fix — exponential backoff — does not prevent it. Deterministic exponential backoff organizes the herd. It takes a crowd of clients that failed at roughly the same moment and marches them forward in lockstep: everyone retries at 1 second, then everyone at 2, then everyone at 4. The load spikes get farther apart, but each spike is just as tall as the first. If the spike is what triggered your rate limit, you have built a metronome that re-triggers it forever.

Your pricing page says every user pays the same. Your cost dashboard says otherwise. The same AI feature — same prompt template, same model, same feature flag — costs 55% more to serve a Spanish user, roughly double for a Japanese user, and over 3x for an Arabic or Bengali user. Meanwhile, the quality those users receive is measurably worse: on identical benchmark questions translated across languages, frontier models drop 13 to 24 percentage points when you leave the English distribution.

Most teams shipping AI features globally have never measured either number. They have per-locale pricing, per-locale support SLAs, per-locale legal review — and a single English eval suite standing in for the experience of every user on the planet.

This is the tokenizer tax, and it compounds with a quality gap that scale alone doesn't close. Both are invisible in your dashboards until you slice by language, and both were decided years before you wrote your first prompt, by the training corpus of a tokenizer you don't control.

If you run coding agents at any real scale, you own a fleet of ephemeral virtual machines. You may not have signed up for that. It happened the moment you decided — correctly — that untrusted, model-generated code should never execute inside your application's trust boundary. Every task gets its own sandbox, every sandbox is a microVM or hardened container, and suddenly the platform team that thought it was building "an agent product" is operating something that looks suspiciously like a miniature AWS Lambda: pool warming, snapshot pipelines, bin-packing schedulers, and a reaper process for the environments nobody came back for.

The trap is assuming your container orchestration instincts transfer cleanly. Some do. But Kubernetes grew up scheduling long-lived, homogeneous services, and agent sandboxes are the opposite: short-lived, wildly heterogeneous, and created at rates that make a deployment rollout look leisurely. The teams that struggle are the ones that treat sandbox infrastructure as "just containers with extra steps." The interesting engineering — and almost all of the cost — lives in four problems: cold starts, filesystem state, packing density, and abandonment.

Most build-vs-buy arguments in AI engineering are fought one component at a time. Should we build our own model gateway or use OpenRouter? Write our own agent loop or adopt a framework? Fine-tune or prompt? Each debate gets its own meeting, its own spreadsheet, its own loudest voice. And each one quietly assumes the landscape will hold still long enough for the decision to pay off.

It won't. The ground under your AI stack is moving faster than any stack has moved before. Inference prices for a fixed capability level have been falling somewhere between 9x and 900x per year depending on the capability threshold you track — GPT-3-level output that cost $60 per million tokens in late 2021 now costs pennies. Agent frameworks have gone through multiple breaking rewrites in three years. The gateway layer went from "we should build one" to a crowded commodity market with managed and self-hosted options in about eighteen months. Deciding component-by-component in a landscape like this is navigating a river by staring at your feet.

There's a sixty-year-old tool built for exactly this problem: the Wardley map. It won't tell you what to build. It will tell you something more useful — which of your components are about to become someone else's cheap product, and which are moving the other way.

Every progress bar you have ever shipped rests on one assumption: you know the denominator. Uploading a 40 MB file? The denominator is 40 MB. Installing 212 packages? The denominator is 212. The bar is honest because the total work is known before the work begins.

An agent breaks this assumption at the root. It doesn't execute a predetermined list of steps — it discovers its remaining work as it goes. It reads a file, which reveals three more files worth reading. It runs the tests, which fail, which spawns a debugging detour nobody planned. Step 4 of 7 becomes step 4 of 19 becomes, occasionally, step 4 of 4 because the last three turned out to be unnecessary. Percent-complete for an agent isn't hard to compute. It's undefined. There is no denominator until the work is finished, at which point the answer is always 100%.

Yet look at what we ship: spinners that promise imminent completion, bars that creep to 90% and stall, labels that say "almost done…" on minute two of a task that takes eight. These are all small lies, and users catch them. The interesting design question isn't how to fake progress more convincingly — it's what honest reassurance looks like when the duration of the work is structurally unknowable.

Your agent died at step seven of a twelve-step task. The framework caught the exception, waited with exponential backoff, and retried. It retried the step — with the same context window that had accumulated three failed tool calls, a half-parsed error message, and a plan the model had already abandoned. The retry failed too, of course, because a retry is a bet that the world changed, and nothing about that agent's world had changed. What needed to change was the agent's state — and no retry policy in any agent framework makes that decision.

Erlang's OTP libraries codified this exact decision thirty years ago, for telephone switches that had to run for decades. The insight behind supervisor trees was never "restart things when they crash." It was that how to recover is a separate concern from doing the work, owned by a separate process, arranged in a hierarchy where each level knows a little more about what recovery means. Most agent frameworks today bolt retries onto individual calls, which is like putting a try/catch around every line of a telephone switch. What they need is the hierarchy.

The web's economics rest on an assumption so old nobody wrote it down: the thing loading the page has eyeballs. A human arrives, an ad impression fires, an affiliate cookie drops, an analytics event attributes the visit — and that chain of tiny monetization events pays for the content. Every part of that chain is now breaking at once, because a growing share of your site's readers aren't people. They're agents, and an agent doesn't see ads. It extracts the answer, hands it to a user somewhere else, and leaves nothing behind but a log line.

This isn't a distant publisher problem you can watch from the engineering sidelines. If you build anything on retrieval — a RAG pipeline, an agent that browses, a product that summarizes the web — you are on the demand side of a market whose supply side just discovered it's been giving away inventory for free. The correction is underway, it has infrastructure and standards behind it, and it lands on your architecture as a new cost line and a new failure mode: upstream sources that were free and open last quarter going paywalled, licensed, or dark this quarter.

In January 2026, curl shut down its bug bounty program. Six years, $86,000 in payouts, and a steady stream of real vulnerabilities — ended not because the money ran out, but because the signal did. Historically, more than 15% of submissions turned out to be confirmed vulnerabilities. By late 2025 the rate was closer to one in twenty or one in thirty, and submission volume had spiked to eight times normal. The queue was full of long, confident, completely fabricated reports — one came with GDB sessions and register dumps referencing a function that doesn't exist in curl at all.

Here's the uncomfortable part: the people generating that flood aren't villains. Many of them are engineers like you, running agents like yours, pointed at repositories like the ones your product depends on. AI collapsed the cost of producing a contribution to near zero. It did nothing to the cost of reviewing one. Every economic system with that shape — cheap to emit, expensive to absorb — turns into a spam problem, and the absorbing side is a volunteer who was already unpaid before your agent showed up.

Persistent memory is the feature everyone adds to their agent and almost nobody maintains. The pitch is irresistible: the agent remembers your schema, your preferences, the decision from last Tuesday, and every session starts smarter than the last. The failure mode is quieter: memory grows monotonically by default, and an append-only store of facts about a changing world is a slow poisoning. The API that got migrated, the team that got reorged, the architectural decision that got reversed — all of it sits in the store next to fresh facts, retrieved with equal authority, injected into context with equal confidence.

A stateless agent makes isolated mistakes. A memory-equipped agent can turn one mistake into a recurring one, because it stores the error and then retrieves it later as evidence. One confidently-written wrong memory — "the payments service owns refund logic" — contaminates every future run that recalls it, and each run that acts on it may write new memories derived from it. That's not a storage problem. That's a garbage collection problem, and most agent memory systems ship without a collector.