The viral pitch says an agent can run a business end to end while you sleep. I ran a much smaller experiment. One document-intelligence pipeline, the live demo on this site, deployed to Fly.io on June 27. No customers depending on it, no revenue attached, one engineer watching it. If anything can run itself, it is this.
Here is the incident log from its first week. Every entry is a real commit in the repo.
Day 3: the model was retired out from under us
On June 30, queries started failing with 404s. Nothing in the pipeline changed. Nobody deployed. Google retired the gemini-2.0-flash snapshot the demo was pinned to, and the endpoint we depended on stopped existing.
The fix took two commits: move to the current model, then repoint to the gemini-flash-latest alias so the next snapshot retirement does not take the demo down with it. Minutes of work, once a human noticed.
Sit with that one. The core dependency of every agentic system is a model with a lifecycle you do not control. Providers retire snapshots on their schedule, not yours. An unattended system does not migrate itself off a dead endpoint. It returns errors until someone looks.
Day 3, again: the failure that threw no error
Same day, different class of failure. In light theme, the chat answer rendered white text on a white background.
Every metric was green. Requests returned 200. Tokens were billed. Answers were "delivered." A user on light theme saw an empty box where the answer should be. No exception, no log line, no alert. The system was working perfectly by every measure the system had.
This is the failure mode that should scare you about unattended operation. Crashes page somebody. Silent failures bill you while quietly convincing every user your product does not work.
Day 4: paying to be ready
The demo ran on scale-to-zero infrastructure: machines spin down when idle, spin up on request. Free-ish when nobody visits. The first visitor after an idle period paid the boot time plus the model call, and the demo felt broken exactly when it mattered, in front of someone deciding whether to trust it.
The fix was one line: keep one machine always warm. The consequence is the point: the meter now runs 24/7. "Free because open source" and "instantly available" are opposites. Availability is a recurring line item, even for a toy.
Day 4, again: the timeout was tuned for a different model
The pipeline's time-to-first-token budget was set for a model that starts talking fast. The current model is a reasoning model. It spends around 9 seconds thinking before it answers, which is most of the end-to-end latency, and it was regularly blowing the budget on legitimate requests.
Raised the budget to 20 seconds. Trivial fix, uncomfortable lesson: latency characteristics are part of model drift. Every timeout, retry policy, and queue depth you tuned for model A is a latent bug waiting for model B. A version bump is not just a quality change, it is a performance regression test you did not run.
Found during launch hardening: the rate limiter throttled the wrong party
One more, caught a day before launch. Per-IP rate limiting was keyed on the connecting peer's address. Behind Fly's proxy, that address is the proxy, not the visitor. Every user on the demo shared a single rate-limit bucket. One curious person hammering the API would have throttled everyone.
The fix reads the real client IP from the Fly-Client-IP header. The lesson generalizes: every piece of infrastructure between you and your user lies to you about who the user is, and an agent acting on that lie acts on the wrong person.
The arithmetic of "unattended"
Count it. A system with no customers, no money moving through it, and an owner who reads its logs needed five human interventions in seven days. Each one was cheap to fix, minutes to hours, because a human noticed quickly, diagnosed it, and shipped.
Now remove the human, the way the pitch says you can. The 404s continue until every user has left. The white-on-white answers keep billing tokens for output nobody sees. The rate limiter keeps punishing the crowd for one visitor's curiosity. None of these repair themselves, because the system does not know it is broken. That is the defining property of the failures that matter: they do not announce themselves, so someone has to be looking.
There is also housekeeping nobody mentions. Uploaded documents accumulate until a cron job expires them. Workers die and need a supervisor watching heartbeats to restart them. Boring, invisible, and mandatory. Unattended systems do not do their own chores.
This is not an argument against shipping AI systems. I shipped this one and it answers questions right now. It is the argument, with receipts, from the first article in this series: the narrow loop works when an eval gate sits in front of the model and an accountable human sits behind it. Week one is when you find out whether anyone is actually behind it.
The full version of how I run these systems, with the runbooks, eval reports, and architecture decision records, is in the operator brief. The demo that generated this incident log is one click away. Both are the receipts for the same claim: production is a practice, not a deploy.