Claude Architect Certification Prep: Articles 37–40 Combined

Claude Architect Certification Prep: Articles 37–40 Combined

The Exam Decision Matrix: Knowing When to Use Claude Chat, Claude Code, MCP, Agents, Hooks, Skills, and Human Approval

At this stage in the certification series, we are past the vocabulary.

We already know the major building blocks:

Claude.

Claude Code.

MCP.

Agents.

Subagents.

Hooks.

Skills.

Memory.

Structured output.

Context.

Evidence.

Human approval.

But the real certification question is not:

Do you know what these things are?

The real certification question is:

Do you know when to use each one?

That is the difference between somebody who knows the toolset and somebody who can architect a solution.

The architect’s job is not to use the most powerful option every time.

The architect’s job is to use the right level of capability, governance, and reliability for the problem in front of them.

That is what this article is about.

The Core Exam Mindset

For the Claude Architect certification, think like this:

Start simple. Add capability only when the task requires it. Add governance wherever risk appears. Add evidence before you trust the result.

That is the exam mindset.

A simple explanation does not need an agent.

A codebase change probably needs Claude Code.

A system lookup may need MCP.

A repeatable workflow may need a skill.

A quality gate may need a hook.

A multi-role workflow may need agents or subagents.

A risky business decision may need human approval.

The architect does not ask, “What is the coolest way to solve this?”

The architect asks:

What is the minimum reliable architecture that solves the problem safely?

That sentence is worth remembering.

1. When to Use Prompt-Only Claude

Prompt-only Claude is the right answer when the task is mostly reasoning, explanation, drafting, summarization, or planning.

Use prompt-only Claude when:

• the task is self-contained

• no files need to be changed

• no tools are required

• no external system needs to be queried

• the output is informational

• the user can review the answer directly

Examples:

“Explain MCP in simple terms.”

“Compare REST and GraphQL.”

“Draft a training article.”

“Summarize this architecture decision.”

“Help me reason through this design.”

Prompt-only Claude is powerful because it is fast and low-friction.

But it has limits.

It should not be trusted for current system state unless it has access to the right source. It should not pretend to know what is inside a repo unless the repo context has been provided. It should not act like it validated something if it did not actually run a tool, inspect a file, or check evidence.

The exam principle is simple:

Use prompt-only Claude for thinking, writing, and explanation — not for unverified system action.

2. When to Use Claude Code

Claude Code is the right answer when the work involves a codebase.

Anthropic describes Claude Code as an agentic coding tool that works in the terminal, understands a codebase, edits files, runs commands, and integrates with development workflows. That means Claude Code is not just a chat window. It is a code execution and repository collaboration environment.

Use Claude Code when:

• the task requires repository context

• files need to be inspected

• code needs to be changed

• tests may need to be run

• build commands matter

• project conventions matter

• the answer depends on actual repo structure

Examples:

“Add a new API endpoint.”

“Refactor this service.”

“Find where this error is coming from.”

“Update tests for this feature.”

“Explain how this repo is structured.”

“Prepare a pull request summary.”

Claude Code is where intent becomes implementation.

But even here, the architect needs boundaries.

Claude Code should know:

• what files are in scope

• what change is requested

• what tests must pass

• what style conventions apply

• what not to touch

• when to stop

• what evidence to produce

This is why CLAUDE.md, repo instructions, project memory, and intent files matter. Anthropic’s Claude Code memory documentation describes CLAUDE.md as a way to guide Claude’s behavior with project-level context and instructions.

The exam principle:

Use Claude Code when the work depends on the actual codebase, not just general reasoning.

3. When to Use MCP

MCP is the right answer when Claude needs to reach outside itself and outside the local repo.

MCP is not just a connector idea. Architecturally, MCP is the controlled bridge between Claude and external tools, systems, and data.

Use MCP when Claude needs:

• Jira tickets

• Confluence pages

• GitHub data

• database queries

• internal APIs

• enterprise search

• cloud resources

• observability systems

• document repositories

• current system state

Examples:

“Look up the Jira story and implement it.”

“Pull the latest Confluence architecture standard.”

“Check the production error logs.”

“Query the customer table for this status.”

“Create a release note from merged PRs.”

The key point is that MCP extends Claude’s reach.

But that also increases risk.

Once Claude can touch real systems, the architect has to care about:

• permissions

• authentication

• least privilege

• auditability

• data boundaries

• tool reliability

• failure handling

• human approval for risky actions

The exam principle:

Use MCP when Claude needs external system capability, but design the permissions and guardrails deliberately.

4. When to Use Agents and Subagents

Agents and subagents are the right answer when the work becomes complex enough to benefit from separation of responsibility.

Anthropic’s Claude Code subagent documentation describes subagents as specialized AI assistants for task-specific workflows and improved context management.

That phrase is important: task-specific workflows.

Do not create agents just because the word sounds impressive.

Create agents when the workflow has different jobs that should be handled separately.

Examples:

A planning agent breaks down the work.

A coding agent implements the change.

A test agent runs and interprets tests.

A security agent checks policy and secrets.

A documentation agent updates docs.

An evidence auditor verifies the work.

This is exactly the pattern we just packaged with the Intent-Driven Engineering repo coach and the evidence auditor.

The main agent looks at the full repo health picture.

The subagent focuses only on evidence.

That is a good architectural separation.

The main agent asks:

“What is the condition of this repo as an Intent-Driven Engineering workspace?”

The evidence subagent asks:

“What proof exists that this repo can be trusted?”

That is a clean agent/subagent design.

The exam principle:

Use agents when specialization improves focus, reliability, context management, or workflow control.

5. When to Use Hooks

Hooks are the right answer when something should happen automatically around an event.

Claude Code hooks can automate actions such as checks, formatting, notifications, or policy enforcement around Claude Code events. Anthropic’s hooks documentation covers hook events, configuration schemas, JSON input and output formats, exit codes, async hooks, HTTP hooks, prompt hooks, and MCP tool hooks.

That tells us hooks are not just “nice automation.”

Hooks are governance points.

Use hooks when you want automatic enforcement.

Examples:

• run formatting after edits

• block unsafe commands

• check for secrets

• require tests before completion

• log tool usage

• notify a team channel

• enforce architecture standards

• validate generated files

• stop risky actions before they happen

Hooks are different from agents.

An agent thinks and works through a task.

A hook responds to an event.

That distinction matters.

Use an agent when you need reasoning.

Use a hook when you need automatic enforcement.

The exam principle:

Use hooks for event-driven automation, quality gates, and policy enforcement.

6. When to Use Skills

Skills are the right answer when you want reusable capability packaged for repeated use.

Anthropic’s Claude Code skills documentation describes skills as a way to create, manage, and share capabilities that extend Claude Code, including custom commands and bundled skills.

That maps perfectly to Intent-Driven Engineering.

A skill is useful when you have a repeatable pattern:

• generate an intent file

• review an architecture

• create a test plan

• produce a PR checklist

• create a deployment readiness report

• run a repo health check

• generate an evidence package

• produce a Wix article draft

• create a Claude certification study artifact

The skill makes the method portable.

That matters for teams.

Without skills, every engineer prompts differently.

With skills, the team gets shared execution patterns.

The exam principle:

Use skills when you want repeatable, shareable, team-level capability.

7. When to Use Human Approval

Human approval is the right answer when risk, judgment, cost, compliance, or business impact is high.

This is one of the easiest exam concepts to understand and one of the easiest to ignore in real life.

Human approval belongs at decision points such as:

• production deployment

• security-sensitive changes

• data deletion

• customer-impacting actions

• financial decisions

• legal or compliance decisions

• architecture standard exceptions

• irreversible changes

• unclear requirements

• low-confidence recommendations

Human approval should not be used everywhere.

If every step needs approval, the workflow becomes too slow.

But if no step needs approval, the workflow becomes unsafe.

The architect has to place approval gates where they matter.

The exam principle:

Use human approval at high-impact decision points, not as a substitute for good automation.

The Practical Decision Framework

Here is the decision flow I would remember for the exam:

What is the intent?

        ↓

Does the task require repo context or file changes?

        ↓

Use Claude Code.

        ↓

Does Claude need external systems or current enterprise data?

        ↓

Use MCP.

        ↓

Is the workflow complex enough to split into responsibilities?

        ↓

Use agents or subagents.

        ↓

Does something need to happen automatically at an event boundary?

        ↓

Use hooks.

        ↓

Is this a repeatable team capability?

        ↓

Package it as a skill or command.

        ↓

Is there risk, compliance, production impact, or ambiguity?

        ↓

Require human approval.

        ↓

What evidence proves the work is done?

That is architecture.

Not because it is complicated.

Because it is controlled.

What This Means for Intent-Driven Engineering

This is why our approach keeps coming back to the same pattern:

Intent

  ↓

Context

  ↓

Capability

  ↓

Execution

  ↓

Evidence

  ↓

Decision

Intent defines what should happen.

Context defines what Claude needs to know.

Capability defines whether we need Claude Chat, Claude Code, MCP, agents, hooks, or skills.

Execution is where the work happens.

Evidence proves whether the work is trustworthy.

Decision determines whether to continue, stop, approve, revise, or escalate.

That is the Intent-Driven Engineering operating model.

And it lines up directly with the architect mindset behind Claude Code and agentic systems.

Exam Scenarios to Practice

Here are the types of scenarios I expect to show up on the exam.

Scenario 1: Simple Explanation

A product manager asks Claude to explain the difference between an API and an event stream.

Best choice: prompt-only Claude.

Why?

Because the task is informational, low-risk, and does not require files or tools.

Scenario 2: Codebase Refactor

A developer wants to refactor a service and update tests.

Best choice: Claude Code.

Why?

Because the task requires repo context, file edits, project conventions, and test execution.

Scenario 3: Jira-to-Code Workflow

A team wants Claude to read a Jira ticket, inspect the repo, implement the feature, run tests, and summarize the change.

Best choice: Claude Code plus MCP.

Why?

Claude Code handles repo implementation. MCP connects Claude to Jira and possibly Confluence or GitHub.

Scenario 4: Enterprise Delivery Assistant

An organization wants a workflow that plans work, implements code, validates tests, checks security, and writes documentation.

Best choice: agents or subagents.

Why?

The workflow has multiple responsibilities that benefit from separation.

Scenario 5: Security Gate

A company wants every Claude-generated code change checked for secrets and unsafe commands before completion.

Best choice: hooks.

Why?

This is event-driven enforcement, not a one-time reasoning task.

Scenario 6: Repeatable Repo Health Review

A company wants every repo to run the same architecture, context, test, and evidence review.

Best choice: skill or custom command, possibly backed by agents.

Why?

The pattern is repeatable and should be standardized across teams.

Scenario 7: Production Deployment

Claude prepares a production deployment recommendation.

Best choice: human approval before deployment.

Why?

Production deployment carries business and operational risk.

The Certification Takeaway

The exam is not looking for blind enthusiasm.

It is looking for architectural judgment.

You should be able to say:

Use prompt-only Claude when the task is simple and informational.

Use Claude Code when the work depends on the repository.

Use MCP when Claude needs external tools, systems, or data.

Use agents and subagents when specialized roles improve the workflow.

Use hooks when event-driven automation or enforcement is needed.

Use skills when a repeatable capability should be packaged and reused.

Use human approval when the decision is risky, ambiguous, regulated, expensive, or irreversible.

Use evidence before trusting the result.

That is the whole game.

Final Thought

A great Claude Architect does not throw every feature at every problem.

A great Claude Architect designs the smallest reliable system that can safely produce the desired outcome.

That means knowing when to stay simple.

It also means knowing when to add power.

Claude Chat gives reasoning.

Claude Code gives repo execution.

MCP gives external reach.

Agents give specialization.

Hooks give automation and enforcement.

Skills give repeatability.

Human approval gives accountability.

Evidence gives trust.

Put those together correctly, and you are not just using AI.

You are architecting with it.

:::