Tagged reliability
64 pieces
- · 9 min read
Every Third-Party API Fails Differently, So Put One Adapter Between Each One and Your Product
Integrating providers inline means every provider's schema, auth, rate limits and failure modes spread through your application, and one provider's outage empties the page instead of thinning it. One adapter per provider behind a single internal shape contains the variation where it starts. On a flight-search product this took API success from 90.6 to 98.95 percent and empty results caused by provider failure from 6.8 to 0.9 percent.
- · 10 min read
Accept The Work, Not The Claim: An Agent's Own Status Is Not Evidence
A headless agent run that hits a rate limit can exit with a success status and a zero exit code, having written nothing at all. Every reliability feature that reads the agent's own account of what happened, retry, recovery, the status pane, then repeats that false claim instead of catching it. The only fix is an independent check between running and accepting.
- · 10 min read
Six Drills That Break An Agent: Accept Milestones By Breaking Them, Not By Demonstration
A demonstration shows an agent pipeline working on the path its author chose. A drill breaks it on purpose and records what the system does. Six drills cover most of what goes wrong: killing the worker mid-run, hitting the output token cap, resuming and watching the budget, cancelling a run that does not heartbeat, rate-limiting mid-run, and changing the workspace through the shell behind the tool's back.
- · 10 min read
You Cannot Cancel What Does Not Heartbeat: Cooperative Cancellation And The Button That Does Nothing
In at least one widely used workflow engine, cancellation is delivered only to work that heartbeats. Wrap a command-line process that never reports in, and the cancel control returns successfully, the orchestrator marks the task cancelled, and the process keeps running and keeps spending. Cancellation is cooperative almost everywhere, which means it is a protocol the work has to participate in, and a timeout is the only non-cooperative backstop.
- · 8 min read
The Cheapest Option That Does Not Work: Gate on the Physical Constraint Before You Rank on Price
When a cheap option carries a risk the user cannot see, ranking it first and warning in the fine print puts the trap exactly where trust is highest. Treat every option as a candidate until it proves executable, gate on the physical constraint, and reject silently. On a self-transfer flight product this caught 76 percent of the combinations that could not actually be made, took false-viable connections from 12.4 to 1.9 percent, and raised the share of searches returning the cheapest valid result from 81 to 95.8 percent.
- · 9 min read
Trust the Webhook, Not the Page: Why Payments Go Missing Between Three Systems That All Report Success
The site, the payment processor and your records each work correctly on their own, and the money that goes missing is lost in the gaps between them. Confirming on the landing page loses every payment where the browser never came back. The processor retries for up to three days, may deliver the same event twice, and guarantees no ordering, so the handler has to be idempotent and the state has to be derived from a ledger rather than incremented on arrival.
- · 10 min read
Checkpoints Do Not See What The Shell Did: Partial State Capture Is Worse Than None
A tool that snapshots its own view of a workspace cannot capture changes made outside that view, such as a file moved or generated by a shell command. Restoring the checkpoint reverts the tool's edits and leaves the shell's edits in place, producing a state that never existed at any point in the run. That is worse than no checkpointing, because a known-dirty workspace gets rebuilt while a confidently restored one gets built on.
- · 7 min read
Bound the Concurrency or Your Latency Problem Becomes a Refusal
Running independent calls concurrently is the right instinct, and unbounded concurrency converts a slow path into a failing one. Without a ceiling, a wide request exhausts connection pools and trips provider rate limits under exactly the load where it matters most. With a ceiling, the same load produces a slower response that still completes. Turning a failure mode into a latency mode is almost always the correct trade in a user-facing path.
- · 7 min read
Four Mechanisms, Four Numbers: Why One Reliability Metric Hides the Work
An integration layer that improved API success, end-to-end failure, duplicate results and empty responses did so through four separate mechanisms. Reported as one number, you cannot tell which part earned its keep, you cannot tell when one regresses, and you cannot defend the architecture. Measure each mechanism on its own, and the gap between two of the numbers becomes the most informative thing in the report.
- · 7 min read
The Seam Is Nobody's Job: Why Failures Live Between Systems That Each Work Correctly
Three systems, each owned, each correct by its own contract, each reporting success. The failure lives in the relationship between two of them, and relationships are not assigned to anyone. That is why these defects survive code review, pass every component test, and are found by a customer rather than by a team.
- · 6 min read
Who Hears About the Failure First: Five Ways to Buy the Same Integration
The same piece of work can be bought from a platform, an agency, a specialist, a generalist or in-house, and the engineering is similar in all five. What differs is who finds out when the boundary between two systems breaks, how long it takes them, and whether anyone is contractually obliged to care. Choose on that rather than on price.
- · 6 min read
Exactly-Once in Effect Is Not Exactly-Once, and the Difference Is Where Your Ledger Stops
Deduplicating on an event identifier and deriving state from an append-only ledger gives you exactly-once behaviour over an at-least-once unordered stream. That is the strongest thing available and it rests on one assumption: that the identifier is a sound deduplication key. Name the assumption, because the cases where it fails are real and the backstop is reconciliation rather than the handler.
- · 7 min read
Human in the Loop or Safe State: Choosing Your Fallback
When a system cannot proceed safely, it has two options: hand the decision to a person, or take a defined safe action itself. Which one is correct is decided by whether a person is reachable inside the time the situation allows, and that single test resolves most of the argument.
- · 18 min read
A Test That Has Never Failed Is a Decoration
A passing suite, a clean demo and green CI are evidence of nothing until somebody has watched the check go red on a known broken input. Passing is a property of the test, not of the code. The only credible proof any check works is a negative control: break the thing it guards and confirm the check fails.
- · 6 min read
Durable Execution, Idempotency, or Both
A workflow engine guarantees your process resumes. It does not guarantee your side effect happened once. Those are different properties solving different halves of the same failure, and buying the first while assuming it delivers the second is the most common way a durable system still double-charges someone.
- · 6 min read
Perception Accuracy Is Not Control Safety
A 99 percent accurate detector is not a 99 percent safe robot, and the gap is not a matter of degree. Safety depends on which errors occur, how they are distributed in space and time, what the system does when it is uncertain, and whether the safe behaviour is enforced somewhere the perception stack cannot override.
- · 7 min read
Reconciliation Is Not a Nice-to-Have
Prevention mechanisms fail silently. Reconciliation is the only part of a money-moving system that can tell you they did, and it is the component most often deferred, because it produces no feature and its value is invisible on every day it finds nothing.
- · 7 min read
Idempotency for Money Movement
An idempotency key is not a header you add. It is a claim about what constitutes the same operation, and almost every double-charge traces to that claim being wrong: the key was generated per attempt instead of per intent, or the deduplication window closed before the retry arrived, or the key covered the request and not the effect.
- · 7 min read
The Update That Bricks the Fleet: OTA Failure Modes
An over-the-air update is the only operation where a bug can remove your ability to fix the bug. That single property should determine the entire design, and it produces requirements that look excessive until you consider what the alternative costs: a truck roll per unit, or a fleet you cannot reach at all.
- · 7 min read
Systems You Cannot Take Offline to Fix
Most engineering practice assumes you can stop the thing to work on it. Remove that and the entire method changes: you diagnose from passive observation, you change one variable per window, you validate in shadow before you commit, and you design every modification to be abandonable halfway through.
- · 7 min read
Desired State: How Fleet Systems Made Double Execution Impossible
Infrastructure engineering solved a problem AI agents are currently rediscovering. Declaring the state you want, rather than the action you want taken, makes repeating an operation harmless by construction. The interesting part is not the idea. It is exactly which properties do the work, because two of the three are usually missing when people borrow the pattern.
- · 7 min read
Fleet Scale Changes the Failure Mode, Not Just the Number
A platform that works at a hundred nodes and fails at twenty-five thousand did not run out of capacity. It met failures that do not exist at small scale: monitoring that damages what it monitors, silence that no poller notices, and heterogeneity that only appears once the sample is large enough to contain it.
- · 7 min read
What a Minute of Line Downtime Buys You in Architecture
Downtime on an automated line runs from hundreds of thousands to millions of dollars an hour. Convert that to a per-minute figure and it becomes an engineering budget, which changes what is worth building. The interesting consequence is not that you should spend more. It is that the false-positive and false-negative costs are wildly asymmetric, and almost nobody sets the operating point from the plant's economics.
- · 7 min read
Why Air-Gapped Changes Every Assumption in Your ML Pipeline
An air gap is usually treated as a deployment constraint, something to solve at the end with a USB drive and a procedure. It is not. It invalidates assumptions at every stage of the pipeline: how you get data, how you version artifacts, how you know what is running, how you evaluate, and how you find out anything went wrong.
- · 7 min read
AI at the Edge With No Network and No Retry
Every convenience in a cloud AI stack is a form of retry: call again, fall back to a bigger model, log it and fix it tomorrow. Remove the network and all of them go at once. What remains is a system that has to be right the first time, inside a power and latency envelope decided by hardware choices made months before anyone wrote inference code.
- · 7 min read
Your Green Dashboard Is Not Evidence
Monitoring answers whether the system is running. Evaluation answers whether it is right. Those are two different dials and almost every organisation has built only the first, which is why the honest sentence after an incident is not that monitoring failed but that nothing was ever watching the thing that broke.
- · 7 min read
When Not to Ship an Autonomous Agent
There is a test that decides it, and it is not about model quality. If you cannot compute, in code, a number that tells you whether the task is closer to done, you cannot build a reliable agent for it yet. The honest move is a bounded assistant with a human terminal state, which is not a lesser product. It is the same capability with the failure mode removed.
- · 7 min read
Five Questions for Your Next AI Design Review
You should not have to read a trace to know whether an agent is safe to ship. Five questions, none of them technical, each with a right answer and a recognisable wrong one. They take ten minutes and they find the failure modes that pass every demo, because the failures live in what the system does when it does not succeed.
- · 8 min read
The Verifier That Verifies Nothing
Naming a pipeline stage 'verifier' does not make it one. If the stage is another model call asked whether the output looks right, it shares the generator's blind spots, produces an opinion rather than a check, and has almost certainly never rejected anything. There is a ladder of verifier strength with five rungs, and most production systems are on the bottom one while believing they are near the top.
- · 7 min read
The Five Ways a Loop Fails to Stop
Floyd gave us the conditions a terminating loop has to satisfy in 1967. Negate them one at a time and you get an exhaustive list of the ways termination can fail, which turns a vague symptom into five named diagnoses with five different fixes. Your agent is almost certainly number four, and number four is the only one that looks like success.
- · 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
Rebuild or Repair? How to Tell Before You Approve Six Months
Two contractors quoted four and six months to rebuild a model. The actual fix took five days and was not the model. The decision between rebuilding and repairing is not a judgement call, it is a diagnosis you can run in an afternoon, and running it first is the difference between a five-day fix and six figures spent reproducing the same failure.
- · 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.
- · 9 min read
You Cannot Hire a Gap: Why Cross-Layer Failures Have No Owner
The analog engineer designed a correct reference loop. The actuation engineer designed a correct current source with a safety limit. The mechanical engineer placed the electrodes correctly. Every one of them did excellent work inside their lane, and the device failed, because the failure lived in the loop connecting all three and that loop was on nobody's schematic. A seam is not a gap in anyone's competence. It is the region between all of your competent people.
- · 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.
- · 7 min read
Your Bill of Materials Passes and Your Board Is Still Wrong: Topology vs Parts
Two current-limit resistors in series for redundancy is good design. The same two resistors, both the correct value, placed in parallel instead, quarters your limiting and roughly doubles the current. Every part inspection passes, because both resistors are the right value and the bill of materials is correct. The failure is not in the parts, it is in the topology, and your incoming checks do not look at topology.
- · 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
Shadow and Canary: Shipping an AI Change Without Betting the Business
Two unglamorous techniques between a change and everyone. Shadow runs the new version against real traffic without showing anyone the results, so you find out how it behaves on production inputs before a single user sees it. Canary releases it to a small fraction with an automatic undo. The alternative, which is what most teams do, is to flip it on for everyone and hope.
- · 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
Your Agent Is Missing a State: Done, Gave Up, Killed
Chess has a draw, which is not a loss. A solver returns unknown, which means it ran out of budget and not that no answer exists. A database names a deadlock victim so the transaction knows it was killed. Your agent has two states, done and killed, and when the cap trips the run must be filed as one of the two it has a name for, so it gets filed as done. Everything downstream believes it.
- · 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
Agents Take Actions That Can't Be Undone: Designing for Irreversibility
A chatbot writes words, and if it is wrong you delete it. An agent acts: it sends the email, charges the card, deletes the record, places the order, and those actions turn one way at machine speed. In 2012 an automated trading system shipped a bad deployment with no kill switch and lost 440 million dollars in about five minutes. The code was the last domino. The failure was the system that let it run with no brakes.
- · 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.
- · 7 min read
The Cloud Hides Your AI's Real Failures
Four properties of every model are always present and almost never visible: it extrapolates past its data, it discards most of your input, it is memory-bound on a shared bus, and its confidence off-distribution is undefined. A cloud environment hides all four, because a retry, a redeploy, a bigger box, and a human on a dashboard tomorrow each absorb one. Take the second chance away and they stop hiding at once.
- · 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.
- · 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.
- · 9 min read
Index Freshness and Drift: Why a Working RAG System Quietly Goes Wrong
A RAG system that works today degrades quietly as its documents change. There are two kinds of drift: the easy one, where the questions start looking different, and the nasty one, where the questions look identical but the right answer changed underneath. The fix is re-checking on a schedule against a baseline, and never auto-rebuilding when the alarm fires, because half the time it is a data-plumbing break, not a real change.
- · 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.