Agentic Coding Weekly Quiz #4: Claude Code Subagents

I publish Agentic Coding Weekly every Monday. If you want new quizzes like these in your inbox, subscribe below.

Q1: What is the primary benefit of delegating a test suite run to a subagent instead of running it in your main Claude Code conversation?

A) The subagent can run tests in a sandboxed environment that prevents side effects
B) The subagent retries flaky tests automatically before reporting results
C) The subagent runs tests in parallel across multiple threads for faster execution
D) The verbose test output stays in the subagent's context, keeping your main conversation clean

Q2: In a subagent Markdown file, which YAML frontmatter fields are required?

A) name and description
B) name, description, and tools
C) name, description, and model
D) name, description, tools, and permissionMode

Q3: If you omit the tools field in a custom subagent's configuration. What happens?

A) The subagent gets no tools
B) The subagent gets only read-only tools as a safety default
C) The subagent inherits all tools available to the main conversation
D) The subagent must request tool access interactively each time it tries to use one

Q4: A subagent needs to validate that all Bash commands are read-only SQL queries. What's the recommended approach?

A) Remove Bash from the tools field and use a custom MCP server for database access instead
B) Set permissionMode: plan so the subagent operates in read-only mode
C) Write a PreToolUse hook that inspects the command and exits with code 2 to block disallowed operations
D) Put a strict "only SELECT queries" rule in the system prompt and rely on the model to comply

Q5: When should you prefer using the main conversation over delegating to a subagent?

A) When the task produces a large volume of output that needs to be referenced later
B) When you need frequent back-and-forth and iterative refinement with Claude
C) When the task is self-contained and can be summarized in a few sentences
D) When the task should run in the background while other work continues

Q1: Correct Answer is D.
Explanation: Context management is the core reason subagents exist. Every tool call and its output uses tokens in the context window, and running a full test suite can easily produce thousands of lines of output. When that work gets delegated to a subagent, all the verbose output lives in the subagent's own context window, and only a concise summary makes it back to the main conversation. This keeps the main context focused on planning, implementation, and decision-making instead of being flooded with raw test logs. Any operation that's going to produce a wall of text that nobody needs to scroll through afterward is a solid candidate for delegation. Test runs, log analysis, documentation fetching, large codebase searches, etc. are all great fits.

Q2: Correct Answer is A.
Explanation: A subagent file is just a Markdown file with YAML frontmatter at the top and a system prompt in the body. The only two required fields are name (a lowercase, hyphenated identifier like code-reviewer) and description. Everything else, tools, model, permissionMode, hooks, maxTurns, skills, memory, all optional with sensible defaults. The description field is quite important. Claude uses it to decide when to automatically delegate tasks to a given subagent. A vague description means Claude won't know when to invoke it.

Q3: Correct Answer is C.
Explanation: When the tools field is left out of a subagent's frontmatter, it inherits everything the main conversation has access to, including MCP tools. Giving a subagent access to all the tools might not be optimal. A code reviewer probably only needs Read, Grep, Glob, and maybe Bash. There's no good reason for it to write files. A debugger that needs to apply fixes would also need Edit. There are two ways to control this: use tools as an allowlist (only these specific tools), or use disallowedTools as a denylist (everything except these). Principle of least privilege should help with deciding what tools to give to a subagent. A subagent with fewer tools stays focused on its intended job and is less likely to go off on tangents or do something unexpected.

Q4: Correct Answer is C.
Explanation: In this situation the tools field alone isn't granular enough. The goal is to allow Bash but only for certain kinds of commands. PreToolUse hooks helps with that. A hook gets defined in the subagent's frontmatter matching on Bash, pointing at a validation script. Claude Code passes the tool input as JSON via stdin, the script extracts the command, checks for things like INSERT, UPDATE, DELETE, or DROP, and exits with code 2 to block it or code 0 to let it through. The error message goes back to the subagent via stderr so it understands why the command was rejected. This pattern also generalizes beyond SQL. The same approach works for ensuring file writes only target certain directories, API calls only hit staging endpoints, or shell commands stay away from production configs.

Q5: Correct Answer is D.
Explanation: Subagents are great for well-defined, self-contained tasks: "run the tests and tell me what failed," "review the auth module for security issues," "find all usages of this deprecated API." They work independently and return a summary. But for iterative work, like exploring a design tradeoff, refining an implementation step by step, or going back and forth on an approach, subagent delegation adds overhead that gets in the way. Subagents start with fresh context (they don't see the main conversation history), and there's no easy way to interject mid-task to redirect them. That interactive, exploratory loop is where you should use main conversation. One more thing worth noting: subagents can't spawn other subagents. So if a workflow requires nested delegation, the way to handle it is chaining subagents from the main conversation, or using skills instead.