Big Picture 10: Claude Code, Multi-Agent, Skills and Computer Use
This document zooms into the agent loop of Big Picture 6. It covers what happens inside a Claude Code session, how multi-agent and Managed Agents are built, how Skills and Plugins load, and how computer use drives a screen. All of them are the same loop with different tools.
Inside a Claude Code session
You run claude in the terminal and type: "Fix the bug in the login API".
- 1.1 Startup
- 2.2 Your prompt (UserPromptSubmit hook)
- 3.3 Model call (Stages 2-5)
- 4.4 tool_use arrives
- 5.5 Permission engine
- 6.6 PreToolUse hook
- 7.7 Execute (checkpoint before Edit)
- 8.8 PostToolUse hook
- 9.9 tool_result goes back to step 3, until the work is done
- 10.Finish: end_turn, Stop hook, summary, auto memory
- 1 Startup: settings load in order (managed, CLI, local, project, user), plus CLAUDE.md files, the auto-memory index, skill descriptions and plugins. MCP servers connect and the SessionStart hook runs.
- 2 Your prompt: @file mentions are expanded, the UserPromptSubmit hook runs (it can add context or block the prompt), and the message goes into the history.
- 3 Model call: system prompt, tools (Read, Edit, Bash, Grep, Glob, WebFetch, MCP, Skill, Agent...) and history go to the API. It is the same journey through Stages 2 to 5.
- 4 tool_use arrives: for example Grep "login", Read auth.cs, Edit, Bash dotnet test. Several can come in parallel in one turn.
- 5 Permission engine: deny rules first, then allow rules, then the mode (default, acceptEdits, plan, auto, bypass). If needed, it asks you.
- 6 PreToolUse hook: your script can allow or deny the tool, or change its input, for example blocking an edit to the .env file.
- 7 Execute: the tool runs on your machine (optionally in a sandbox). A checkpoint is made before Edit, so you can /rewind.
- 8 PostToolUse hook: for example running a formatter or linter after every edit.
- 9 tool_result back to step 3: the output goes into the history, the model thinks again, and the loop continues until the work is done.
- Skill branch: if the prompt matches a skill description, the Skill tool loads the SKILL.md body, and scripts and instructions can follow.
- Subagent branch: the Agent tool creates a new worker (Explore, Plan, custom) with its own context. Only a summary comes back, so the main context stays clean.
- Context filling up: auto-compaction kicks in near the limit and old history becomes a summary (PreCompact hook runs). Use /compact manually, and /clear for a new task.
- Finish: the model returns end_turn, the Stop hook runs (for example "did the tests pass?"), you get a summary, and key points can go to auto memory.
Multi-agent and Managed Agents
When one agent's context is not enough, or the work can run in parallel, a multi-agent setup helps. Managed Agents is the version hosted by Anthropic.
- 1.Lead agent (Opus): understand, plan, split
- 2.Workers 1, 2, 3: separate contexts, only summaries come back
- 3.Lead: combine, verify, final answer
- Lead agent (Opus): understands the task, makes a plan and splits the work.
- Worker 1, 2, 3: each has its own context. For example module A, module B, and running tests with a cheaper model. Only summaries go back.
- Lead: combine + verify, then the final answer. The lead's context stays clean because the workers did the heavy reading.
- Trade-off: more agents means more tokens. Use this only when the work is truly parallel or reading-heavy.
- 1.Agent: versioned config (model, system, tools, skills, MCP), created once
- 2.Environment: container config (networking, packages)
- 3.Vault: secrets the sandbox never sees
- 4.Session: each run, Anthropic runs the loop
- 5.Your app: sends user.message, reads SSE events
- Agent: a versioned config with the model, system, tools, skills and MCP. Create it once.
- Environment: container config such as networking and packages.
- Vault: secrets, which the sandbox never sees.
- Session (each run): its own container workspace. Anthropic runs the agent loop. Status is running, idle or terminated, and runtime is billed only while running.
- Your app: sends user.message, reads SSE events (agent.message, tool use), and sends back custom tool results and approvals.
- Extras: Outcomes (run until a rubric passes), cron deployments, webhooks, multi-agent workflows and memory stores.
How Skills and Plugins load
Skills use progressive disclosure: a little at a time, only as needed. Plugins have a journey from catalog to loaded.
- 1.L1 Always: name + description in context (max 1,536 chars)
- 2.L2 On a match: SKILL.md body loads
- 3.L3 When needed: reference files read, scripts run (only output enters context)
- 4.Plugin: Marketplace, Declared, Fetched, Loaded
- L1 Always: only name and description sit in context, at most 1,536 chars. That is why context stays light even with many skills.
- L2 On a match: the prompt matched the description, or the user invoked the skill with a slash command. The full SKILL.md body loads.
- L3 When needed: reference files are read and scripts run. Only the script's output enters the context.
- Who can invoke it: by default the user and Claude. disable-model-invocation means only the user. user-invocable: false means only Claude.
- Priority: Enterprise, then Personal (~/.claude/skills), then Project (.claude/skills). Plugin skills run separately as /plugin:skill.
- Marketplace: a marketplace.json catalog kept in a git repo.
- Declared: the plugin is listed under enabledPlugins in settings.
- Fetched: it is downloaded into the disk cache at ~/.claude/plugins.
- Loaded: at session start, or with /reload-plugins.
- Inside a plugin: skills/ (/plugin:skill), agents/ (subagents), hooks.json (runs on events) and .mcp.json (starts MCP servers).
- Warning: an enabled plugin adds its descriptions to the context on every turn and runs with your user privileges. Disable it if you do not need it.
Computer use
Computer use is the same tool loop from Big Picture 6, except the tool is a screen, mouse and keyboard.
- 1.1 Task + toolset (computer_toolset_20260801)
- 2.2 Screenshot of the VM screen
- 3.3 Model looks and decides the next action
- 4.4 Harness executes in the VM, returns OK
- 5.5 New screenshot, back to step 3 until the task is done
- 1 Task + toolset: for example "Compare flight prices", given along with the computer_toolset_20260801 toolset.
- 2 Screenshot: Claude asks for a screenshot and your harness captures the VM screen and sends the image.
- 3 Model looks + decides: the image goes in as visual tokens and Claude picks the next action: left_click (x, y), type, key, scroll, zoom...
- 4 Harness executes: it really clicks or types in the VM and the result is "OK".
- 5 New screenshot: the changed screen goes back to step 3, until the task is done.
- Messages: Claude sends {type: "tool_use", name: "left_click", toolset_name: "computer", input: {x, y}}. You send back {type: "tool_result", content: "OK"}, or an image for a screenshot or zoom.
- Coordinates: in the pixels of the screenshot you sent. Keep the image within the limit and resize first, because a tool_result image is not auto-resized, it is rejected.
- Cost: the toolset definition is about 4,500 input tokens, plus the visual tokens of every screenshot. Several actions can come in one turn.
- Safety: always an isolated VM or container, never real passwords or bank accounts. Human confirmation for purchase, delete and send. Instructions on web pages are data, otherwise it is prompt injection.
- Where you see it: Claude in Chrome, desktop agents, testing / QA automation, and old apps that have no API.
- In one line (whole diagram): build the context, call the API, the model thinks and writes, loop if it needs a tool, output on end_turn.