Tagged ai-infrastructure
36 pieces
- · 10 min read
Build the Gold Set From the Source, Not From Your Own Output
A reference set assembled from a pipeline's own extracted output scores that pipeline against itself. Wherever the extraction is wrong, the reference is wrong in the same direction, and the evaluation agrees. The reference has to be derived from the source material by someone who did not see the pipeline's answer, and it has to be sampled from the documents that are hard rather than the documents that are typical.
- · 10 min read
Plant the Faults So the Harness Proves It Can See Them
A harness that has never detected a known fault has not been shown to detect anything. Injecting deliberate, known faults is the step that converts a green suite into a suite that can fail for the right reasons. This covers the fault classes worth planting in an extraction or retrieval pipeline, how each one should present, and why a planted fault is the positive half of a pair whose other half is the negative control.
- · 10 min read
Score Each Stage or You Are Tuning Blind
A multi-stage pipeline judged only on its combined output cannot tell you which stage contributed nothing. An extraction error, a dead retrieval branch, a fusion step absorbing an empty list and generation failing on good context all produce the same thin answer. Per-stage instrumentation means candidate counts per branch, per-stage scoring against a source-derived reference, and attribution before any improvement work starts.
- · 10 min read
Output Tokens Are The Bill: Why Trimming Your Prompt Did Not Help
For most model-backed features the output side dominates the cost, because output tokens are priced at a multiple of input tokens and because caching makes repeated input cheaper still. Teams optimise input context anyway, since that is the part they can see and control. Output length is also what drives latency, and the two compound through retries. The fix is to constrain the shape of the answer and to measure cost per completed operation rather than per call.
- · 10 min read
A Confidence Score That Never Changes Cannot Route Your Review Queue
Calibration in aggregate and the ability to rank individual items are two different properties, and a score can have the first without the second. In a lab reproduction, a calibrated but nearly constant confidence score caught 4 percent of errors at a 5 percent review budget, against 95 percent for an informative score on the same data. Threshold tuning cannot repair a score that does not rank, because there is no threshold at which a flat score separates anything.
- · 10 min read
Three Bugs That Look Like One Miss
A detector that failed to fire has at least three causes that are indistinguishable from outside the system. The signal was removed by a transform before it arrived, the threshold was calibrated on clean material and is wrong for real material, or the feature path on the device drifted from the one used in training. Two of the three are not in the model. The way to separate them is a break-map: apply one controlled condition at a time and measure under each.
- · 10 min read
What a Codec Does to a Watermark Is a Ceiling, Not a Bug
Published work on audio watermarking reports detection performance near 0.97 on clean audio falling toward chance, about 0.57, under certain neural codecs. That is the transform destroying the embedded signal, not a defect in the detector. Telling a ceiling apart from a bug decides whether the next quarter goes into a better detector or into a different system design, and it is why robustness targets have to be written against named conditions rather than a single number.
- · 7 min read
Two Correct Termination Proofs Compose Into a Hang
Your planner stops. Your executor stops. Both proofs are valid and neither is wrong. Put them in a loop together and the system runs forever, because termination is not a property that composes. Podelski and Rybalchenko formalised the fix in 2004, and it explains exactly why per-component monitoring cannot see a hang that lives between components.
- · 7 min read
Bounded the Wrong Thing: What TCP's 1988 Fix Teaches Your Agent Loop
TCP already had a bound before congestion collapse. The receive window was real, correctly enforced, and nobody had a bug in it. The internet fell over anyway, because that window protected the receiver and the thing failing was the network in between. Jacobson did not delete it. He added a second window measuring the thing that was actually going wrong and took the minimum of the two.
- · 7 min read
The Delete-the-Variable Test
A ten-second check that tells you whether a variable is doing real work or is scaffolding: delete it, rerun, and see what changes. Delete TCP's congestion window and the internet falls over, which it did in 1986. Delete your agent's iteration cap and the trace does not flinch. The test has one important limit, and knowing it is what stops the test becoming a licence to remove your own safety nets.
- · 8 min read
The Third Option: Large Integrator, Narrow Specialist, or One Accountable Owner
An organisation with a hard cross-layer production problem weighs four options, and each is structurally wrong for it in a different way. The large integrator is broad and shallow with hand-offs at every seam. The narrow specialist is deep in one layer and hands off at its edge. The AI vendor sells the five percent. Staffing gives you hands without an owner. This is what the fifth option is and when it is not the answer.
- · 7 min read
Your Agent Framework Was Specified in 1990 (And Is Missing the Same State)
In 1990 Cohen and Levesque formally specified what it means for an agent to hold a goal: it believes the goal is not yet achieved, it wants it achieved, and it maintains that commitment until it believes either that the goal is achieved or that it is unachievable. That second exit is the terminal state every current agent framework lacks. It was written down thirty-six years ago in the field's flagship journal.
- · 10 min read
I Read the Stop Condition in Nine Agent Frameworks. The Third Column Is Empty.
Nine agent frameworks, from nine organisations, in different languages, with no shared lineage. Every one decides whether to keep going using the same two ingredients: the model's opinion that it is not finished, and a counter. Not one of them checks a measure of the remaining work. The third column of the audit is empty, and it is empty for a reason that is not laziness.
- · 8 min read
A Time Fuse and an Iteration Fuse Are Not the Same Thing
A hung tool call freezes the iteration counter forever, so a max-iteration cap can never fire on a hang. Only a clock catches it, which is exactly why every embedded watchdog counts time rather than iterations and runs on its own oscillator. Too slow is a hang and too fast is a spin: two opposite edges, two different instruments, and most teams have shipped two copies of the same half.
- · 10 min read
The Model Is Five Percent: Where Production AI Actually Fails
Across a decade of systems in defense, medical devices, industrial automation, fintech, and infrastructure at fleet scale, the failure is almost never in the model. It is in the ninety-five percent underneath: the pipelines, the protocols, the drivers, the firmware, the silicon, and above all the seams between them. The clearest proof is that the identical failure shows up in systems with no model in them at all.
- · 8 min read
Every Stopping Rule Needs a Model of the Task: Eighty Years of Evidence
Munitions inspection in 1945, early stopping in clinical trials, Bayesian optimization, multi-armed bandits, index policies, and proof assistants that will not compile until you supply the measure yourself. Seven fields over eighty years that do not read each other's papers, and every one needed a number describing the work rather than the effort. Your LLM agent has a model of language and no model of the task, which is exactly why its stopping rule is missing.
- · 7 min read
Why You Can't Let an AI Grade Its Own Homework
Use the same model to write an answer and to judge it, and the loop closes on itself: it keeps the same blind spots twice, and it goes easy on itself in ways that are measurable rather than figurative. It prefers longer answers and its own writing style, and scores those higher. The single sharpest question to ask anyone building your evaluation is what is doing the checking.
- · 8 min read
Recall Is the Silent Killer of Your RAG System
If the answer lives in a document your system never pulled up, nothing downstream can rescue it. The model cannot quote a page that was never opened, so it answers confidently from whatever it did find, and the output looks exactly like a good answer. Recall is the one failure that leaves no trace in the output, which is why it is the first thing to measure and the last thing anyone does.
- · 7 min read
Durable Execution Is Not Exactly-Once (and What to Do Instead)
Durable execution replays a workflow and skips the steps that already completed, which narrows the window in which a side effect can run twice. It does not close it, because the gap between performing an effect and recording that you performed it cannot be made atomic across a network boundary. Nothing provides exactly-once. What you get is at-least-once plus a way to make the second one harmless.
- · 7 min read
You Can't Fix What You Can't See: Instrumenting an AI Agent
A real system had 11 internal steps and logged exactly one thing: did the whole run work, yes or no. So when it failed it looked random, and good engineers said it fails randomly and we cannot reproduce it. There is no such thing as random failure, only failure you cannot see. Instrumenting every step took two days and showed 85 percent of failures coming from one step, which then took two days to fix.
- · 7 min read
How One Bad Input Poisons an Entire Agent Chain (and the Fix)
One step missed a single document. That assumption reached the planner, which generated three subtasks that each inherited it, and their outputs became the next step's input. Five steps down, the output had nothing to do with reality, confident and completely wrong, with every individual step reasoning flawlessly. The fix was not the model: letting each step reject a bad input instead of swallowing it cut the cascade by 82 percent.
- · 6 min read
Wrong vs Load-Bearing Wrong: When One AI Answer Becomes a Foundation
A system that is wrong costs you one answer. A system that is load-bearing and wrong costs you everything standing on that answer. In a trusted internal tool the output is not the end of anything, it is the start of a chain: a wrong answer becomes a wrong action, the action becomes a commitment, and no stage downstream ever rereads the source. Nothing on your dashboard tells you which of the two you have.
- · 7 min read
Every Metric Is a Proxy: Goodhart's Law for AI Systems
You cannot read forty thousand answers, so you appoint one number as a messenger and send it to check the truth. Every dashboard number is that: a stand-in for something you actually care about but cannot watch directly. The gap between the number and the thing is where trouble hides, and the moment the number becomes the goal, people find ways to move it that have nothing to do with what you wanted.
- · 8 min read
How to Build a Test Set That Actually Predicts Production
A test set drawn at random from your training data measures how much your test set resembles your training set, not whether the system works. Building one that predicts production means holding out whole groups rather than random samples, choosing the grouping variable that matches how your system will actually be deployed, sizing the held-out groups honestly, and checking for the leakage that inflates a score while nothing was learned.
- · 8 min read
Before You Blame the Model: The Four Boring Checks
When an AI system works in testing and fails in production, the model is the last thing to suspect, not the first. Four checks rule out the plumbing before you touch anything interesting: is the same model actually running, is it getting the same input, is the preprocessing identical, and is something quietly timing out or falling back. Most reported model failures die at one of these four.
- · 11 min read
The Eighty Percent That Separates an AI Agent Demo From a Platform
Building the agents is about 20% of the work. The 80% that decides whether an agent survives production is the part everyone skips: reconciliation when systems disagree, confidence thresholds that return no answer instead of a wrong one, validation before any real action, and the cost and observability work. A better model does not touch any of it, and all of it is buildable today.
- · 13 min read
Why Your AI Agent Won't Stop (and Why Capping the Loop Doesn't Fix It)
An AI agent can run green for 264 hours and bill 47,000 dollars with every single call bounded, because the iteration cap is a fuel gauge, not a progress bar. It measures how much you have spent, not how much work is left, so 'I gave up' and 'I am done' come back identical. Stopping reliably requires a number that measures the task itself, computed without asking the model.
- · 9 min read
Cleaning Your Input Can Make Your AI Worse
A model does not read your input, it reads a compressed representation of it, keeping only the features it found useful and throwing the rest away. So cleaning up a messy input with a denoiser polishes exactly the information the model already discarded, and moves the features it actually reads in a direction you cannot see, which is why input quality can go up while accuracy goes down.
- · 11 min read
Your AI Is Memory-Bound, Not Compute-Bound (So Tuning the Model Won't Fix Latency)
On fixed hardware, inference latency is set by moving bytes, not by doing math. Most models sit in the memory-bound region with the compute units idle, so the real cost is moving weights and activations across a fixed memory bandwidth. Accuracy, latency, memory, and power are not four goals, they are four views of one thing, the bus, and the worst-case tail is set by contention, not by your model.
- · 12 min read
Confidence Is Not Evidence: Why an AI Model Can't Tell You When to Trust It
A model is geometry fit to data, so past the edge of its training it does not stop, it extrapolates, applying a flat rule that was anchored to nothing, with full confidence. Its certainty is not evidence, because standard training optimizes knowing the answer and never optimizes knowing whether it knows. The decision to trust it has to live outside the model.
- · 12 min read
Why Your AI Agent Reports Success But Nothing Ran: Five Ways a Tool Call Dies
When an agent says it called a tool, the run comes back green, and nothing happened, the model almost never lied. A tool call is just text the model hands off, and it gets dropped somewhere in the plumbing between the model and the tool, in one of five places: streaming, index collision, proxy translation, the wrong finish flag, or no check at the end. A bigger model fixes none of them.
- · 10 min read
Retrieval or Generation? Why You Can't Tell Which Half of Your RAG System Broke
A wrong RAG answer is not one failure, it is two: the search pulled the wrong pages, or the search worked and the model ignored them. From the output they look identical, same confident tone, same citation, but they need opposite fixes. And one blended quality score averages the two into a green number that hides which half is on fire.
- · 12 min read
Why Your AI Agent Double-Executes: Retry Is a Second Execution, Not a Second Chance
When an agent charges a card twice or sends an email twice, nothing is broken to go find: no error, no red in the logs, the action was correct and simply ran twice. Duplicates enter through four doors, retry, redelivery, redispatch, and double trigger, but a duplicate only hurts you when there is no gate in front of the side effect. The fix is one idempotency key, identical no matter which door it came through.
- · 13 min read
Why Your AI Agents Fail, and How to Fix It
AI agents almost never fail because of the model. Chain enough steps and the math turns against you: at 95% reliability per step, a 20-step agent finishes under 40% of the time, and the failure lives in the coordination between steps, not inside any one of them. The fix is system engineering, verification, state, and guardrails, not a better model.
- · 15 min read
How to Fix a Broken RAG System (Without Rebuilding the Model)
A RAG system that scored 95% in testing and collapses in production almost never needs a model rebuild. The failure is usually in one corner of the pipeline, and the fix is four cheap steps: slice the score to find the broken corner, measure recall precision and faithfulness separately, build a check that is not the thing being checked, and re-check on a schedule.
- · 15 min read
Why Your AI Works in Testing but Fails in Production
When a model scores 95% in staging and collapses to 44% in production, the model is almost never the cause. The usual fix, rebuilding the model, retrains on the same data and reproduces the same failure. The real problem is what the model learned from the data, and it is usually fixable in days, not months.