A Developer’s Last-Ditch Guide to Agentic Architecture, Claude, and Intent-Driven Engineering

Reverse Exam Cram: 19 Principles for Surviving the Agentic Engineering Deep End

A Developer’s Last-Ditch Guide to Agentic Architecture, Claude, and Intent-Driven Engineering

There is a point in certification prep where memorizing terminology stops helping.

You can know what a subagent is. You can know what MCP stands for. You can explain prompt caching, hooks, skills, tool calls, structured output, and orchestration.

And then the exam gives you a scenario.

A coordinator has three workers. One worker needs repository access but must not call deployment tools. Two investigations can happen concurrently. The coordinator must combine their findings into a machine-readable result. One worker fails. What should happen?

Now you’re not taking a vocabulary test.

You’re designing an agentic system.

That is the purpose of this Reverse Exam Cram.

Instead of starting with documentation and trying to memorize it, we start with the architectural problems developers actually face and work backward to the mechanism that solves them.

These 19 principles also form a practical architecture for Intent-Driven Engineering (IDE).

The mental model is:

INTENT

  ↓

CONTEXT

  ↓

PLAN

  ↓

ORCHESTRATION

  ↓

SPECIALIZED WORKERS

  ↓

TOOLS

  ↓

STRUCTURED RESULTS

  ↓

VALIDATION

  ↓

IMPLEMENTATION

  ↓

GOVERNANCE

The AI model is only one component of that system.

1. The Agentic Loop Is Universal

Every agentic system ultimately runs some variation of the same loop.

User / Application

       ↓

     Model

       ↓

   Tool Request

       ↓

Application executes tool

       ↓

   Tool Result

       ↓

     Model

       ↓

Continue / Finish

The important architectural distinction is:

The model requests actions. The host application executes them.

Conceptually:

response = model(messages, tools)

while response.requests_tools:

    results = []

    for request in response.tool_requests:

        result = execute_tool(request)

        results.append(result)

    messages.append(response)

    messages.append(results)

    response = model(messages, tools)

This distinction matters because permissions, retries, logging, validation, and security usually belong outside the model.

Exam signal

When you see:

Claude requests a tool…

Think:

Claude → tool request

Application → execute

Application → tool result

Claude → continue reasoning

2. Multiple Tool Calls Must Be Correlated Correctly

One response can request more than one tool.

For example:

Coordinator

   ├── Search repository

   ├── Read Jira requirement

   └── Query architecture registry

Those requests may execute concurrently.

The results therefore cannot simply be returned as anonymous text.

Each result must correspond to the request that produced it.

Conceptually:

{

  "tool_use_id": "tool_17",

  "result": {

    "status": "success",

    "data": "..."

  }

}

This is fundamental when tools execute asynchronously.

Developer rule

Never assume:

result[0] belongs to request[0]

Use explicit correlation identifiers.

Exam signal

Multiple tool calls → correlate results with their tool-use IDs.

3. Goal-Oriented Prompts Beat Overly Procedural Prompts

A common mistake is turning the model into an expensive shell script.

Procedural prompt:

Open directory A.

Read file B.

Search for function C.

Open file D.

Compare lines 30–80.

Then inspect test E.

Goal-oriented prompt:

Determine how outbound adapters perform source filtering.

Identify:

- the canonical implementation,

- deviations,

- shared utilities,

- evidence supporting the conclusion.

Do not modify files.

The second prompt gives the agent room to reason.

The first dictates implementation mechanics that may not even be correct.

Use procedural instructions when

The process itself is mandatory:

• compliance steps,

• migrations,

• security procedures,

• deterministic deployment processes.

Use goal-oriented instructions when

You care primarily about the result:

• investigation,

• architecture analysis,

• repository discovery,

• debugging,

• code generation.

4. Subagents Are Context Boundaries

A subagent isn’t valuable simply because it is another AI.

Its biggest advantage is context isolation.

Imagine analyzing an enterprise repository.

Without subagents:

Main Context

├── 12,000 lines of adapter analysis

├── security investigation

├── test investigation

├── deployment investigation

└── architecture investigation

The coordinator becomes polluted.

Instead:

Coordinator

   │

   ├── Architecture Agent

   ├── Security Agent

   ├── Testing Agent

   └── Deployment Agent

Each worker returns only what matters.

Example worker contract:

{

  "finding": "Adapters use shared source filtering",

  "confidence": 0.96,

  "evidence": [

    "shared/utils/sourceFilter.ts"

  ],

  "exceptions": [

    "legacy-servicenow-adapter"

  ]

}

The coordinator receives perhaps 500 tokens instead of 20,000.

Mental shortcut

Focused investigation + context isolation → subagent.

5. Restrict Subagent Tools

Not every worker needs every capability.

Consider:

Architecture Agent

Tools:

✓ repository search

✓ file read

✗ file write

✗ shell

✗ deployment

Meanwhile:

Implementation Agent

Tools:

✓ repository search

✓ file read

✓ file edit

✓ tests

✗ production deployment

This follows the principle of least privilege.

The architecture worker has no reason to deploy anything.

Why this matters

Tool restrictions improve:

• safety,

• predictability,

• auditability,

• prompt focus,

• blast-radius control.

Exam signal

If the question asks:

How should you prevent an investigative agent from modifying the repository?

The best answer is generally not:

Tell it not to.

The stronger answer is:

Don’t give it the modification tool.

6. Scope the Context Given to Workers

Tool restriction controls what an agent can do.

Context restriction controls what it can see.

Those are different controls.

Bad delegation:

Here is the entire repository.

Find the OAuth behavior.

Better:

Investigate OAuth behavior in outbound adapters.

Focus on:

- adapter configuration,

- authentication clients,

- token acquisition,

- fallback behavior.

Ignore UI and unrelated services.

Better still, provide known evidence or narrowed paths when appropriate.

{

  "task": "Determine OAuth grant ordering",

  "scope": [

    "shared/auth",

    "packages/*-adapter"

  ]

}

Less irrelevant context means better reasoning and lower token cost.

7. Coordinator-Worker Is the Core Multi-Agent Pattern

A coordinator owns the objective.

Workers own bounded investigations or tasks.

                  Coordinator

                       │

          ┌────────────┼────────────┐

          ↓            ↓            ↓

     Architecture   Security      Testing

        Worker       Worker        Worker

          │            │            │

          └────────────┼────────────┘

                       ↓

                  Coordinator

                       ↓

                  Final Decision

The coordinator should not duplicate worker work.

Its job is to:

1. decompose the objective,

2. delegate,

3. receive structured findings,

4. resolve conflicts,

5. synthesize,

6. decide what happens next.

This maps extremely well to IDE.

Intent

  ↓

Coordinator

  ↓

Discovery workers

  ↓

Scaffold plan

  ↓

Implementation

  ↓

Validation

8. Parallelize Independent Work

Suppose three investigations each take 30 seconds.

Sequential:

Architecture → Security → Testing

30 + 30 + 30 = 90 seconds

Parallel:

       ┌→ Architecture

Start ─┼→ Security

       └→ Testing

≈ 30 seconds

Parallelism makes sense when tasks do not depend on one another.

Use sequential execution when:

Task B requires Task A's result.

For example:

Discover canonical adapter

        ↓

Generate scaffold

        ↓

Run tests

        ↓

Analyze failures

But discovery itself may parallelize:

        ┌→ architecture discovery

Intent ─┼→ test discovery

        ├→ security discovery

        └→ deployment discovery

Exam shortcut

Independent → parallel.

Dependent → sequential.

9. Pass Findings, Not Entire Histories

Suppose an architecture worker searches 70 files.

The next worker usually does not need the entire conversation that produced the result.

Pass the conclusion plus evidence.

Bad:

Here are 18,000 tokens from the previous agent...

Better:

{

  "reference_adapter": "sf2-adapter",

  "architecture": "Kafka outbound worker",

  "source_filter": "shared utility",

  "auth": "OAuth client credentials",

  "evidence": [

    "packages/sf2-adapter/src/index.ts",

    "shared/auth/oauth.ts"

  ]

}

This is context engineering.

The objective is not to preserve every thought.

The objective is to preserve the information necessary for the next decision.

10. Structured Output Is an Architectural Contract

Human-readable prose is useful.

Agent-readable prose is dangerous.

Consider:

The adapter probably uses client credentials and there may

be a fallback depending on configuration.

Compare that with:

{

  "primary_grant": "client_credentials",

  "fallback_grant": "password",

  "fallback_enabled": true,

  "confidence": 0.94

}

The second can be validated and consumed by another system.

A useful schema might be:

{

  "status": "PASS | FAIL | UNKNOWN",

  "findings": [],

  "evidence": [],

  "warnings": [],

  "confidence": 0.0

}

Know these distinctions

missing

null

""

[]

{}

They are not interchangeable.

For example:

{

  "warnings": []

}

means:

The warnings field was evaluated and none were found.

Whereas:

{

  "warnings": null

}

may mean:

Warning analysis wasn’t performed or isn’t applicable.

That distinction matters in machine-to-machine workflows.

11. Validate Structured Output

Requesting JSON does not magically make it valid.

Treat model output like input from any external service.

result = call_worker()

try:

    validated = WorkerResult.parse(result)

except ValidationError:

    result = retry_with_validation_feedback()

Validation should check:

• required fields,

• allowed enums,

• data types,

• nested objects,

• missing fields,

• unexpected fields,

• malformed JSON.

Retry should be bounded.

attempt 1

   ↓ invalid

attempt 2

   ↓ invalid

attempt 3

   ↓

FAIL

Never create an infinite AI retry loop.

12. Use Headless Execution for Pipelines

Interactive coding sessions and automated pipelines solve different problems.

Interactive:

Developer

   ↓

Claude Code

   ↓

Explore / plan / modify

Headless:

CI

↓

claude -p "Analyze this change..."

↓

structured result

↓

next pipeline stage

A conceptual pipeline could look like:

claude -p "Analyze architecture" > architecture.json

claude -p "Using architecture.json, generate implementation plan"

claude -p "Validate implementation against intent"

The critical architecture isn’t the shell syntax.

It’s:

Stage A

   ↓

structured artifact

   ↓

Stage B

   ↓

structured artifact

   ↓

Stage C

This makes AI usable inside CI/CD and automated engineering workflows.

13. Skills Encode Reusable Expertise

A skill answers:

How does our organization perform this type of work?

Examples:

create-adapter

review-security

generate-api

scaffold-service

validate-intent

A skill can encode:

• conventions,

• workflow,

• architecture,

• questions,

• constraints,

• output expectations.

For example:

Adapter Scaffold Skill

1. Identify reference adapter.

2. Extract architectural constraints.

3. Determine requested delta.

4. Identify shared capabilities.

5. Generate scaffold plan.

6. Validate against reference implementation.

This is different from repository instructions.

A skill represents reusable expertise.

Mental shortcut

Reusable expertise/workflow → Skill.

14. Hooks Provide Deterministic Enforcement

AI instructions are probabilistic.

Some rules cannot be probabilistic.

Suppose every intent must contain:

Intent

Inputs

Outputs

Success Criteria

You can prompt:

Please remember to validate those fields.

Or you can enforce them.

required = [

    "Intent",

    "Inputs",

    "Outputs",

    "Success Criteria"

]

for section in required:

    if section not in intent:

        raise ValidationError(section)

That’s deterministic.

Hooks are useful for:

• validation,

• policy enforcement,

• formatting,

• security gates,

• blocking dangerous actions,

• mandatory checks.

Exam shortcut

Need deterministic enforcement → Hook.

15. MCP and Tools Connect the Agent to the Outside World

The model should not magically know your Jira tickets, database records, internal APIs, or deployment status.

Those are external systems.

Claude

  ↓

MCP / Tool

  ↓

Enterprise System

Examples:

Claude → Jira MCP → Jira

Claude → Database MCP → SQL

Claude → GitHub MCP → repositories

Claude → ServiceNow MCP → incidents

This creates a clean architectural boundary.

The model reasons.

The integration layer provides controlled access.

Mental shortcut

External system or live enterprise data → MCP/tool.

16. Durable State Belongs Outside the Model

Conversation context is not a transactional database.

If a workflow lasts hours, days, or weeks, its state should live somewhere durable.

Bad:

Claude remembers that step 7 completed.

Better:

{

  "workflow_id": "WF-782",

  "state": "VALIDATING",

  "completed_steps": [

    "DISCOVERY",

    "PLAN",

    "IMPLEMENTATION"

  ]

}

Store that in an appropriate durable system.

Then:

Agent

↓

read state

↓

perform operation

↓

write checkpoint

↓

continue

Mental shortcut

Durable workflow state → external store.

17. Side Effects Require Idempotency and Controlled Retry

AI systems eventually call systems that change things.

create account

deploy service

send message

update Jira

publish Kafka event

Retries become dangerous.

Suppose this fails after the external system creates the account but before your agent receives confirmation.

Retrying:

Create account

Create account

may produce duplicates.

Instead:

request

  +

idempotency key

Example:

{

  "operation": "create_customer",

  "idempotency_key": "customer-8372-create"

}

Retries should also be bounded and generally use backoff.

attempt

↓

failure

↓

wait

↓

retry

↓

eventual success or terminal failure

Mental shortcut

Side effects + retries → idempotency + bounded retry/backoff.

18. Long-Running Workflows Need Checkpoints and Compensation

Some operations cannot simply be rolled back with a database transaction.

Imagine:

Create Salesforce account

        ↓

Create billing account

        ↓

Create ServiceNow record

        ↓

Publish Kafka event

What if step three fails?

You may need a Saga-style workflow.

STEP A ── success

  ↓

STEP B ── success

  ↓

STEP C ── FAIL

  ↓

COMPENSATE B

  ↓

COMPENSATE A

Or perhaps business rules say to checkpoint and resume instead.

Either way, long-running distributed workflows require explicit state.

{

  "workflow": "customer-onboarding",

  "current_step": "SERVICENOW_CREATE",

  "status": "FAILED",

  "completed": [

    "SALESFORCE_CREATE",

    "BILLING_CREATE"

  ]

}

Mental shortcut

Long-running multi-system transaction → checkpoint + Saga/compensation.

19. Agentic Infrastructure Must Be Governed

This is the principle that turns everything above from clever developer experimentation into enterprise architecture.

Skills, agents, hooks, MCP servers, and reusable automations are not disposable feature artifacts.

They are infrastructure.

Without governance:

Developer A

└── security-agent

Developer B

└── security-agent-v2

Team C

└── super-security-agent

Team D

└── security-check-final-final

Soon the organization has dozens of competing implementations.

Instead:

               Shared Agentic Platform

                        │

        ┌───────────────┼────────────────┐

        ↓               ↓                ↓

      Skills          Agents           Hooks

        │               │                │

        └───────────────┼────────────────┘

                        ↓

                    MCP Servers

                        ↓

              Enterprise Systems

Developers should consume approved capabilities by default.

Feature

  ↓

Need reusable capability?

  ↓

Does approved capability exist?

  │

YES ─────────────→ USE IT

  │

NO

  ↓

Create candidate

  ↓

Review

  ↓

Validate

  ↓

Promote

  ↓

Shared capability

This prevents every repository from becoming its own miniature AI platform.

The developer’s responsibility is primarily:

Intent

+

business delta

+

feature implementation

The platform/shared-services responsibility is:

skills

agents

hooks

MCP

security controls

schemas

observability

governance

That separation is enormously important.

Putting the 19 Principles Together

Now we can assemble the complete architecture.

                         INTENT

                           │

                           ↓

                      COORDINATOR

                           │

             ┌─────────────┼─────────────┐

             ↓             ↓             ↓

        Architecture    Security       Testing

          Worker         Worker         Worker

             │             │             │

             └─────────────┼─────────────┘

                           ↓

                  STRUCTURED FINDINGS

                           │

                           ↓

                     SCAFFOLD PLAN

                           │

                           ↓

                    IMPLEMENTATION

                           │

                           ↓

                       VALIDATION

                           │

                           ↓

                         HOOKS

                           │

                           ↓

                         CI/CD

                           │

                           ↓

                       DEPLOYMENT

Surrounding the entire system:

Skills       → reusable expertise

MCP          → external systems

Schemas      → agent contracts

State Store  → durable workflow state

Hooks        → deterministic enforcement

Governance   → approved reusable infrastructure

This is much closer to a software architecture than a chatbot.

The Developer Scenario

Suppose Jira says:

Add an organization-account adapter using the existing Salesforce adapter architecture.

Don’t immediately generate code.

The IDE workflow becomes:

JIRA REQUIREMENT

       ↓

     INTENT

       ↓

   COORDINATOR

       ↓

┌─────┼─────────────┐

↓     ↓             ↓

Repo  Architecture  Tests

Scan  Analysis      Analysis

└─────┼─────────────┘

       ↓

STRUCTURED FINDINGS

       ↓

REFERENCE IMPLEMENTATION

       ↓

DELTA ANALYSIS

       ↓

SCAFFOLD PLAN

       ↓

IMPLEMENT

       ↓

TEST

       ↓

VALIDATE INTENT

       ↓

PR

And notice what we didn’t do.

We didn’t tell the model:

Create these 17 files.

Create this class.

Create this interface.

Create this abstraction.

We said:

Here is the desired outcome. Discover how this repository already solves the problem. Determine the smallest safe delta.

That’s intent-driven engineering.

A Practical Coordinator Contract

A production-oriented coordinator could accept something like:

{

  "intent": "Implement organization account adapter",

  "constraints": {

    "preserve_architecture": true,

    "reuse_shared_components": true,

    "new_shared_abstractions": false

  },

  "workers": [

    "architecture",

    "security",

    "testing"

  ]

}

Each worker returns:

{

  "status": "PASS",

  "findings": [],

  "evidence": [],

  "risks": [],

  "recommendations": [],

  "confidence": 0.95

}

The coordinator produces:

{

  "implementation_required": true,

  "reference_pattern": "existing-adapter",

  "files_to_modify": [],

  "files_to_create": [],

  "shared_components_reused": [],

  "tests_required": [],

  "risks": [],

  "unresolved_questions": []

}

Now the system has contracts.

That’s the difference between:

AI helped me write some code.

and:

AI participates in our engineering architecture.

The Exam-Day Decision Matrix

When a scenario appears, translate it into architecture.

Scenario

Think

Need deterministic enforcement

Hook

Reusable expertise/workflow

Skill

External system/data

MCP / Tool

Focused investigation

Subagent

Prevent worker side effects

Tool restriction

Reduce worker distraction

Context scoping

Several specialized investigations

Coordinator-worker

Independent investigations

Parallel execution

Dependent operations

Sequential execution

Pass worker result onward

Structured findings

Machine consumes response

Schema + validation

Automated CI operation

Headless / -p

Multiple tool requests

Correlate tool-use IDs

Huge mostly-static context

Prompt caching

Huge knowledge source

Retrieval instead of stuffing

Persistent workflow

External state

Retried side effect

Idempotency

Distributed long transaction

Saga/checkpoint/compensation

Reusable agent infrastructure

Govern it centrally

That table is worth knowing cold.

The Three Layers to Remember

If everything else disappears from memory, reduce the architecture to three layers.

Layer 1 — Intent

What do we want?

What constraints exist?

What constitutes success?

Layer 2 — Intelligence

Coordinator

Workers

Skills

Reasoning

Planning

Retrieval

Layer 3 — Control

Tools

MCP

Hooks

Schemas

State

Idempotency

Permissions

Governance

The model primarily lives in the intelligence layer.

Enterprise reliability comes from the control layer.

And the entire system exists to satisfy the intent layer.

The Final Mental Model

When confronted with an ugly certification scenario, don’t try to remember which page of documentation mentioned the feature.

Ask five questions:

1. What is the intent?

What outcome is actually required?

2. Who should reason about it?

Coordinator? Specialized worker? Skill?

3. What should that worker be allowed to see and do?

Context scope and tool restrictions.

4. What contract connects this stage to the next?

Structured input/output, evidence, IDs, validation.

5. What must be deterministic?

Hooks, permissions, state, retries, idempotency, and governance.

That turns a complicated question into an architecture problem.

The Bigger Lesson

The frustrating part of this material is also what makes it valuable.

This isn’t really about learning how to talk to Claude.

It’s about learning how to engineer systems in which probabilistic intelligence operates inside deterministic boundaries.

That requires understanding:

reasoning

delegation

context

contracts

tools

state

failure

security

orchestration

governance

Those are architecture concerns.

And they survive whichever AI coding tool happens to be popular next year.

Claude Code may change.

Models will certainly change.

Agent frameworks will change.

MCP implementations will evolve.

But this architecture:

Intent

   ↓

Reasoning

   ↓

Delegation

   ↓

Tools

   ↓

Structured Results

   ↓

Validation

   ↓

Controlled Action

   ↓

Governance

is much more durable.

That’s why the Reverse Exam Cram isn’t really about memorizing 19 Claude concepts.

It’s about recognizing the 19 architectural forces underneath modern agentic engineering.

Once those become familiar, the exam question stops looking like a trick question.

It starts looking like a system design problem.

And system design problems can be reasoned through.