Most "AI agent" demos die at the same place: a tweet, a screenshot, a five-minute video. Then the founder closes the laptop and the agent quietly stops existing.

I wanted to know what it actually takes to keep an agent running for a month — not "working in a Jupyter notebook for an afternoon," but on for 30 consecutive days, processing real inputs, surviving real failures, without me babysitting it.

The headline answer: the model isn't the hard part. The hard part is the eight unglamorous engineering decisions you make before the agent ever generates a token.

Here's what shipped, what broke, and what fixed it.

The setup

One agent. Scheduled job, runs every 6 hours. Job: pull a queue of unread customer support emails, classify them, draft a reply for the human to review, and tag the thread. Stack: OpenClaw runtime, Sonnet as the model, Postgres for state, Docker container with a restart policy. Boring on purpose.

Why this specific job? It's the kind of workload that actually has a budget attached. Nobody pays $99/mo for a chatbot that does nothing. They pay for a thing that processes 200 emails a night while they sleep.

What broke (and what fixed it)

1. The agent forgot it was a process, not a script

First crash: day 4. The container OOM-killed itself loading a 300-email batch into memory at once. The agent had been written like a Python script — "read everything, process everything, write everything."

Fix: queue plus worker, with explicit checkpointing after every N items. If the worker dies on item 47, the next run picks up at item 48. This is so obvious in retrospect that it's embarrassing, but every first-pass agent I've reviewed makes this mistake.

The pattern that works:

for batch in queue.pull(limit=10):
    for item in batch:
        result = agent.process(item)
        db.write_result(result)
        db.mark_done(item.id)  # commit point

The commit point is the whole game. No commit point means the agent has to redo work on restart. No redo means lost work. There is no third option.

2. The retry loop became a money fire

Day 9: I woke up to a $40 inference bill from the previous night. The agent had hit a model timeout on one weird input, retried infinitely, and burned through tokens.

Fix: exponential backoff with a hard ceiling. Three retries, then dead-letter the item with the full input attached so I can debug. The dead-letter queue is the unsung hero of agent reliability — it turns "agent failed silently" into "agent failed loudly, in a place I can see."

3. State drift across restarts

Day 14: the agent started replying with stale facts. Turned out it was caching the customer's previous order details in memory, and a container restart wiped the cache mid-conversation. Replies were referencing orders the customer had already received and forgotten about.

Fix: treat in-memory state as a lie. Anything the agent needs to remember across runs goes in Postgres before the next inference call, not after. If I cannot survive a kill -9 between any two lines of code, I have not built a long-running agent — I have built a long-running prototype.

4. The "it works on my laptop" infrastructure tax

Day 19: I tried to hand the agent off to a non-technical operator to run on their own. They could not. They did not know what docker compose up meant, did not have a Postgres instance, did not want to learn what an environment variable was.

This was the moment I stopped pretending the model was the product. The product is the operating environment — the thing that makes the agent run for someone who never opens a terminal. That is the actual moat, and it is where most of the "AI agent" market is going to consolidate over the next 18 months.

If you're building this layer yourself, you have signed up to operate infrastructure for the rest of your life. If you don't want to do that, managed OpenClaw hosting exists for the same reason managed Postgres exists. You don't run your own database server in 2026 unless you have a very good reason.

The boring uptime math

After the four fixes above, the agent ran the remaining 11 days without intervention. Final tally:

• Total scheduled runs: 120
• Successful completions: 117
• Dead-lettered items: 14 out of roughly 6,000 (0.23%)
• Human interventions required: 3 (all dead-letter triage, took ~10 minutes total)

That ratio — three interventions in 30 days — is the only number that matters to the buyer. They don't care which model you used. They care whether the thing keeps running when they go on vacation.

What this means if you're shipping an agent

The next wave of agent winners aren't going to be the ones with the cleverest prompts. They're going to be the ones who treat the agent as a long-running process — checkpointing, dead-lettering, observability, snapshot/rollback — and ship that whole stack as the product.

If you want to skip the four lessons I learned the dumb way, the Builder Sandbox tier gives you a MicroVM with sudo and live port-forwarding, and the Dev Agent tier adds observability and snapshot/rollback. That's the layer you actually want when there's a paying customer's workload on the other end.

Either way, the lesson is the same: agents don't fail because the model is bad. They fail because nobody wired up the boring stuff. Wire up the boring stuff. The model is the easy part.