Inner loop and outer loop
Definition: two loops that together let a fleet of agents keep working without a human carrying context between them. lauren-tan names them in 2026-10-05-youtube-poteto-software-factory and says she is not sure she uses the terms precisely, so treat them as hers.
- Inner loop (35:32): the agent engineers writing code toward a goal. “My inner loop is basically my agent engineers working on the code toward an intent, or a snapshot of my intent.”
- Outer loop: the context the codebase does not contain, bug reports and requests arriving in Slack, Linear, and X, plus email and calendar. Tools with connectors to those systems are “your outer loop” (41:03).
A stale snapshot needs a trigger
The inner loop works against a snapshot of intent, and a snapshot goes stale (35:50). New information comes to light and, unless a trigger pulls it in, you become the proxy who ferries it across: “you’re off in Slack or X gathering context about bug reports and feature requests, and you have to ferry that across to your agent” (36:07). Connecting the loops is what removes you (38:37): “how do I take information that my agent needs that I would otherwise have to pass it myself, and teach it how to do it? That removes me from the equation.” She dismisses the terms company brain and context graph as “unnecessarily complex or abstract” (38:22). The move is a trigger, not a graph.
The wiring she describes
A simple version (36:51): a Slack MCP, or your own harness with a subscription into one channel. Tell the agents to watch that channel, and on a bug report they go and triage it, reproduce the issue using the verification skills already built, and confirm the bug still exists on main rather than being a quirk of that user’s setup (37:28). Concretely (42:13) some Grok bots watch her Slack, X, email, and Linear on routines, and when one finds an issue it sends it to a cursor project. “Cursor projects are my inner loop and Grok bot is my outer loop” (44:03), and because the bot can message a project, you can create work without opening the editor.
The coordinator agent
A Cursor project is a coordinator agent in the cloud with its own computer (42:52): “It’s a manager of agents, like your executive chef, your chief of staff. It doesn’t do the work itself. It delegates and orchestrates and manages the work of sub agents.” On a burst of thirty related payloads it can pick among several agent topologies and distribute the tasks (43:39). The reason to group rather than spawn one agent per bug (44:33): one agent per task “loses the thread between them, you may duplicate work, or you may not think about the higher-level problem,” and several slightly different reports let it zoom out and find the real bug is elsewhere.
The buffer beats the immediate fix
Another trigger runs on a schedule, the ones she has tweeted about (47:24). A standing example (47:40): React has many footguns, and an agent scans for the bad patterns, but “I don’t tell it to fix the issue first. I tell it to append it to a document, and then every couple of days I look at it and see these are all the same thing. You almost want a buffer, a queue.” In pure execution mode you miss the big picture, and a buffer forces you to look for patterns you would miss solving each bug one at a time (48:22). The coordinator is the automated version of that forest view (48:54).
Related
- agent-verification-skill: what lets an outer-loop trigger close its own loop
- environment-and-constraints: context not control, which the two loops operationalize
- michelin-kitchen-metaphor: the pass, the expo, and running the orders
- trust-ladder-agents: connecting the loops is the high-rung move