# Claude Code Isn’t Just a Terminal Anymore: Subagents, Agent Teams, Plugins, and MCP, Explained… > Source: > Published: 2026-08-10 04:54:52+00:00 *In **Part 1**, I went through the fundamentals: model vs. effort, why context rot is dilution and not forgetting, CLAUDE.md, skills, and hooks. All of that is about making one Claude session work well.* This part is about what happens once one session stops being enough. The honest reason I put off learning this half of Claude Code for so long: it sounded expensive and complicated, and I’m a solo developer, not a team of ten. Turns out some of it *is* expensive — but knowing when to reach for it (and when not to) is exactly what makes it worth learning instead of avoiding. A subagent is a specialized, isolated instance of Claude that your main session can delegate a task to. Each one runs in its **own context window**, with its own system prompt, its own tool permissions, and a narrow focus — think a “code-reviewer” agent or a “test-runner” agent. They’re defined as Markdown files with YAML frontmatter, stored in .claude/agents/ (project-level) or ~/.claude/agents/ (personal). **When to actually reach for one:** any task that needs deep, focused digging that would otherwise clutter your main conversation — reviewing a large diff, running and fixing a full test suite, a security audit, researching a library you’re about to depend on. They’re also great for standardizing a workflow across a team, since a “debugger” subagent that always investigates the same way can just be checked into git like any other file. **The cost trade-off, plainly:** subagents are *more* expensive than doing the same thing inline, not less. Every invocation spins up a fresh context — its own system prompt, its own exploration, its own reasoning — completely separate from your main session’s budget. What you get in exchange is that your main context stays lean, since the subagent only hands back a summary. Total token spend across the whole task usually goes *up*. You’re paying for isolation and reusability, not for saving tokens. A minimal one looks like this: ``` ---name: test-runnerdescription: Runs tests and fixes failurestools: Bash, Read, Edit---You are a test automation expert. Run the test suite,diagnose failures, and fix them without changing test intent. ``` Then you just invoke it conversationally: Use the test-runner subagent to fix failing tests That’s it. Your main session stays focused on the actual feature work while the subagent goes and wrestles with the test suite in its own sandbox. This is the one that sounds like science fiction until you read the fine print. “Teammates” are individual Claude Code instances spawned inside an **Agent Team** — an experimental multi-agent mode where one session becomes a Team Lead. The lead breaks work down, assigns pieces to teammates, and synthesizes what comes back. Each teammate works independently in its own context window, but — and this is the actual difference from a subagent — **teammates can message each other directly** through a mailbox system, rather than only reporting up to the lead. It’s off by default. You need to explicitly set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 to even try it. **When it earns its cost:** genuinely complex, multi-file work where parallel workers actually need to coordinate — a full-stack feature spanning frontend, backend, and tests at once; parallel code reviews comparing notes; debugging where multiple “investigators” are testing competing hypotheses at the same time. The lateral messaging matters here. A subagent that quietly changes an API signature can’t tell anyone. A teammate can message the others: “hey, I changed the signature, adjust accordingly.” That’s the entire value proposition — no stepping on each other’s work. **The cost, less plainly:** this is *significantly* more expensive than subagents or a single session — roughly **3–7x more tokens** than a single session, depending on configuration, because every teammate loads its own initialization context. Four teammates at 10K tokens of init each is 40K tokens spent before any actual work happens, versus 10K for one solo session. In practice: Set up an agent team: lead coordinates, spawn “frontend” and “backend” teammates to build the auth feature in parallel The lead manages a shared task list at ~/.claude/tasks/{team-name}/, and teammates message each other directly whenever their work overlaps. My honest take after learning this: it’s genuinely impressive, and genuinely not for simple, sequential tasks. If a feature doesn’t actually need parallel coordination, an agent team is just a more expensive way to do what one focused session would’ve done anyway. A plugin is an installable bundle that extends Claude Code — it can package slash commands, agents, skills, hooks, and MCP server configs together as a single unit. Plugins get distributed through **marketplaces**, which are just catalogs someone else has put together and shared. Adding a marketplace doesn’t install everything in it — it just gives you the ability to browse and pick, the same way adding a source to an app store doesn’t install every app in it. **When to use one:** whenever you want ready-made, reusable functionality instead of hand-rolling your own subagent or command from scratch — a security-audit command, a set of framework-specific skills (Next.js, Postgres, whatever your stack is), or a whole SDLC toolkit bundling code review and deployment automation together. Teams standardizing tooling benefit especially — add a marketplace once, install by name, done, instead of every developer hand-writing their own version of the same config. **Cost-wise**, plugins have no inherent overhead by themselves. You only pay tokens when a component inside the plugin actually runs — same as if you’d written it yourself. A plugin that’s just a slash command is basically free until you call it. A plugin bundling a bunch of auto-loaded skills, or an MCP server with a large tool schema, will add to your context and init cost, because that’s what those components would cost regardless of whether they arrived via plugin or by hand. bash ``` /plugin marketplace add anthropics/claude-plugins-official/plugin install security-audit@claude-plugins-official ``` Two lines, and a plugin’s commands and agents are live in your session. Model Context Protocol is an open, standardized way for Claude to talk to external systems — issue trackers, databases, APIs, file systems, browsers — through one uniform interface, instead of a custom integration per tool. Without it, giving Claude access to Jira, GitHub, *and* Slack means three separate bespoke integrations, each with their own quirks. With MCP, each of those systems just exposes an MCP server, and Claude speaks the exact same protocol to all three. One plug, many devices — the analogy really does hold. **When to reach for it:** anytime Claude needs to interact with something outside your local codebase — pulling tickets, querying a production database, posting to Slack, browsing the web. Instead of one-off scripts or handing Claude raw API credentials and hoping it reasons about them correctly, you connect an MCP server and it gets structured, *discoverable* tools it can call directly, like create_issue or search_tickets, instead of improvising against an API it's guessing at. **The cost isn’t in the protocol, it’s in what it exposes.** Every connected MCP server registers its tool definitions — names, descriptions, schemas — into the system prompt, and that consumes context on *every single turn*, whether you use it or not. A server with a lot of tools or verbose schemas can bloat your context window meaningfully. The practical rule: connect only what the current session actually needs, and disconnect what you’re not using. json ``` // .mcp.json{ "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] } }} ``` Find open issues labeled “bug” and summarize them That’s it — Claude now has real, structured access to GitHub issues, not a guess based on training data about how GitHub’s API probably works. Claude Code Desktop is the app’s Code tab — an integrated dev interface that goes past the CLI: visual diff review, live app previews, PR monitoring, and connectors like GitHub, all in one window. It can now start a dev server and preview your running app directly inside the desktop app, reading console logs as it goes, without you needing a browser tab open at all. You can even click on a visual element in the running preview and hand feedback straight to Claude. **Where it actually shines:** end-to-end feature work in a single window. Run the dev server, point at a UI element, say “make this red,” Claude edits the code live, hit “Review code” and it examines your local diff, leaving inline comments highlighting bugs and suggestions before you even open a PR. If your code lives on GitHub, you can watch PR status — including CI checks — directly in the desktop app, using the GitHub CLI under the hood. **Cost:** no separate pricing model — it draws from the same Claude Code usage as CLI sessions. Where it *can* creep up is automation depth: enabling auto-fix means Claude automatically attempts to resolve CI failures it detects, and enabling auto-merge means it’ll attempt to merge once checks pass. Every auto-fix cycle re-invokes Claude, so an unattended CI-fixing loop over a long session can add up. Rough flow: open Preview → npm run dev → click something in-app, say "make this red" → Claude edits live → "Review code" for inline diff comments → open PR → desktop tracks CI automatically from there. Cowork sits alongside Chat and Code as a third tab in Claude Desktop, built specifically for non-developer knowledge work. It connects to apps like Gmail, Google Calendar, Slack, and Drive through OAuth connectors and reasons *over* that data to produce a finished output — not just shuffle information between apps. Its **Scheduled Tasks** feature lets you write a prompt once, set a cadence, and it just runs on its own from there. **Where it fits:** recurring “office work” — summarizing yesterday’s Slack activity and emails into a morning briefing, or compiling data spread across Drive, spreadsheets, and other connected tools into a weekly summary. Scheduled tasks run remotely on their own cadence even if your laptop is asleep or the app is closed — the one exception being tasks that need local files or apps, which only run while your machine is actually awake. This one is explicitly *not* for developer tasks — that’s what Code/Claude Code is for. Trying to force Cowork into a coding workflow is the wrong tool for the job. **Cost:** available starting on Claude Pro ($20/mo), but each Cowork run is a full agentic session reasoning across multiple connectors and tools — meaningfully more quota-hungry than a normal chat reply. Example prompt: Every weekday at 8am, summarize my unread Slack, top 3 priority emails, and today’s calendar into a briefing. Skip newsletters. Set the cadence once, and a finished briefing shows up under “Scheduled” every morning without you asking again. *If I had to compress both parts of this into a decision tree I’d actually use:* None of this was obvious to me typing prompts into a terminal for months. Turns out the tool wasn’t the bottleneck — my mental model of it was. Cheaper lesson to learn from a course than from a token bill. If this was useful, a clap👏 goes a long way, and following means you’ll catch whatever I write up next as I keep pushing on this. Questions, disagreements, or “you missed X” — all fair game in the comments. [Claude Code Isn’t Just a Terminal Anymore: Subagents, Agent Teams, Plugins, and MCP, Explained…](https://pub.towardsai.net/claude-code-isnt-just-a-terminal-anymore-subagents-agent-teams-plugins-and-mcp-explained-ae767bdd0f91) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.