Article 3: The Claude Architect Thinks in Orchestration, Not Prompts

Article 3: The Claude Architect Thinks in Orchestration, Not Prompts

From “Ask Claude” to “Design the Work”

Most people begin with Claude by asking better prompts.

That is useful.

But a Claude Architect has to go further.

A Claude Architect does not simply ask Claude to do work. A Claude Architect designs the way Claude receives context, selects tools, delegates to subagents, uses skills, calls MCP servers, follows guardrails, and produces evidence.

That is the shift.

Prompting is the surface.

Orchestration is the architecture.

And for the Claude Architect certification, this is one of the most important mental models to master.

You are not being tested only on whether you know what Claude Code is. You are being tested on whether you understand how Claude Code becomes part of a reliable enterprise delivery system.

Claude Code is not just a coding assistant. Anthropic describes Claude Code as an agentic coding tool that lives in the terminal, understands the codebase, and helps execute routine development tasks. It can also be extended with hooks, subagents, MCP, permissions, sessions, and other orchestration capabilities through the Claude Code SDK and related configuration model.

That means the architect’s job is not merely to write clever prompts.

The architect’s job is to design the operating system around the work.

The Certification Mindset: One Claude Is Not the Architecture

A common beginner mistake is thinking:

“Claude will read the repo, understand everything, and do the right thing.”

Sometimes it will.

Sometimes it will not.

In an enterprise environment, “sometimes” is not an architecture.

A real architecture asks:

• What does Claude need to know?

• Where does that context come from?

• Which tool should be allowed?

• Which task should be delegated?

• Which action requires approval?

• Which result needs evidence?

• Which output becomes a reusable asset?

• Which mistake must be blocked before it happens?

That is orchestration.

The Claude Architect has to understand how multiple pieces work together:

• Claude Code for repo-aware development

• CLAUDE.md or project memory for persistent guidance

• Skills for reusable capability

• Subagents for specialized delegation

• Hooks for automation and enforcement

• MCP servers for enterprise context and external systems

• Permissions for control

• Structured output for reliability

• Evidence loops for validation

The certification is not really asking, “Can you use Claude?”

It is asking, “Can you design a system where Claude can succeed repeatedly?”

That is a different level.

The Big Architecture Picture

Here is the simple model:

User Intent

   ↓

Architectural Context

   ↓

Claude Code Session

   ↓

Skills / Commands / Subagents

   ↓

Tools / MCP Servers / Repo Access

   ↓

Implementation

   ↓

Validation / Tests / Evidence

   ↓

Delivery Decision

This is the difference between a prompt and a delivery system.

A prompt says:

“Build this feature.”

An orchestration architecture says:

“Understand the intent, load the repo standards, inspect the current implementation, call the right tools, delegate specialized work, enforce rules through hooks, produce test evidence, and return a decision-ready result.”

That is what the certification wants you to see.

Skills: Reusable Capability

A skill is a packaged capability.

In Claude Code, skills extend what Claude can do by giving it structured instructions, workflows, or domain-specific procedures that can be reused across tasks. Anthropic’s Claude Code documentation describes skills as a way to create, manage, and share reusable extensions to Claude’s capabilities.

Architecturally, skills matter because they prevent every team from inventing its own delivery process.

Without skills, every developer prompts differently.

With skills, the organization can say:

• Here is how we create a feature plan.

• Here is how we generate tests.

• Here is how we review security.

• Here is how we produce release evidence.

• Here is how we summarize delivery risk.

• Here is how we create an implementation scorecard.

This is where Claude Code becomes more than a personal coding tool.

It becomes a shared delivery system.

For certification, the key is to understand that a skill is not just “extra instructions.” A skill is reusable operational knowledge.

That is the architectural value.

Subagents: Specialized Delegation

A subagent is a focused worker.

Claude Code supports custom subagents with their own descriptions, prompts, tool access, and specialized behavior. Anthropic’s documentation explains that Claude uses each subagent’s description to decide when to delegate work, which means the subagent description is part of the routing architecture.

This matters.

A weak subagent description creates weak delegation.

A strong subagent description makes routing clear.

For example:

Security Review Agent:

Use this agent when code changes affect authentication, authorization,

secrets, dependency risk, data exposure, or external API access.

That is much better than:

Security Agent:

Helps with security.

The architect has to design subagents by responsibility.

Common enterprise subagents might include:

• API design agent

• Test generation agent

• Security review agent

• Database migration agent

• UI accessibility agent

• DevOps deployment agent

• Documentation agent

• Evidence review agent

The point is not to create agents for fun.

The point is to reduce cognitive overload and increase quality by routing specialized work to specialized instructions.

For certification, remember this:

Subagents are not just helpers. They are architectural boundaries.

Hooks: Automation and Guardrails

Hooks are one of the most important pieces of the Claude Code architecture.

Hooks allow actions to run at specific points in the Claude Code workflow. Anthropic’s Claude Code hook documentation covers hook events, configuration, JSON input and output formats, exit codes, async hooks, HTTP hooks, prompt hooks, and MCP tool hooks.

That sounds technical, but the architectural idea is simple:

Hooks let the system react.

They can help enforce rules, run checks, log activity, trigger validation, or block unsafe behavior.

A hook can say:

• Before tool use, check permission.

• After file edit, run formatting.

• After code change, run tests.

• Before commit, scan for secrets.

• Before deployment, validate evidence.

• When a risky command appears, require approval.

• When a task completes, write a delivery summary.

This is huge.

Because in enterprise architecture, you do not rely only on humans remembering the process.

You build the process into the workflow.

That is what hooks enable.

A developer may forget to run tests.

A hook does not forget.

A developer may skip documentation.

A hook can require it.

A developer may accidentally expose a secret.

A hook can stop it.

For certification, hooks should be understood as the automation and control layer of Claude Code.

Skills teach Claude what to do.

Subagents divide the work.

Hooks enforce the operating model.

MCP: Enterprise Context and External Systems

MCP stands for Model Context Protocol.

Architecturally, MCP matters because Claude needs access to real enterprise context: Jira, Confluence, GitHub, databases, design tools, cloud systems, internal documentation, monitoring platforms, and other systems of record.

Anthropic’s Claude Code documentation explains that Claude Code can connect to external tools and data sources through MCP, an open standard for AI-tool integration.

This is one of the biggest differences between toy AI and enterprise AI.

A toy AI answers from whatever the user pasted into the chat.

An enterprise AI system connects to the actual work environment.

That means Claude can reason from:

• Current Jira stories

• Confluence requirements

• GitHub branches and pull requests

• Figma designs

• API documentation

• Test results

• Deployment logs

• Security policies

• Production incidents

• Architecture standards

But MCP also introduces risk.

The architect has to ask:

• Which systems should Claude access?

• Which tools are read-only?

• Which tools can write?

• Which actions require approval?

• Which data is sensitive?

• Which context is authoritative?

• Which source wins when two sources conflict?

That is the certification-level thinking.

MCP is not just “connect Claude to tools.”

MCP is enterprise context architecture.

The Architect’s Pattern: Intent → Context → Action → Evidence

For certification prep, use this pattern repeatedly:

Intent

  → Context

  → Action

  → Evidence

This is the cleanest way to think about Claude Code architecture.

1. Intent

What outcome are we trying to achieve?

Not just “write code.”

The intent should describe the business goal, feature goal, constraints, acceptance criteria, and boundaries.

2. Context

What does Claude need to know?

This may come from the repo, CLAUDE.md, Jira, Confluence, MCP servers, design files, API docs, coding standards, test history, or architecture decisions.

3. Action

What should Claude do?

This is where skills, subagents, tools, hooks, and permissions come into play.

4. Evidence

How do we know it worked?

This includes tests, logs, diffs, screenshots, build output, validation notes, review summaries, and risk assessments.

This pattern is simple enough to remember and strong enough to design with.

If you can explain Claude Code using this model, you are thinking like an architect.

Example: Bad Workflow vs Architected Workflow

Weak Workflow

Prompt:

“Add the customer notification feature.”

Claude starts coding.

Maybe it finds the right files.

Maybe it misses the notification standards.

Maybe it forgets tests.

Maybe it changes the wrong service.

Maybe it produces code that works locally but breaks the pipeline.

This is not architecture.

This is hope.

Architected Workflow

1. Load feature intent.

2. Read repo guidance from CLAUDE.md.

3. Pull Jira story and acceptance criteria through MCP.

4. Review existing notification patterns.

5. Use API design skill.

6. Delegate test strategy to test subagent.

7. Use security subagent for data exposure review.

8. Apply hooks after file edits to run formatting and tests.

9. Generate implementation evidence.

10. Return delivery summary with risks and next steps.

This is architecture.

The difference is not that Claude is smarter in the second version.

The difference is that the system around Claude is smarter.

That is the heart of Claude Architect thinking.

What You Need to Master for the Exam

For Article #3, master these ideas:

Skills

Skills are reusable capability packages.

They help standardize workflows across users, teams, and repositories.

Subagents

Subagents are specialized workers.

They should have clear descriptions, focused responsibilities, and appropriate tool access.

Hooks

Hooks are automation points.

They help enforce rules, trigger validation, log activity, and prevent unsafe or incomplete work.

MCP

MCP connects Claude to external tools and enterprise context.

It creates power, but it also creates responsibility around permissions, data access, and source authority.

Orchestration

Orchestration is the architecture that connects all of these pieces.

The Claude Architect designs the flow of work, not just the prompt.

Study It

To study this, do not start by memorizing definitions.

Start by drawing the system.

Draw a feature request moving through Claude Code.

Ask:

Where does the intent come from?

Where does context come from?

Which skills are used?

Which subagents are needed?

Which hooks enforce quality?

Which MCP servers provide data?

Which permissions protect the system?

What evidence proves completion?

If you can draw it, you can explain it.

If you can explain it, you can teach it.

If you can teach it, you are getting close to mastery.

Learn It

To learn it, take one real feature and map the orchestration.

For example:

Feature: Add payment failure notification email.

Now map it:

Intent:

Notify customers when payment fails.

Context:

Billing service code, email templates, notification policy, retry rules,

customer communication standards, Jira acceptance criteria.

Skills:

Feature planning skill, API review skill, test generation skill.

Subagents:

Payment domain agent, email template agent, security review agent,

test validation agent.

Hooks:

Run lint after edits.

Run unit tests after implementation.

Scan for secrets before commit.

Require evidence before completion.

MCP:

Jira for story details.

Confluence for billing rules.

GitHub for repo context.

Monitoring system for existing failure patterns.

Evidence:

Passing tests, changed files, sample email output, risk summary,

acceptance criteria checklist.

That is how you learn architecture.

You turn abstract tools into a real delivery flow.

Master It

Mastery comes when you can choose the right level of control.

Not every task needs ten subagents.

Not every repo needs heavy hooks.

Not every workflow needs five MCP servers.

The architect must balance power and simplicity.

Too little orchestration creates chaos.

Too much orchestration creates friction.

The best Claude Architect knows when to use:

• A simple prompt

• A reusable skill

• A specialized subagent

• A hook-based guardrail

• An MCP-connected enterprise workflow

• A full delivery orchestration pipeline

That judgment is what separates an operator from an architect.

The exam may test terminology.

The real world tests judgment.

Teach It

Here is the way I would teach this to an engineering team:

“Claude Code is not magic. It is a worker inside an operating model. If you give it vague intent, weak context, no standards, no tools, no validation, and no evidence requirements, you will get inconsistent results. But if you design the workflow around intent, context, action, and evidence, Claude becomes part of a repeatable engineering system.”

That is the lesson.

Do not teach developers to prompt harder.

Teach them to architect the work.

The One Sentence to Remember

A Claude Architect does not just use Claude Code to generate code.

A Claude Architect designs the system that allows Claude Code to deliver reliable, governed, evidence-backed engineering outcomes.

That is Article #3.

That is the shift from user to architect.

And that is one of the core ideas to master for certification.

:::

This one fits naturally after the first two articles: #1 vocabulary/mechanics, #2 architecture mindset, and now #3 orchestration architecture. Next article should probably go deeper into Tool Design & MCP Integration, because that is where certification starts separating casual Claude Code users from true enterprise architects.