The boring middle.

Most agent demos die in week three.

They don't die in front of a camera. They don't die at a conference. They die quietly, on a Tuesday morning, when the data shapeshifts by 2% and the model decides — for the first time in its short life — to invoke a tool with a slightly different argument shape than it did yesterday. The cron fires. The output is wrong. Nobody notices for an hour. By the time someone does, the agent has happily written 14 corrupted Notion pages and the slack channel that was supposed to ping you was silent because the error path forgot to.

This is the part nobody puts on YouTube.

The demo trap

The shape of an agent demo is well-established now. You record an early run. You catch a happy path. You speed it up 4×. You add a synthwave track. You ship it. It looks like the future.

What you're actually showing is a function that worked once, on the input you chose, with the model you had loaded that day. It is closer in nature to a magic trick than to a piece of software.

The hard problem isn't writing the agent that demoed well. The hard problem is writing the agent that runs every day for the next nine months — through model updates, schema drift, library breakages, vendor outages, a holiday weekend where your eval set silently rotted, and the morning your billing card expires.

A working axiom: if the agent doesn't survive its first model upgrade unattended, it was never a system. It was a sketch.

What "Tuesday" actually requires

In my experience, the difference between a Thursday-demo agent and a Tuesday-production agent is mostly:

1. Real evals. Not vibes. Not "I ran it ten times and it looked good." A versioned suite of inputs with expected behaviors and tolerances, that runs in CI on every prompt change, every model bump, every tool addition. The eval suite is the product.

2. Observability that isn't an afterthought. Every tool call logged, every reasoning step captured, every cost line attributed. You should be able to answer "why did the agent do that on May 14 at 09:02?" in under two minutes. If you can't, you're flying blind and your agent will start drifting before you notice.

3. A small, dumb, deterministic outer loop. The interesting reasoning happens inside the LLM. The reliability happens in the boring code around it — the retry policy, the timeout, the schema validation, the dead-letter queue, the dashboard. None of that is glamorous. All of it is required.

4. A human you can wake up at 3am. Yes, even for "autonomous" agents. The first version of every production agent I've shipped has a notify_human_if_unsure tool with a clear threshold. You graduate to fully unattended only after weeks of clean runs.

What I'm actually optimizing for

The metric I've started using internally is uptime in days without intervention. Not accuracy. Not p99 latency. Not even cost.

A new agent ships and the clock starts. Every time I have to manually fix something — a retry, a re-run, a re-prompt — the clock resets. The goal is to get every agent past 30 days clean before I declare it "done." Most agents I build take 3-4 attempts to get there.

The first version is always the fastest to build. The version that survives is the one that respects how often the world changes around it.

That, in the end, is the whole job.