Zero to Autopilot, Part 9: Anatomy of a $25 AI Company

Series: Zero to Autopilot — Building a Self-Improving AI Media Channel. Part 9 — the internals. Part 8 told the story; this one opens the machine. Full prior arc: Part 1 … Part 7.

Data status: real-now — real runtime config and code from the repo. Open source.

In Part 1 the interesting claim was that the thing runs itself. Here I want to answer the engineer's next question: how? Not "an LLM does it," but the actual mechanics — how a goal becomes tasks, what the company remembers, how an agent decides what to do when it wakes up, and how the pieces hand off without stepping on each other. I'll name the theory where it's useful, because it turns out this design maps onto a well-worn stack, and the places where it doesn't are the interesting ones.

Everything below is the real runtime (Paperclip): a local daemon plus an embedded Postgres, agents that are Claude Code sessions, and a company you can read as a folder.

1. The goal, and how it becomes tasks

The company has a goal tree. At the root: unlock YouTube monetization. Under it, child goals — reach 1,000 subscribers, reach the watch-time threshold. Each is a row with a level (company / team / agent / task) and a parentId, so goals form a hierarchy.

Here's the part people assume and get wrong: the runtime does not decompose the goal into tasks. There's no planner reading the goal and emitting a work breakdown. A goal is just data. The only link between a goal and the work under it is a single field on each ticket — goalId — that an agent stamps when it creates the ticket.

So how does the goal actually produce today's three video ideas? Through a prompt. The Growth Lead agent's instructions say, in effect, "own progress toward this goal." When it wakes, it reads the goal's metrics and the channel state, reasons about the most useful next move, and creates the tasks itself — a script here, a measurement there — each tagged with the goal. The decomposition lives in an agent's head, not in the scheduler.

The classic vocabulary for this is worth borrowing. Planning theory calls the ideal goal-driven decomposition by an orchestrator that owns "high-level task comprehension, planning, and decomposition," and it warns that planning should be a pipeline, not a prompt — something you can instrument and constrain (survey, arXiv:2602.10479). The Belief–Desire–Intention model gives the cleanest frame: desires = the goal and its constraints, beliefs = world state and memory, intentions = the plans and tool-calls the agent commits to ([CoALA-adjacent; ChatBDI, AAMAS 2025]). Map that onto the company: the goal tree is desires, the tickets and journal are beliefs, the assigned issues are intentions.

The honest divergence: Paperclip's decomposition is a prompt, not an instrumented pipeline. The goal steers behavior only as much as the Growth Lead's prompt makes it, and goalId is a flat tag with no automatic roll-up of task completion into goal progress. It's cheaper and it works, but it's the weakest joint in the system. The goal is scaffolding, not control flow. (Progress toward the goal is measured separately, by the marketing engine, not computed by the runtime from closed tickets.)

2. Two kinds of memory

Ask "where's the memory" and the surprising answer is: there's no vector store, no embeddings, no "agent memory" module. There are two plain stores doing two different jobs.

Coordination memory is the tickets and their exhaust, all in Postgres: issue comments (the reasoning and handoff ledger), issue documents (durable artifacts like a plan or spec attached to a ticket), the activity log (an append-only audit stream), and per-run NDJSON transcripts (the black-box recorder of every agent turn). This is "who did what, why, and what's attached."

Learning memory is a separate file the marketing engine owns — the journal — holding every bet, its measured metrics, a virality score, and the strategy the company has learned (winning patterns, losing patterns, seeds for the next idea). This is "what actually works."

The split is deliberate, and the theory backs it. Cognitive-architecture work (CoALA, arXiv:2309.02427) tiers agent memory into working (the ephemeral context of one decision), episodic (time- and task-indexed experience), semantic (durable knowledge), and procedural (skills/code). Paperclip's stores land on that grid cleanly: working memory is the context assembled for one heartbeat; the comments, activity log, and run transcripts are a genuine episodic store (they're literally indexed by when and which task); documents and the journal's strategy are semantic; and the agents' instruction files are procedural. Multi-agent memory research adds a rule Paperclip follows by accident: keep memory two-layered — a shared global layer plus a local per-agent layer — because fully-shared memory homogenizes agents and erodes role specialization ([LLM-MAS memory survey]). The per-agent instruction bundle is that local layer; the tickets and journal are the shared one.

The divergence here: nothing consolidates. Comments and activity grow without bound; there's no summarize/forget/prune policy, which the literature flags as a drift-and-bloat hazard ([MemGPT, arXiv:2310.08560]; [MemInsight]). The company's only real "consolidation" is the Analytics agent periodically distilling measured bets into updated strategy. For a small channel that's fine. At scale it wouldn't be.

3. How an agent decides what to do

Agents aren't long-running processes polling a queue. Each is dormant until woken, runs one heartbeat — one Claude Code process — then exits. So "decision-making" is per-wake, and the whole company is a set of stimulus→response reflexes over tickets.

Four things wake an agent:

• assignment — set a ticket's assigneeAgentId to the agent. This is the backbone: reassign a ticket, the new owner wakes. It works even with idle heartbeats off.
• schedule — a cron routine fires and creates a ticket assigned to an agent (the daily 9am kick to the Growth Lead).
• idle heartbeat — a per-agent self-wake on an interval. I turned these off; ~240 no-op wakes a day is pure token burn and the chain runs fine without them.
• mention — an @handle in a comment. Unreliable: a wrong handle wakes nobody, which is exactly how QA gates silently stalled until I switched handoffs to reassignment.

On wake, the runtime injects context — PAPERCLIP_WAKE_REASON, PAPERCLIP_TASK_ID, the issue to act on, the workspace. The agent's opening move is a fixed reflex I can see in the transcripts: "new heartbeat — check env and inbox." If there's a task, work it. If nothing is assigned and there's no wake context, exit. (This is why firing a bare heartbeat at the Growth Lead did nothing once: with no driver ticket, it correctly no-ops. You steer this company by creating and assigning tickets, not by poking agents.)

The tidy way to describe the loop is a POMDP control cycle: perceive → update memory → decide → act, feeding measured feedback back in (arXiv:2601.12560). Each heartbeat is one timestep of that; the "update memory" step — reading the ticket's comments and documents before acting — is retrieval-augmented generation by another name. The control style is firmly reactive/event-driven, not a central deliberative planner. That's a deliberate trade: it's cheap, cron-friendly, and reproducible, at the cost of the instrumentable planning stage the theory would prefer.

4. Coordination: tickets, not chatter

The company coordinates through one artifact (the ticket) and one signal (assignment). A handoff is literally: change the ticket's assignee, which wakes the next owner. Comments are advisory (reasoning, mentions), not a transport. Documents are the artifacts that ride along. One agent owns a ticket at a time, enforced by an atomic checkout lock.

In the taxonomy of multi-agent shapes — chain, star/hub-and-spoke, mesh — this is a star (the Growth Lead orchestrates) using ticket coordination rather than a blackboard or message-passing.

Topology isn't cosmetic: it measurably affects both goal attainment and cost, and dense mesh topologies burn 2–12× the tokens of a chain (arXiv:2601.12560; [arXiv:2505.22467]). Tickets are on the cheap end, which is part of how the bill stays at $25.

The satisfying part is that the two classic failure modes of an orchestrator-worker company are named in the literature, and Paperclip's design is exactly their prescribed mitigations (arXiv:2602.10479; silent failures are ~75% of multi-agent errors, [arXiv:2606.08162]):

• Silent worker failure — a worker stops, the orchestrator assumes progress. Mitigation: heartbeats plus "never end a turn with an in-flight ticket." Paperclip has both, plus an Observability agent that hunts stuck tickets. The one rule every agent's prompt repeats is: before you exit, set the ticket done or blocked — never leave it hanging.
• Goal-semantic drift, the "telephone effect" — the goal's meaning degrades as it passes down layers. Mitigation: periodic re-alignment to the root goal. That's the Analytics agent measuring every bet against the goal's real metrics and rewriting strategy — a re-grounding step baked into the loop.

5. Why the guardrails live in code, not the prompt

This is the lesson I earned the hard way, and the one place the theory is bluntly prescriptive. Stability against drift comes from bounded autonomy: hard limits on tokens, time, tool-calls, and money; fail-safe termination; and, critically, policy-mediated tool execution and observability as first-class requirements (arXiv:2602.10479; [Agent Contracts, arXiv:2601.08815]).

Paperclip runs each agent as a Claude Code session with dangerouslySkipPermissions on. Which means the agents' tools are not policy-mediated. And it shows: the Producer's prompt clearly said "never commit to the main branch" and "never git add -A," and an agent did both anyway — one of them swept a live API token into a commit, caught only by a push-protection hook. A per-video budget wasn't passed once, so a producer generated premium AI video on all nine scenes and a single Short cost $2.81 instead of twelve cents.

The fix in every case was the same shape: stop asking, start enforcing. A pre-commit hook now blocks secrets and direct-to-main commits regardless of what any agent intends. Channel runs now derive their spend cap from the budget automatically, so the expensive default can't apply. None of that lives in a prompt, because a prompt is a suggestion an LLM will cheerfully ignore in the same breath it agrees with it. Creative latitude belongs in the prompt; rights — spending money, publishing, touching git — belong behind code you control.

What the design gets right, and where it's thin

Mapping the whole thing back to the literature, the scorecard is honest:

• Right: the org shape (a star with ticket coordination) and its two failure modes are textbook, and the mitigations — heartbeats, "never leave a ticket hanging," and goal-re-alignment through measurement — are exactly what the theory prescribes. The two-memory split (coordination vs learning) and per-role local prompts match best practice. The per-heartbeat POMDP loop is a clean, cheap control model.
• Thin: goal→task decomposition is a prompt, not an instrumented pipeline, and goalId is a flat tag — the goal is scaffolding, not control flow. Memory never consolidates. Tools aren't policy-mediated, so safety has to be bolted on from outside.

That last gap is the whole thesis in one line: an agent company is only as safe as the code around it, not the instructions inside it. The interesting engineering isn't the agents — it's the harness that lets you trust them with the publish button and the credit card.

---

That's the machine. If you want the story instead — the overnight ships, the two times I stepped in, the receipts — that's Part 8: The $25 Company.

⭐ Repo: github.com/dasein108/slope-studio — the company package, the agents, the pipeline.
📚 Foundational build log: the Zero to Autopilot series, Part 1.