Claude Code gives you several ways to make an AI coding workflow feel bigger than one chat window.
Subagents can take side work into a separate context.
Hooks can run automatic checks at lifecycle moments.
MCP servers can connect the agent to external tools and data.
The main conversation can still be the best place for tightly coupled judgment.
The hard part is not knowing that these tools exist.
The hard part is deciding when each one should be used.
This is where many local AI coding setups get messy.
Everything looks like a candidate for delegation.
Everything looks like a candidate for automation.
Everything looks like a candidate for an MCP server.
Then the workflow becomes slower, noisier, and harder to audit.
That is the opposite of the point.
This field note gives you a practical decision table.
It is written for operators who already use Claude Code or a similar local coding agent.
The goal is not to admire the architecture.
The goal is to finish work without flooding the main thread, hiding critical decisions, or creating an automation trap.
Tiny villain arc avoided.
We love to see it.
The Core Rule
Use a subagent when the task benefits from a separate context.
Use a hook when the task should fire automatically at a predictable lifecycle moment.
Use MCP when the agent needs a durable connection to an external tool or data source.
Use the main thread when the next decision is tightly coupled to your current judgment.
That is the whole rule.
The rest is edge cases.
Unfortunately, software is mostly edge cases wearing a hoodie.
So let us make the rule operational.
Decision Table
| Need | Best fit | Why |
|---|---|---|
| Search many files and return a short summary | Subagent | It preserves main-thread context. |
| Review logs without adding all logs to the main thread | Subagent | The noisy evidence stays isolated. |
| Run a lint check after a file edit | Hook | The trigger is predictable. |
| Block a dangerous shell command before execution | Hook | The check belongs at tool-use time. |
| Query a database or issue tracker | MCP | The agent needs a connected tool. |
| Fetch monitoring context repeatedly | MCP | Reuse beats pasting dashboards into chat. |
| Decide between two architecture paths | Main thread | Judgment and coordination are central. |
| Fix a bug where every next step depends on the result | Main thread | Delegation would block the critical path. |
| Compare three libraries from docs | Subagent | Research can happen separately. |
| Enforce a project rule on every edit | Hook | Repetition is the point. |
| Call a tool with high privilege | Main thread plus approval | Keep the decision visible. |
| Keep an agent running in the background | Subagent | Only if the result is not immediately blocking. |
The table is simple.
The discipline is not.
Most mistakes come from using the most impressive tool instead of the most boring fit.
The boring fit wins more often than it gets invited to conferences.
What Subagents Are Good At
Anthropic’s Claude Code documentation describes subagents as specialized assistants that handle specific types of tasks in their own context.
The practical value is context isolation.
If a side task would flood the main conversation with search results, file contents, logs, or research notes, a subagent can do that work elsewhere.
Then it returns the useful summary.
That is the key phrase.
Useful summary.
A subagent should not return a second wall of unfiltered material.
That just relocates the mess.
Good subagent tasks are bounded.
They have a clear input.
They have a clear output.
They can be wrong without corrupting the main decision loop.
Examples:
- Find every place the auth token is parsed and summarize the variants.
- Compare the official docs for two SDK methods and report the migration risk.
- Inspect recent test failures and identify the top three likely causes.
- Review a local design pattern and list files that match it.
- Gather security implications of a proposed MCP server before installation.
Those tasks are useful because the main thread does not need to read every file or log line.
It needs the conclusion, the evidence path, and the risk.
What Subagents Are Bad At
Subagents are bad at urgent blocking work.
If your very next action depends on the answer, sending it away can slow you down.
Subagents are also bad at ambiguous ownership.
If two agents are likely to edit the same file or make conflicting design decisions, you need clearer boundaries.
Subagents are bad at hidden policy decisions.
If a choice affects security, data access, deployment, billing, or user-facing behavior, keep that decision visible.
Subagents are also bad at vague prompts.
“Look around and improve things” is not a task.
It is a fog machine.
A better prompt is:
“Search the authentication module for duplicated token parsing logic. Do not edit files. Return file paths, behavior differences, and one recommended consolidation plan.”
That is a task.
The agent can succeed or fail against it.
What Hooks Are Good At
Claude Code hooks are user-defined shell commands, HTTP endpoints, or LLM prompts that run automatically at specific lifecycle points.
The hooks reference describes events such as session start, prompt submission, pre-tool use, post-tool use, file change, and stop.
That makes hooks ideal for repeatable guardrails.
The hook should be predictable.
The trigger should be predictable.
The output should be predictable.
Examples:
- Block destructive shell commands.
- Run a formatter after file edits.
- Check generated files for secrets before completion.
- Add a warning when a tool call touches a protected path.
- Run a quick unit test after TypeScript files change.
- Deny an MCP write tool unless the project rule allows it.
Hooks are especially good when the question is not “should I think about this?”
The question is “should this check always happen here?”
If the answer is yes, hook it.
If the answer is “sometimes, depending on what I am trying to do,” do not rush.
Hooks that fire too often become background noise.
Background noise becomes ignored.
Ignored guardrails are decorative furniture.
Very expensive furniture, sometimes.
What Hooks Are Bad At
Hooks are bad at open-ended judgment.
They are also bad when the cost of running them is larger than the risk they reduce.
A hook that runs a full test suite after every tiny edit will teach you to hate your own automation.
That is not DevOps.
That is a small productivity tax with a nice hat.
Hooks are also risky when they hide side effects.
If a hook can write files, call APIs, change permissions, or send messages, it needs the same seriousness as any other automation.
The fact that it is automatic does not make it safer.
It just makes it faster.
Fast mistakes are still mistakes.
They just arrive with better latency.
Where MCP Fits
MCP is not a replacement for subagents or hooks.
It is a way to connect Claude Code to tools, databases, APIs, and external systems.
Anthropic’s MCP docs describe MCP servers as a way for Claude Code to read and act on connected systems instead of relying on copied-and-pasted context.
That is powerful.
It is also a permissions problem.
The same docs warn that third-party MCP servers should be trusted carefully, especially when they can fetch untrusted content or expose prompt-injection risk.
So the MCP question is:
Does the agent need this system as a tool?
If yes, MCP may be the right layer.
If no, do not add a server just because it is fashionable.
A tool surface is an attack surface.
The sentence is grim.
It is also useful.
Where Codex-style Sandbox Thinking Helps
OpenAI’s Codex documentation describes sandbox mode and approval policy as two security layers.
Sandbox mode controls what the agent can technically do.
Approval policy controls when the agent must ask before acting.
That framing is useful beyond Codex.
Claude Code workflows need the same mental model.
Tool access is one layer.
Human approval is another.
Hooks can enforce rules.
Subagents can isolate context.
MCP can extend capabilities.
But none of that removes the need to decide which actions should be automatic and which should be visible.
If the operation can move money, delete data, publish content, change production, or expose private information, do not bury it in a convenience layer.
Put a gate in front of it.
Good automation has brakes.
Bad automation has confidence.
The Main Thread Still Matters
The main thread is not the old way.
It is the coordination layer.
Keep work in the main thread when the task is tightly coupled to the current plan.
Keep it there when you need to balance tradeoffs.
Keep it there when the next step depends on the result.
Keep it there when the user or team needs to see the reasoning.
Keep it there when the work changes files that many other tasks depend on.
The main thread is also where you integrate subagent results.
A subagent can gather evidence.
A hook can enforce a check.
An MCP server can expose a system.
The main thread decides what to do with all of that.
That is not glamorous.
It is where the work becomes coherent.
A Practical Routing Pattern
Start every task with one question:
What is the critical path?
If the next action is blocked by a piece of information, get it locally.
Do not delegate the immediate blocker.
If a side question can run while you continue working, delegate it.
If a repeatable check should always run, hook it.
If the information lives in a durable external system, connect it through MCP.
If the action is sensitive, keep it visible and require approval.
This routing pattern prevents tool sprawl.
It also prevents the “AI team” from becoming six agents waiting on the same missing fact.
We have all seen meetings like that.
No need to automate one.
Example Workflow: Bug Fix
Imagine a failing payment test.
The main thread should read the failure and inspect the immediate code path.
That is the blocker.
A subagent can search for similar failures in old tests or release notes.
That is a side task.
A hook can run the narrow test after edits.
That is a repeatable check.
An MCP server might pull the issue tracker ticket.
That is connected context.
The main thread integrates the result and decides whether the patch is safe.
That is the judgment layer.
The workflow uses all four layers.
But each layer has one job.
That is why it stays legible.
Example Workflow: Documentation Update
Imagine updating an SDK migration guide.
A subagent can read official docs and compare API changes.
The main thread can write the guide.
A hook can check broken links or forbidden terms before completion.
MCP can fetch issue tracker examples if the project uses one.
The main thread should still own the final claims.
Documentation errors are sneaky.
They do not crash in CI.
They wait until a human trusts them.
That is worse.
Use tools, but keep responsibility visible.
Example Workflow: Security Review
Imagine adding a new MCP server.
Do not start with installation.
Start with threat modeling.
A subagent can inspect the server docs, permissions, transport, auth model, and package source.
A hook can later detect risky MCP write tools or protected paths.
The main thread should decide whether the server belongs in local, project, or user scope.
The main thread should also decide which environment variables are exposed.
This is exactly where convenience can get expensive.
Every integration that saves five minutes can create a new failure mode.
That does not mean avoid integration.
It means name the failure mode before celebrating the convenience.
Anti-patterns
- Spawning a subagent because the main thread is uncomfortable with deciding.
- Adding a hook because you forgot to run a command once.
- Installing MCP servers because a list said they were popular.
- Letting background agents edit the same files without ownership boundaries.
- Using hooks to perform actions the user expected to approve.
- Returning raw search dumps from subagents.
- Treating MCP tool access as harmless because the server is local.
- Keeping critical-path work out of sight.
- Calling everything an agent and then wondering why nobody knows who owns the result.
The fix is boring:
Bound the task.
Name the trigger.
Name the permission.
Name the owner.
Name the expected output.
When those five are clear, the tool choice usually becomes obvious.
My Default Heuristic
I use subagents for context isolation.
I use hooks for repeated lifecycle checks.
I use MCP for durable tool access.
I use the main thread for coordination and decisions.
I avoid background work when it touches the same files I am actively editing.
I avoid hooks that are expensive enough to make me resent them.
I avoid MCP servers that I cannot explain in one sentence.
I avoid any automation that makes sensitive actions less visible.
That heuristic is not fancy.
It is productive.
Productive beats fancy surprisingly often.
Fancy sends follow-up invoices.
FAQ
Are subagents the same as agent teams?
No.
Subagents work within a Claude Code session and isolate task-specific context.
Agent teams are for multiple agents working in parallel and coordinating more explicitly.
Use the lighter tool when the lighter tool fits.
Should every research task go to a subagent?
No.
If the research result is the immediate blocker, do it in the main thread.
If the research is a bounded side task that can return a summary later, a subagent is a good fit.
Should every safety check become a hook?
No.
A hook should be predictable, cheap enough, and valuable enough to run at its trigger point.
If it is expensive or judgment-heavy, keep it manual or run it at a narrower trigger.
Is MCP safer if it is local?
Not automatically.
Local tools can still expose files, secrets, commands, databases, and untrusted content.
Treat tool access as a permission surface.
When should I stay in the main thread?
Stay in the main thread when the next action is blocked on the answer, when the decision affects architecture or security, or when multiple edits must be coordinated carefully.
What is the easiest rule to remember?
Delegate noise.
Automate repetition.
Connect durable tools.
Keep judgment visible.
๊ด๋ จ ๊ธ
- Workspace Agents๋ GPTs์ ๋ญ๊ฐ ๋ค๋ฅผ๊น 2026 – ํ ๊ถํยท์น์ธยท๋ก๊ทธ ์ด์ํ
- Codex๋ฅผ ๋ต๋ณ๊ธฐ๊ฐ ์๋๋ผ ์์ด์ ํธ๋ก ์ฐ๋ ๋ฒ
- Claude Code 100๋ง ํ ํฐ ์๋ ์์ด์ ํธ ์ํฌํ๋ก