I ran 100 AI agents on one laptop. The hierarchy is what made the work usable

One model doing everything runs out of room before it runs out of ability

A single session that writes the code and then checks it reads far more than it produces. It opens files to find one function, runs a test suite to see one failure, and pulls a log to locate one line. All of that stays in the same context that holds the plan, the decisions made two hours ago and the rule it was told never to break. By the end of the session the model is not reasoning about the project. It is reasoning about a transcript of the project. I saw this as broken output rather than as a context problem. The work looked finished and was not: a change applied in one file and forgotten in the file that called it, a test marked as passing without being run, a rule from CLAUDE.md respected early in the session and dropped late. None of it came back as an error, which is what made it expensive. The correction is structural, not a stronger model. Move the reading out of the room where the decisions are made. Claude Code's subagent documentation names this directly: delegating an operation that produces a lot of output keeps that output in the subagent's own context, and only the summary returns. The lead then spends its room on judgment, which is the one thing it cannot delegate.

Delegation only works when the boundary is a permission

A subagent is defined in a file, .claude/agents/<name>.md for one project or ~/.claude/agents/<name>.md for every project. Four lines of frontmatter do the work: name identifies it, description tells the lead when to delegate to it, tools lists what it is allowed to touch, and model sets which model runs it. The body is its system prompt. The tools line is the part people skip, and it is the reason a hundred agents can be trusted with a project. A researcher declared with tools: Read, Grep, Glob, WebFetch can read anything and write nothing. A reviewer given Bash can run the test command and still not edit the file it is judging. This is a permission, so it holds when the model is wrong, when the instruction is ambiguous, and when the task turns out bigger than expected. An instruction that says please do not edit anything holds only while the model agrees with it. The lead keeps what cannot be split: the plan, the decisions between two acceptable approaches, the integration of results that arrive separately, and the final approval. Everything else is a delegation with a boundary. The documentation states that each subagent carries its own system prompt, its own tool access and independent permissions, so the boundary is real rather than a convention the run is expected to honor.

Fable 5.1 leads because the expensive thinking happens once

The model line accepts fable, opus, sonnet, haiku, a full model ID, or inherit to follow the main conversation. Claude Code resolves it in a fixed order: a model passed at invocation, then the frontmatter, then CLAUDE_CODE_SUBAGENT_MODEL, then the model of the main conversation. So routing is a property of the definition file, not something you have to remember to say. Anthropic's model overview is the basis for how I route. It recommends Claude Opus 5 for most workloads and Claude Fable 5.1 for demanding reasoning and long-horizon agentic work, which is exactly the shape of a lead that plans a large goal and then holds it across hours. It also lists the prices: 10 dollars per million input tokens for Fable 5.1, 5 for Opus 5, 2 for Sonnet 5 and 1 for Haiku 4.5, with Haiku on a 200 thousand token context window while the other three carry 1 million. That spread is the argument for a hierarchy rather than a fleet of equals. Planning happens once and its errors spread through every task after it, so it belongs to the most capable model available. Searching a repository, comparing two sources, summarizing a log and applying a repetitive edit are bounded jobs with a clear acceptance check, and they are the volume of the run. The documentation names cost control through faster, cheaper models as one of the reasons subagents exist. The cheap model still has to pass its check. Low cost only counts when the result is accepted.

100 agents is a number the task graph produces, not a target

Claude Code sets a default ceiling of 20 subagents running at once, and spawning the twenty first fails with a concurrent subagent limit reached error. An agent may spawn agents of its own up to 3 layers below the main conversation. Both are configurable, through CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS and CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH, and I have not needed to raise either. My run reached about 100 agents as a total across many waves, on one laptop, for one goal. What decides the count is the task graph. Two tasks that touch the same file stay in sequence, because parallel edits to one file produce repair work that costs more than the time saved. A task that needs an earlier decision waits for it. Parallel work is reserved for branches that can reach a finished result on their own, which is the same rule whether the wave holds 3 agents or 15. There is one more limit worth knowing before the roster grows: Claude Code warns at startup once the combined description fields pass 15,000 tokens, so keep each description to the one sentence that says when to delegate. The rule that made the difference is the last one. A report is not a completion. A task closes when the command named in the plan passes and its evidence is recorded, and until then it stays open however confident the agent sounded. That is the approval gate, and it is the whole answer to whether you can run a software team on a laptop. You can, as long as one lead reads every result, runs the checks itself, and keeps the right to say this is not done.

شغّلت ⁨100⁩ ⁨agent⁩ على لابتوب واحد، والبنية الهرمية هي ما جعل العمل قابلاً للاستخدام

شغّلت نحو ⁨100⁩ ⁨agent⁩ على لابتوب واحد من أجل هدف واحد، والعدد هو أقل ما يستحق الانتباه في هذه الجملة. ما أنهى العمل فعلاً هو البنية الهرمية: نموذج قائد يحتفظ بالقرارات والموافقة على التعديلات، ومجموعة ⁨agents⁩ أصغر ينفذ كل واحد منها مهمة محددة ثم يعيد تقريره.

الفشل الذي تحل هذه البنية مكانه معروف. نموذج واحد يكتب الميزة، ويشغّل الاختبارات، ويقرأ السجلات، ثم يحاول إصلاح ما بناه قبل قليل. يمتلئ ⁨context⁩ الخاص به بمخرجات لن يعود إليها، فتصبح إجاباته في آخر الجلسة أضعف من إجاباته في أولها. هذه ليست مشكلة قدرة، بل مشكلة مساحة.

يشرح توثيق ⁨subagents⁩ في ⁨Claude Code⁩ الحل بصيغة تقنية واضحة. يعمل كل ⁨subagent⁩ في ⁨context⁩ خاص به، مع تعليمات خاصة، وأدوات محددة، وصلاحيات مستقلة، ولا يرجع إلى المحادثة الرئيسية سوى ملخص عمله. تبقى القراءة الطويلة في مكانها، ويبقى المكان الذي تُتخذ فيه القرارات نظيفاً.

ال⁨agent⁩ هو ملف ⁨Markdown⁩. داخل ⁨.claude/agents/<name>.md⁩ تحمل مقدمة الملف ⁨name⁩، و⁨description⁩ يخبر القائد متى يفوّض المهمة، وقائمة ⁨tools⁩ المسموحة، و⁨model⁩. هنا يوجد التحكم الحقيقي. ⁨agent⁩ للمراجعة معرّف بـ ⁨tools: Read, Grep, Glob⁩ لا يستطيع الكتابة في أي ملف مهما كانت نتيجته، لأنه لم يحصل على أداة كتابة من الأساس.

سطر ⁨model⁩ كلمة واحدة، ويقبل ⁨fable⁩ أو ⁨opus⁩ أو ⁨sonnet⁩ أو ⁨haiku⁩، أو اسم النموذج كاملاً، أو ⁨inherit⁩. توصي صفحة النماذج لدى ⁨Anthropic⁩ بـ ⁨Claude Opus 5⁩ لمعظم الأعمال، وبـ ⁨Claude Fable 5.1⁩ للاستدلال الصعب والمهام الطويلة التي تحتاج استقلالية، وتعرض سعر ⁨Fable 5.1⁩ بعشرة دولارات لكل مليون ⁨token⁩ إدخال مقابل دولارين لـ ⁨Sonnet 5⁩ ودولار واحد لـ ⁨Haiku 4.5⁩. لذلك يأخذ القائد ⁨Fable 5.1⁩، ويأخذ التنفيذ ⁨Opus 5⁩، وتذهب القراءة والمهام المتكررة إلى ⁨Sonnet 5⁩ و⁨Haiku 4.5⁩.

الحدود هي سبب كون ⁨100⁩ مجموعاً لا دفعة واحدة. يشغّل ⁨Claude Code⁩ ⁨20⁩ ⁨subagent⁩ في الوقت نفسه افتراضياً، ويسمح لأي ⁨agent⁩ بإطلاق ⁨agents⁩ أخرى حتى ⁨3⁩ طبقات. يأتي العمل على دفعات، وتنتهي كل دفعة بعودة القائد إلى التقارير، وتشغيل الفحوص بنفسه، وإغلاق المهام التي وصل دليلها فقط. يحتوي مربع النسخ على هذا النظام كبنية ملفات، وأمر للقائد، وقاعدة للدفعات. ابدأ بمشروع واحد و⁨3⁩ ⁨agents⁩.

تابعني على ⁨Instagram⁩:

التسجيل في الدورة: https://halaqa.app/enrollment?course=start-with-ai

الخطوات

Prompt

# AGENT HIERARCHY FOR ONE LAPTOP
# Use this when one goal is too large for a single session to hold.
# Lead: Fable 5.1. Implementation: Opus 5. Reading and volume: Sonnet 5, Haiku 4.5.

# --- FILES ---
# CLAUDE.md
# The rules every session must see:
# - the goal and the architecture
# - the build, test and lint commands
# - what may never be touched
# - where the memory and the task file live

# .claude/agents/researcher.md
# ---
# name: researcher
# description: Reads the codebase and external sources, returns findings only
# tools: Read, Grep, Glob, WebFetch
# model: sonnet
# ---
# Report what you found with file paths and line numbers. Change nothing.

# .claude/agents/reviewer.md
# ---
# name: reviewer
# description: Checks a finished change against its acceptance command
# tools: Read, Grep, Glob, Bash
# model: opus
# ---
# Run the command named in the task. Report pass or fail with the output.

# An agent that must not write is given no tool that writes. The permission
# is the control. The instruction is not.

# --- THE LEAD PROMPT ---
# Read CLAUDE.md, then the task file. You are the lead. You keep the
# decisions, the integration and the final approval.
#
# Write the work as a checklist. Every task carries:
# 1. one bounded objective;
# 2. the files or system it owns;
# 3. the agent and the model that will run it;
# 4. the command that proves it worked;
# 5. the evidence it must return.
#
# Delegate only tasks that are independent. Two agents never edit the same
# file in the same wave. A task that needs an earlier decision waits.

# --- THE WAVE RULE ---
# Run 3 to 5 agents, then stop and reconcile: read the reports, run the
# checks yourself, resolve the conflicts, update the checklist.
#
# A report is not a completion. A task closes when its command passes and
# its evidence is recorded. When a check fails, open the smallest repair
# task that can fix it.
#
# Launch another wave only while independent work remains. Stop at the goal
# or at a stop condition you named in advance, then write the receipt: what
# shipped, what was verified, what failed, and the next exact action.