Academy

99% Isn't Enough

The gap between a system that is usually right and one that can be trusted with consequential actions.

The Felesh team 5 min

A 99 percent success rate sounds exceptional on a benchmark leaderboard. In a live production environment, it sounds like a ticking clock.

Imagine an agentic system tasked with processing incoming support requests and adjusting billing records. It handles 99 tickets flawlessly. It reads the context, calculates a prorated amount, and updates the billing ledger. Then comes ticket number 100. Instead of applying a ten-dollar credit, it issues a full refund for a yearly enterprise contract. Or, instead of updating a secondary email address, it overwrites the primary administrative contact for an entire account, locking the customer out.

The hundredth row of the billing ledgerFour of the ninety-nine correct ledger rows: a prorated credit, an address update, and two ten-dollar credits. Ticket 100 asks for a ten-dollar credit, and the agent writes a full refund of 48,000 dollars on a yearly enterprise contract. The ledger accepts it, because nothing checks the payload before the write.billing ledger, ticket by ticket99 correct#96 prorated credit$4.20#97 address updatedno charge#98 billing credit$10.00#99 billing credit$10.00#100 ten-dollar credit$10.00#100 refund, yearly contract$48,000the ledger accepted it: nothing checked the payload
Ninety-nine correct ledger rows say nothing about row 100, which pays a full yearly refund instead of a ten-dollar credit.

When that happens, the 99 successful operations do not matter. The system is no longer trusted. The project is paused, the integration is rolled back, and the operations team returns to processing everything manually.

Industry figures suggest that well-tuned agentic systems can routinely reach accuracy rates in the high nineties. But statistical confidence is fundamentally different from operational trustworthiness. Large language models are inherently probabilistic engines. They do not fail gracefully, and they do not fail predictably.

When a system relies entirely on the probability that a model will construct the correct payload, a 1-in-100 — or even a 1-in-1,000 — failure rate is not a manageable edge case. It is an unacceptable tail risk. The core danger is asymmetry. You cannot know in advance which specific action will contain the hallucination. A catastrophic error often looks structurally identical to a flawless execution right up until the moment the system commits the change.

Planned and written payloads, field by fieldFour fields compared. The keys are identical: action, account, amount and term. The account is the same. Three values differ: the planned credit is written as a refund, ten dollars as 48,000 dollars, and monthly as yearly.fieldplannedwrittenactioncreditrefundaccountacme-0042acme-0042amount$10$48,000termmonthlyyearlysame keys, same order: the structure looks valid either way
The planned payload and the one that was written have the same fields in the same order, so nothing in the structure gives the error away.

Faced with this reality, the instinct is often to push for better prompts, larger models, or heavier fine-tuning. But the answer to unpredictable execution is not waiting for a hypothetical model that reaches 99.9 percent accuracy. The answer is architectural.

When an action is consequential, hard-to-reverse, or expensive, probabilistic execution is the wrong tool. These actions require deterministic guards.

A deterministic guard is a hard, non-probabilistic constraint written in standard code. It defines the absolute boundaries of what an agent can and cannot do, regardless of what the natural language model decides. Instead of granting an agent direct write access to a sensitive endpoint, the architecture shifts to a proposal model. The system operates in suggest-mode.

In this pattern, the agent still performs the complex cognitive labour. It gathers context across multiple data stores, determines the necessary steps, and constructs the required payload. But it is structurally prohibited from executing it. The agent proposes the action. A human operator reviews and approves it.

A proposal passes the guard before anyone approves itThe agent reads ticket 100, the contract and the ledger, and drafts a payload: refund, 48,000 dollars, yearly contract. A plain code guard holds any amount over 500 dollars for review. The operator approves it, and only then is the ledger written.agentreads ticketreads contractreads the ledgerdrafts a payloadticket #100proposalrefund$48,000yearly contractguardplain codeover $500?holds itoperatorapprovesledgerwritten once
The agent proposes, the guard holds anything over its limit, and the ledger is written only after a person approves.

For this review cycle to be efficient rather than exhausting, the agent must provide receipts. A complete, glass-box review record — the exact reasoning, the specific records consulted, and a preview of the intended state change — must travel with the proposal. The human operator does not have to rebuild the context from scratch or dig through raw system logs. They only need to verify the logic. The agent handles the heavy lifting of synthesis, and the human provides the final, deterministic judgement.

A review record for the refund proposalA review record with four parts. Reasoning: the ticket asks for a ten-dollar credit, and the refund rule is applied because the contract is annual. Records read: ticket 100, the contract ACME-0042, and ledger rows 1 to 99. Preview: a credit of 10 dollars becomes a refund of 48,000 dollars, a mismatch the reviewer sees at once.review recordproposal, not yet executedreasoningticket #100: $10 creditthe refund rule applies to annual contractsrecords readticket #100, ACME-0042, ledger 1 to 99previewcredit $10refund $48,000
The review record travels with the proposal: its reasoning, the records it read and the exact change it will make, so the mismatch shows in two lines.

This architecture is not universally applicable, and it is important to acknowledge its trade-offs. Inserting a human approval gate introduces latency. It creates friction in the loop.

For high-volume, low-stakes operations, deterministic guards and mandatory human reviews are pure overhead. If an agent is sorting a triage queue, applying metadata tags to incoming documents, or drafting internal summary notes, the cost of a wrong action is negligible. A mislabelled document can be fixed later. In these specific environments, a highly autonomous setup without human bottlenecks is simply better. The friction of a review step actively outweighs the benefit of absolute safety.

Deterministic guards earn their cost only when a wrong action carries a real penalty.

Where a guard earns its costFour actions, what a wrong one costs, and the route each takes. A wrong tag on an incoming document is fixed later, and a drafted summary is rewritten, so the agent runs alone. A refund on a yearly contract puts money out for good, and an overwritten admin email locks the customer out; both go through a guard and a human approval.actionif it is wrongroutetag a documentwrong tag, fixableruns alonedraft a summarysomeone rewrites itruns aloneyearly refundmoney gone for goodguard + approvaloverwrite admincustomer locked outguard + approval
Guards are for actions whose wrong result cannot be taken back; a mislabelled document can be fixed later.

Agentic operations scale only when trust scales. Building that trust means acknowledging the limits of probabilistic models and designing around them. Human operators and AI agents work best as peers on one cognitive substrate. The agent earns autonomy slowly, action by action, while the human operator retains control over the boundaries. By routing sensitive operations through hard constraints, teams can move fast where it is safe, and pause where it matters.

Start here →