# How to Get 1,000 AI Agents Working While You’re Offline > Source: > Published: 2026-09-23 16:32:22+00:00 Five or ten sessions running at once. Each one spinning off its own **sub-agents**. A few of them still working long after the laptop closes, checked from a phone instead of a desk. That is the actual shape of an overnight AI agent setup, once it is **built** **correctly**. The number attached to it gets all the attention: a **thousand agents**, sometimes more, running unattended while nobody is watching. The number is the least useful part of the idea. Almost nobody needs a thousand agents running at once, and the ordinary settings that make any number of them **safe instead of reckless** rarely make it into the retelling. Five agents running badly can already make a mess by morning. The same five, built on the **right settings**, scale to five thousand without changing shape. The architecture underneath breaks into five pieces, and every one of them already exists inside [Claude Code](https://docs.claude.com/en/docs/claude-code/overview). *Together with Granola:* **Your agents can touch everything except your meetings. That’s where your real context lives.** [Granola](https://go.granola.ai/theAIcorner) takes notes in the background, wherever you meet, then its [MCP integration](https://go.granola.ai/theAIcorner) connects them straight to Claude: ▫️ Works [everywhere](https://go.granola.ai/theAIcorner): Zoom, Meet, Teams, or in person on iPhone ▫️ Ask Claude to review last week’s client calls and update your CRM ▫️ Turn meeting decisions into [Linear tickets](https://go.granola.ai/theAIcorner), without copy-pasting a thing Free month with code **[THEAICORNER](https://go.granola.ai/theAIcorner)**. ## Table of Contents 1. Sessions, Sub-Agents, and the Phone in Your Pocket 2. Isolation Solves Files. It Does Not Solve Judgment. 3. The “Runs While You Sleep” Claim Has Three Different Truths 4. Don’t Let the Agent Grade Its Own Homework 5. Limits Have to Be Rules, Not Suggestions 6. What a Real First Run Looks Like ## **1. Sessions, Sub-Agents, and the Phone in Your Pocket** A **session** is the base unit underneath all of this, and it is smaller than the headline number makes it sound. Everything else here is really a decision about **how many sessions to run** and how closely they need to talk to each other. That **headline** number is really just this same decision, made many times over, until it adds up to something that sounds impressive from a distance. ### One Session Is One Focused Piece of Work Think of a session the way you’d think of a **browser tab**. That means **one open conversation**, working on one piece of work. Several sessions can run at **once**, each pointed at something different. Inside a single session, a task can be split into smaller independent pieces and handed to **sub-agents**, so several focused workers run in parallel without leaving that one conversation. The decision that matters: work that needs to see another piece’s **progress** in real time stays together, as sub-agents inside one session. Work that genuinely doesn’t depend on anything else becomes a separate session instead. ### The Screen That Makes “From the Phone” Literal The Claude app has a **coding tab** built for exactly this. It lists every active session, shows what each one is doing, and takes a correction or a fresh instruction typed straight into any of them, no laptop nearby. **That is the entire “from the phone” part of the claim**. A live window into work already happening, not a status dashboard dressed up to look impressive. Mixing up the sub-agent-or-session decision is the most common way parallel work turns into a mess. Five sub-agents told to edit the same files at once produce five different opinions about what the file should look like, and **reconciling** that afterward costs more time than the parallel work saved. None of this holds up at scale until the sessions stop stepping on each other’s files. ## **2. Isolation Solves Files. It Does Not Solve Judgment.** Multiple sessions working against the same codebase need a way to **avoid overwriting** each other, and there is a specific tool built for exactly that problem. ### Git Worktrees Keep Parallel Work From Colliding [Git worktrees](https://www.developersdigest.tech/blog/git-worktrees-claude-code-parallel-agents-guide) give each session its own working copy of the repository, on its own branch. One session builds a feature while another fixes a bug, and neither sees the other’s half-finished changes. This kind of isolation is already [built into](https://www.the-ai-corner.com/p/loop-engineering-coding-agents-2026) **[Claude Code](https://www.the-ai-corner.com/p/loop-engineering-coding-agents-2026)**. Nobody needs to hand-roll it. Worktrees solve a file problem, not a judgment problem. Ten sessions given ten slightly different instructions against the same repo return ten slightly different opinions about how the code should look, and somebody still has to **reconcile that by hand**. ### Where the Real Wall Sits Push much past four or five sessions hammering the same repository at once, and reviews slow down and usage limits get easy to hit. Not because anything breaks, but because coordinating that many simultaneous edits by hand **stops being realistic**. The **thousand-agent version** of this claim is almost never a thousand sessions arguing over one codebase. It is a thousand sessions each doing one small, independently checkable job. Researching one company out of a hundred. Triaging one ticket out of a thousand. Wide parallelism works beautifully on work shaped like that. It does not work on a single shared codebase, no matter how many sessions get thrown at it, because **somebody still has to read** every diff that comes out of it. The next question is what actually keeps any of this moving after the laptop closes. ## **3. The “Runs While You Sleep” Claim Has Three Different Truths** There are three distinct ways to make a task repeat itself, and only one of them **survives** an actual closed laptop. ### Two of the Three Options Still Need a Machine On The quickest option is a [loop](https://code.claude.com/docs/en/scheduled-tasks) inside a live session: a task repeats every few minutes or hours, for as long as that session stays open, up to three days at most. It disappears the moment the session closes. One level up is a **scheduled task** on a desktop. It survives closing the terminal and coming back later, and it reaches local files directly. The computer still has to be switched on for it to fire. **Both are genuinely useful**. Neither one is what “runs overnight with the laptop shut” actually describes. ### Only One Option Actually Survives a Closed Laptop A [routine](https://claude.com/blog/introducing-routines-in-claude-code) is a task saved to run on Anthropic’s own servers, on a schedule, triggered by an event like a pull request opening, or called through an API. Each run starts from a fresh copy of the repository rather than reaching into local files, and it can call cloud-hosted tools but not whatever only exists on a personal machine. No machine required at all, and no pause to ask permission mid-task, which is **exactly why** the next section matters as much as it does. The **honest version** of the claim: closing the laptop only works with a routine. Everything lighter than that is still tethered to a machine that has to stay on. A task running with nobody watching also needs a way to check its own work, and this is the step almost **everyone** skips. ## **4. Don’t Let the Agent Grade Its Own Homework** Ask the **same agent** that did a piece of work whether the work is any good, and it will tend to say yes. ### Why Self-Review Fails Exactly When It Matters Most Not out of dishonesty. It simply has no independent vantage point on its **own output**. **That blind spot gets worse, not better,** on anything [running unattended](https://www.softwareseni.com/how-to-run-ai-coding-agents-unattended-without-risking-your-production-systems/) for hours with nobody checking in. A fresh pass, ideally a separate session with no memory of how the first one got there, has a **real shot** at catching what the first pass missed. ### What an Independent Check Actually Requires The checking pass needs **something real** to check against: the actual test suite, the requirements written down beforehand, a specific list of criteria. Told plainly not to trust its own summary, and to say a claim can’t be verified rather than assume it worked, that single instruction **outperforms** every other setting in this piece combined. For code, this is fairly clean: tests pass or they don’t. For softer output, research summaries, written judgment calls, it gets harder, because a checker **cannot always confirm** a claim without redoing the very work the first pass just did. A second pass still catches what a tired first pass stops noticing, the same reason a second editor catches typos the writer no longer sees. Even a properly checked task still needs a leash, because unattended and unlimited **are not the same word**. ## **5. Limits Have to Be Rules, Not Suggestions** Every task left running unattended needs three numbers decided in advance, and they need to be settings the system enforces, not a polite sentence **buried in the prompt.** ### Three Numbers to Set Before Bed A limit on how long a task is allowed to run before it stops and **reports back** instead of pushing on. A limit on what it is allowed to spend, **based on real numbers** from a small test run rather than a guess. Cost also multiplies with concurrency in a way that is easy to **underestimate**. A limit that looks small for one task looks very different once fifty tasks are running it at the same time. **A short, explicit list of things it is never allowed to do without asking first: nothing deployed, nothing deleted, nothing sent externally, no money moved, without a direct yes.** ### Test the Failure on Purpose One task, on purpose, given an instruction **designed** to trip its own limit, before anything real gets handed over. A task that doesn’t stop **cleanly** **while being watched** will not stop cleanly on the ten tasks that aren’t. Skipping this step is the fastest way an overnight win turns into a **Monday-morning surprise.** ## **6. Your First Run** **This is not about the hypothetical number (1,000).** Ideally, you should be starting somewhere between 5-20 genuinely independent tasks, the kind that don’t depend on each other’s output. ### Start Small, Decide the Mechanism Up Front Write down what **“done”** looks like before starting, for every one of them, and hand that same description to whatever is going to check the work. Decide, task by task, whether it needs [a loop](https://www.the-ai-corner.com/p/loop-engineering-coding-agents-2026), a **desktop schedule, or a [full routine](https://www.the-ai-corner.com/p/claude-code-dynamic-workflows-6-patterns-14-steps-anthropic-engineers-2026)**. Set the time limit and the cost limit before bed, not after. ### Morning Review Beats the Completion Count **Morning review** should be the focus instead of completion count. Spot-check the actual evidence behind a few tasks marked done, not just the word next to them. Nearly every failure in a system like this traces back to the same handful of causes: - Scaling up before the checking step has been proven on a small batch - Treating a stop condition as a suggestion instead of a rule - Running tasks in parallel that **depended on each other** in ways nobody noticed until there were too many of them running at once to track by hand. It might not be exotic, but it is the same set of mistakes made delegating to a large team of people, compressed into a single night instead of a few weeks. Scale up when the **independent**, well-defined work actually exists to justify it, not because a bigger number sounds more impressive on a feed. Once a few small batches run cleanly, the checking step **catching real problems** and the limits actually firing when tested, the settings are worth revisiting rather than left untouched. What worked for twenty tasks needs re-checking before it gets trusted with two hundred. **The number was never the point.** The hours it gets back, the ones that used to disappear into work only one person could do slowly, that is the actual trade on the table.