[I Ran 5 AI Agents Unattended for 30 Days] What Actually Broke and What Held

When I tell operators their AI assistant will "just run 24/7," that's the promise. The reality is uglier — agents crash, sessions die, context windows fill up, model providers throttle, and your "automation" becomes a 3AM page.

Last month I gave myself a constraint: run 5 small agents unattended for 30 days as a solo founder. No babysitting, no manual restarts. One for inbox triage. One for monitoring a few competitor pricing pages. One for nightly browser-based status checks. One for code refactor batch jobs. One for content scraping.

Here's what actually broke, what held, and the reliability patterns I'd ship before letting a non-technical operator anywhere near an agent.

The four failure modes I hit (in order of frequency)

1. Context window bloat → silent degradation. This was the most insidious. The agent didn't crash — it just got progressively dumber. By day 4, the inbox agent was misclassifying obvious spam because the conversation history was bumping against the limit and the most recent emails were displacing the routing rules. No exception, no alert. Just bad work.

2. Model provider throttling. Day 11. Rate limits I didn't know existed kicked in mid-batch. The agent threw a 429, didn't have a retry path, and silently stopped processing the queue. I found out 6 hours later when the backlog showed up.

3. Auth token expiry. The scraping agent died on day 19 when a session cookie aged out. Standard problem, completely predictable, completely missed.

4. Memory leaks in long-running browser sessions. Headless Chrome doesn't love a 30-day uptime. Day 23, OOM. The monitoring agent took the whole VM with it.

The five reliability patterns that would have prevented all of it

These aren't novel — they're the same patterns you'd apply to any unattended workload. The new part is applying them to an LLM-driven workflow.

Pattern 1: Context rotation at fixed intervals. Don't let conversation history grow unboundedly. Snapshot the state you care about (decisions, rules, persistent memory), drop the rest, start a fresh context. For the inbox agent, every 200 messages = new context with a summary of routing rules pinned at the top. Simple, fixes the silent degradation problem permanently.

Pattern 2: Exponential backoff with provider failover. When your primary model throttles, fall back to a secondary. OpenRouter makes this trivial — you configure a fallback chain and forget about it. For most tasks, Claude → Haiku → GPT-4o-mini is plenty. The user never notices when the primary 429s.

Pattern 3: Health checks an operator can actually read. Not Prometheus, not Grafana. A status page that says "Inbox agent: last action 8 minutes ago" or "Pricing monitor: failed at 2:14am, retried 3 times, paged at 2:20am." The operator should be able to glance at it in the morning and know what to act on. If they have to interpret a graph, you've already lost them.

Pattern 4: Token refresh as a first-class concern. Auth tokens have expiries. Bake them into the agent's lifecycle: rotate proactively, never reactively. If your agent runs longer than your shortest token lifetime, you have a bug — even if it hasn't fired yet. Treat it like SSL renewal: scheduled, alerted, automated.

Pattern 5: Process-level rollback on resource thresholds. When memory or CPU breaches a threshold, snapshot the agent state, kill the process, restart from snapshot. This is boring infra work. It's also what makes the difference between "my agent ran for 30 days" and "my agent ran for 4 days, three times in a row."

What this looks like in a managed world

If you're an operator — not a developer — you don't want to set up any of this. You want your assistant to run, you want to know when it doesn't, and you want a vendor to fix the second case before you notice the first.

That's what managed agent hosting is supposed to solve. Not "we run a container for you" (that's just hosting). The actual job is the five patterns above, plus the 50 others I haven't written about yet, applied consistently so the operator never sees them.

I'm building toward this with RapidClaw — managed OpenClaw hosting tiered for SMEs. The Builder Sandbox tier ($99/mo, MicroVM with sudo + live port-forwarding) is where agents like the five above live. The Dev Agent tier ($200/mo) adds observability and snapshot/rollback specifically because patterns 3 and 5 above kept biting me during this test.

The boring stuff is the moat

The ambient-agent-does-your-job narrative is still mostly vibes. What's actually working in production today is the boring stuff — scheduled jobs that run reliably, browser automation that doesn't die overnight, coding agents that finish their refactor without losing the plot at hour 4.

That's not a sexy story. But it's the story that pays. The patterns above aren't novel; they're table stakes for any unattended workload. The reason most agent stacks don't have them is because most agent stacks are demos that got deployed.

If you're running agents yourself, the five patterns above are free advice — apply them, you'll have a better month than I did. If you'd rather not think about any of it, that's the pitch for managed agent hosting: the boring stuff, handled, so you can run 5 agents at once and not wake up at 3AM.

Either way: don't ship an agent into production without context rotation, failover, health checks, token refresh, and resource thresholds. The next 30-day uptime story you tell will be better for it.