Ask HN: Has anyone built an autonomous AI operator for their side projects?
I spent the last month building what I call an AI operator - an autonomous agent that manages my side projects end-to-end while I focus on strategy. It runs on a 30-minute heartbeat loop, publishes daily blog posts, monitors Stripe for sales, checks sites are up, and does directory submissions. It knows when to escalate to me (financial decisions, strategic pivots) and when to just handle things. The hardest part was writing the decision tree - not the AI itself but defining what it owns vs. what needs human judgment. Current setup: main agent handles orchestration, a builder sub-agent handles code/deploys, an amplifier handles content/social. Revenue is small so far ($200 from PDFs) but the system works while I sleep. Curious if others have gone down this path and what broke for you.
The 'decision tree' problem you're describing is fundamentally an authorization design problem. Natural language rules like 'escalate for financial decisions' work until edge cases show up — what's the threshold? What if the agent makes a series of small decisions that collectively cross a line no single action would have triggered?
What tends to work better than a natural language decision tree:
- Explicit capability grants: agent starts with zero authority, specific actions are granted not inferred - Threshold rules over judgment calls: not 'financial decisions' but '$X or more, always ask' (deterministic) - Audit-first for new capabilities: first N times an agent exercises a new type of authority, log for review before executing - Veto primitives: a way to interrupt mid-execution, not just pre-approve
The subtle failure mode to watch: an agent that gradually expands its interpretation of what's in scope because context accumulates and past decisions look like permission. It doesn't ask because prior runs didn't require asking.
The heartbeat/orchestration pattern you're using (30-min loop, sub-agents by function) is solid architecture. The authorization layer is usually what causes the hard-to-debug incidents. What did 'broke' look like when it happened?
depends on cost of running it and determining if ROI is there...