What a Year of Running Production AI Agents Taught Me About Reliability
The hardest part of building with AI agents isn’t getting them to work. It’s noticing when they’ve quietly stopped.
For the past year I’ve run a stack of autonomous agents that trade real money across crypto venues — prediction markets, perpetual futures, on-chain vaults. Not demos. Agents that place orders, size positions, and review their own performance on a schedule, while I sleep in a different timezone. a16z’s “Big Ideas 2026” calls this year the one where “vertical AI goes multiplayer” and agents become economic participants. YC’s W26 batch funded an entire cluster of agent-swarm trading funds. The narrative has caught up to what a handful of us were already doing in production.
So here’s what nobody puts in the pitch deck: the lessons that actually matter for shipping agents are not about intelligence. They’re about reliability. Here are the five that cost me the most to learn.
1. Agents fail silently, and silence is the most expensive failure mode
A demo agent fails loudly — it throws an error, you see it, you fix it. A production agent fails silently. One of mine hit an unhandled edge case and stopped placing trades. It didn’t crash. It didn’t alert. It just… did nothing, for over 30 hours, while I assumed it was working. No trades looks identical to a quiet market until you check.
The fix wasn’t better code. It was a watchdog that alerts on the absence of expected activity — “this agent should have evaluated N opportunities by now; it evaluated zero; something is wrong.” Most teams instrument errors. Almost nobody instruments silence. For any agent doing real work, expected-throughput monitoring matters more than error logging.
2. “It works in backtest” is a different claim than “it works”
I had a strategy with a beautiful backtest. When it went live, a model that estimated execution costs turned out to be off by 266% — it dramatically under-counted real-world slippage. The edge was real on paper and gone in practice, entirely inside the gap between simulated and live conditions.
The PM lesson generalizes far beyond trading: the environment your agent was evaluated in is never the environment it runs in. Eval scores, sandbox demos, golden datasets — they all measure a world that doesn’t have real latency, real adversaries, or real cost. Before trusting any agent, I now ask: what’s the delta between the conditions it was measured in and the conditions it’ll operate in? That delta is where products die.
3. Build the kill switch before you build the strategy
One of my strategies — a cross-venue arbitrage play — looked great for two days, then started bleeding. A halt mechanism I’d built before launch fired automatically and shut it down. I went back and computed the counterfactual: if the kill switch hadn’t fired, the position would have gone from +$5 to −$13. The guardrail was worth more than the strategy.
Agentic products invert normal software priorities. In a CRUD app, you build the feature and add error handling later. With an agent that acts in the world, the guardrail is the feature. Spend limits, action allow-lists, circuit breakers, “stop if you’re losing” — these aren’t safety theater, they’re the thing that lets you sleep. I now write the kill criteria before I write the agent.
4. Multi-agent systems need a global off-switch, not just local ones
When I had one agent, stopping it was easy. When I had eight, sharing capital and infrastructure, I discovered they had correlated failure modes — a shared dependency, a common data feed — and no single command to stop all of them at once. a16z’s framing of “multi-agent multiplayer” is exactly right, and the unglamorous truth is that orchestration’s first job isn’t coordination, it’s containment. Before you let agents cooperate, make sure you can halt the entire swarm in one action. Most multi-agent demos can’t.
5. The most valuable output an agent produces is its reasoning, not its answer
The single best decision I made was forcing every agent action to emit why: the signals that fired, a confidence weight, the competing interpretation it rejected, and the explicit condition that would invalidate the decision. Garry Tan’s YC RFS for AI-native funds lists almost this exact stack as a hard requirement, and now I understand why. When something goes wrong — and it will — a logged answer tells you what happened. A logged rationale tells you whether the agent was wrong or just unlucky. Those require completely different fixes, and you cannot tell them apart after the fact without the reasoning trail.
For a product, this is also the trust surface. Users don’t trust agents that are right. They trust agents that can show their work — and that keep showing it on the trades they got wrong.
The common thread: a demo agent is judged by its best moment; a production agent is judged by its worst. The discipline that separates the two is almost entirely about observability, containment, and explainability — the boring infrastructure around the intelligence, not the intelligence itself.
The 2026 wave of agent products will be won by the teams that internalize this early. Intelligence is increasingly a commodity you can buy from a model provider. Reliability is the part you have to earn, in production, usually by getting burned. I’ve done a year of the getting-burned part. If you’re building agents that touch anything real — money, infrastructure, customer data — start with the watchdog and the kill switch. The clever part can wait.