Claude Code Has a Context Architecture. Intent-Driven Engineering Adds the Layer Above It.
- Mark Kendall
- 2 hours ago
- 12 min read
Claude Code Has a Context Architecture. Intent-Driven Engineering Adds the Layer Above It.
Anthropic is teaching us how to engineer context. Intent-Driven Engineering asks a different question: what governs what all that context is trying to accomplish? Put the two together, and the architecture gets very interesting.
For a while, I thought I understood context windows.
I understood the basic definition: an LLM has a finite amount of information it can actively work with. Give it too much irrelevant information and reasoning becomes harder. Keep the important information close and performance improves.
Technically correct.
Architecturally incomplete.
What finally made the concept click for me was looking at a complex Claude Code workflow and asking:
When Claude delegates work to a subagent, whose context is it?
The answer changes how you think about agentic development.
The main Claude session has a context. A subagent operates with its own context. The information crossing that boundary has to be deliberately selected.
Once you see that, Skills, subagents, CLAUDE.md, prompts, tools, MCP, Hooks, structured outputs, and the context window itself start fitting into one architecture.
And then another layer appears above them:
Intent.
That’s where Anthropic’s Context Engineering and what I call Intent-Driven Engineering begin to converge.
Start With a Real Enterprise Problem
Let’s remove any company-specific application and use something we’ll call SEGA.
What Is SEGA?
For purposes of this discussion, SEGA is a fictional enterprise services and process platform.
Think of it as the kind of platform many large organizations have: dozens of services, APIs, adapters, event processors, workflows, shared libraries, databases, and external system integrations.
A SEGA repository might contain:
SEGA
│
├── APIs
├── Services
├── Adapters
├── Event Processors
├── Workflows
├── Shared Libraries
├── External Integrations
├── Tests
└── Deployment
SEGA isn’t important because of the name.
It’s useful because it represents the kind of enterprise system where AI-assisted engineering becomes difficult.
Now give Claude Code a serious assignment:
Add a new customer-account integration to the existing SEGA platform.
Reuse the closest existing service or adapter.
Do not redesign the platform.
Determine the smallest safe delta.
Preserve existing event-processing, filtering, authentication, error-handling, response, testing, observability, and deployment conventions.
Research the repository first.
Investigate architecture, implementation, testing, and security independently where useful.
Avoid filling the primary context with unnecessary repository exploration.
Return evidence supporting architectural decisions.
Implement only after the proposed delta has been validated.
That’s real enterprise engineering.
It requires repository exploration, architecture reasoning, comparison, planning, implementation, testing, and validation.
Now the context problem becomes obvious.
We could dump enormous amounts of repository content into one conversation.
Or we could engineer the context.
Anthropic increasingly gives us mechanisms for doing the latter.
Layer 1: The Main Claude Context
Start Claude Code in the SEGA repository and there is a primary Claude session.
Think of this as the main working context.
Claude receives the conversation, instructions, repository information it discovers, tool results, and other relevant information supplied during the session.
The important principle is that Claude doesn’t need the entire SEGA repository loaded into its context.
It can discover information as needed.
That’s already context engineering.
The question isn’t:
How much information can I give Claude?
The better question is:
What information does Claude need right now?
Those are radically different engineering philosophies.
Layer 2:
Defines the Environment
Anthropic provides CLAUDE.md for persistent project-level guidance.
For SEGA, it might say:
SEGA is an enterprise services and process platform.
Prefer existing service and adapter patterns.
Do not introduce new infrastructure without justification.
Use shared platform libraries before implementing local equivalents.
Preserve existing API and event contracts.
Run appropriate tests before changing shared components.
Follow existing security, observability, deployment,
and error-handling conventions.
That’s valuable information.
But notice what it isn’t.
It isn’t today’s feature.
Those instructions could apply to hundreds of different changes.
CLAUDE.md tells Claude:
This is how this environment works.
It doesn’t necessarily tell Claude:
This is what we’re trying to accomplish today.
That’s an important distinction.
Layer 3: The Prompt Supplies the Immediate Goal
Now the developer gives Claude a prompt:
Add customer-account integration support.
First inspect existing SEGA services and adapters.
Determine the closest reference implementation.
Do not modify code yet.
Return:
- reference implementation
- required delta
- reusable capabilities
- affected components
- tests
- risks
Claude now has the immediate assignment.
The working specification already exists across several locations:
Repository
+
+
Prompt
As the work progresses, additional information accumulates:
Conversation
Tool results
Files
Search results
Plans
Decisions
Test output
This is where context management starts becoming architecture rather than simply prompting.
Layer 4: Subagents Change the Context Model
Suppose Claude needs to investigate four areas:
Reference implementation
Architecture
Testing
Security
One approach is for the main agent to investigate everything.
It searches hundreds of files.
Reads tests.
Examines deployment configuration.
Studies authentication.
Compares services.
Inspects shared libraries.
Eventually the primary context contains enormous amounts of information that were useful during investigation but aren’t necessarily useful for making the final decision.
Subagents give us another option.
Conceptually:
MAIN CLAUDE
|
+-----------------+-----------------+
| | |
Repository Testing Security
Research Research Research
| | |
own context own context own context
| | |
FINDINGS FINDINGS FINDINGS
+-----------------+-----------------+
|
MAIN CONTEXT
Each worker investigates its problem independently.
The crucial idea is:
A subagent boundary is a context boundary.
That’s one of the most important concepts in multi-agent engineering.
The Subagent Does Not Need Everything
Suppose our repository-analysis subagent needs to determine which SEGA service should become the reference implementation.
It doesn’t need every conversation we’ve ever had.
It needs a contract.
GOAL
Identify the closest existing service or adapter
for the new customer-account integration.
CONSTRAINTS
Do not redesign the platform.
Prefer established production patterns.
Prefer shared capabilities over local implementations.
Determine the smallest safe change.
INVESTIGATE
Event consumption
Validation and filtering
Transformation
External integration
Authentication
Error handling
Response processing
Testing
Observability
Deployment
RETURN
{
reference_component,
reasons,
relevant_files,
reusable_components,
required_differences,
risks,
evidence
}
Now the subagent can explore deeply.
It may read dozens or hundreds of files.
It may perform searches.
It may consume a substantial amount of context.
It may follow several possible architectural paths.
But the main Claude session doesn’t need all of that.
It needs the result:
{
"reference_component": "customer-service-adapter",
"reasons": [
"same event-processing model",
"same authentication mechanism",
"same response pattern"
],
"reusable_components": [
"validation",
"authentication client",
"response publisher"
],
"required_differences": [
"customer-account mapping",
"new external endpoint"
],
"risks": [
"duplicate validation implementation"
]
}
A large amount of investigation has been compressed into a small amount of useful information.
That’s more than delegation.
That’s context compression through delegation.
Context Passing Is an Information Contract
This is where context windows stop being an LLM trivia question and become an architecture concern.
Whenever information crosses an agent boundary, treat that boundary like an API.
Don’t ask:
What can I send this agent?
Ask:
What is the minimum sufficient information this agent requires to accomplish its goal?
A good context contract might contain:
Intent
Constraints
Relevant state
Required evidence
Expected output
Not:
Entire conversation
Entire repository
Every previous agent transcript
Every tool result
Everything everybody knows
More context isn’t automatically better context.
The goal is minimum sufficient context.
The return path should follow the same principle.
Bring back:
Findings
Decision
Evidence
Risks
State
References
when those are what the next stage requires.
Now we’re building an information pipeline.
Four Workers, Four Context Windows
The SEGA assignment could therefore become:
MAIN
|
+-----------------+-----------------+
| | |
REFERENCE ARCHITECTURE TESTING
WORKER WORKER WORKER
| | |
own context own context own context
| | |
findings delta test plan
| | |
+-----------------+-----------------+
|
SYNTHESIS
Security might be another independent worker:
SECURITY WORKER
|
authentication
secrets
permissions
external calls
|
security findings
The architecture isn’t valuable because four AIs sound cooler than one AI.
That’s agent theater.
Multiple agents are justified when there is a concrete reason:
specialization
isolation
parallel independent reasoning
different tool permissions
context containment
If the main agent can do the job cleanly, let it.
The goal isn’t more agents.
The goal is better reasoning with better context.
Layer 5: Skills Provide the Reusable “How”
Suppose SEGA contains dozens of services and integrations.
We shouldn’t explain this every time:
Here’s how our organization creates a new SEGA service.
That’s reusable organizational knowledge.
That’s where Skills fit.
A SEGA Skill might know:
How to identify the reference service
How to scaffold a new component
Required folder structure
Standard logging
Testing conventions
Security conventions
Deployment conventions
Observability requirements
Validation requirements
Now we get a clean separation:
Intent
WHAT must happen
Skill
HOW we do this here
For example:
Intent:
Add customer-account integration.
Skill:
How SEGA services and integrations are created.
Those aren’t the same thing.
And they shouldn’t be.
Layer 6: Tools Perform Actions
Claude may need to:
search files
read source
run tests
inspect Git history
query APIs
retrieve tickets
read documentation
query an external system
Those are tools.
Tools provide capabilities.
The model reasons about what needs to happen.
The tool performs the action.
So now:
Intent = what must happen
Skill = how we do it here
Subagent = specialized or isolated reasoning
Tool = external action
Once those responsibilities are separated, agent architecture becomes much easier to understand.
Layer 7: MCP Connects External Context and Capabilities
SEGA’s repository isn’t necessarily the entire enterprise.
Claude may need information from:
Work management systems
Documentation
Design repositories
Databases
Architecture registries
Enterprise APIs
Operational systems
MCP provides standardized connectivity between the AI environment and those external systems.
Conceptually:
Claude
|
MCP
|
Enterprise Systems
MCP isn’t the reasoning.
It’s access to external context and capability.
And that access can be governed.
Layer 8: Hooks Enforce What Cannot Be Optional
Suppose SEGA has non-negotiable rules:
Tests must pass.
Secrets cannot be committed.
Architecture validation must run.
Certain files cannot be modified.
Security scanning is mandatory.
Those shouldn’t depend entirely on:
Claude, please remember.
If something truly cannot be optional, deterministic enforcement is stronger.
That’s where Hooks fit.
Now:
Intent
What must happen
Skill
How we do it here
Hook
What cannot be optional
That is a powerful separation of concerns.
So Where Is the Orchestrator?
Now we reach the part I find most interesting.
Anthropic has given us much of the machinery:
Prompts
Skills
Subagents
Tools
MCP
Hooks
Context windows
Structured outputs
Claude can reason across those mechanisms.
But where does the durable definition of this particular job live?
Often it’s the prompt.
Maybe the conversation.
Maybe a work item.
Maybe pieces distributed across several systems.
That’s where Intent-Driven Engineering adds another layer.
Put the Intent Above the Context Architecture
Instead of allowing the goal to exist primarily inside the conversation, make it a durable engineering artifact:
For our SEGA example:
INTENT
Add customer-account integration to SEGA.
INPUTS
Existing SEGA services
Reference integrations
Business requirements
Shared platform capabilities
OUTPUTS
Working integration
Tests
Deployment configuration
Implementation evidence
SUCCESS CRITERIA
Correct customer-account processing
Existing architecture preserved
Tests passing
No unnecessary infrastructure
CONSTRAINTS
Smallest safe change
Reuse existing patterns
Prefer shared capabilities
Do not redesign the platform
VALIDATION
Automated tests
Architecture checks
Integration validation
STOP CONDITIONS
Stop if a safe reference architecture cannot be determined.
Stop if implementation requires an unapproved
platform-level change.
Something important has happened.
The mission is no longer trapped inside a conversation.
It exists independently.
The Intent Becomes the Orchestration Anchor
This is where I put Intent-Driven Engineering one layer above Claude Code’s context architecture.
Not because Anthropic calls it that.
They don’t.
This is the Intent-Driven Engineering interpretation.
INTENT
|
What must be accomplished?
|
+-----------------+-----------------+
| | |
Inputs Constraints Success
| | |
+-----------------+-----------------+
|
MAIN CLAUDE
|
+-----------------+-----------------+
| | |
SKILLS SUBAGENTS TOOLS
| | |
reusable "how" isolated reasoning actions
| | |
+-----------------+-----------------+
|
MCP
|
External Systems
HOOKS
|
deterministic enforcement
The Intent becomes the orchestration anchor.
It says:
This is what we’re trying to accomplish.
Claude determines how to reason toward it.
Skills supply organizational knowledge.
Subagents investigate isolated problems.
Tools perform actions.
MCP supplies governed access to external systems.
Hooks enforce mandatory boundaries.
Context engineering determines what information each component receives.
Intent Engineering and Context Engineering Solve Different Problems
This is where the two ideas finally come together.
Context Engineering asks:
What information should this reasoning component have right now?
Intent-Driven Engineering asks:
What outcome is the entire system trying to achieve, under what constraints, and how will we know it succeeded?
They’re not competing philosophies.
They’re complementary architectures.
Context without durable intent can produce sophisticated execution without a sufficiently persistent definition of the destination.
Intent without good context engineering can produce a beautiful specification feeding a poorly managed reasoning system.
Put them together:
INTENT ENGINEERING
↓
defines the destination
CONTEXT ENGINEERING
↓
delivers the right information
AGENTIC EXECUTION
↓
performs the work
DETERMINISTIC GOVERNANCE
↓
enforces the boundaries
VALIDATION
↓
proves the outcome
Now we have a system.
Anthropic Is Filling In the Execution Layers
This distinction is important if we’re going to talk about this publicly.
I’m not saying:
Anthropic recommends Intent-Driven Engineering.
They don’t.
I’m not saying:
Anthropic recommends intent.md.
They don’t.
Anthropic is documenting the mechanisms needed to build increasingly sophisticated context-aware and agentic workflows:
persistent project guidance
context management
Skills
subagents
tools
MCP
Hooks
structured outputs
automated/headless execution
Those mechanisms form an increasingly sophisticated context and execution architecture.
Intent-Driven Engineering proposes a durable task contract sitting above them.
That’s the distinction.
Claude Code has a context architecture. Intent-Driven Engineering adds an intent architecture.
And This Changes How We Think About the Intent File
The Intent file should not contain everything.
That’s critical.
If Context Engineering teaches us to provide the minimum sufficient context, Intent-Driven Engineering should follow the same principle.
A massive Intent file describing every implementation detail simply creates another context problem.
The Intent should establish the contract:
Goal
Inputs
Outputs
Constraints
Success Criteria
Acceptance Criteria
Validation
Evidence
Stop Conditions
Then allow information to be progressively discovered.
INTENT
|
| "Here is the mission."
↓
CLAUDE
|
| "What do I need to know?"
↓
RETRIEVAL / SKILLS / SUBAGENTS / MCP
|
| "Here is the relevant context."
↓
REASONING
That’s much more scalable.
The Intent File Isn’t a Giant Procedural Script
The Intent also shouldn’t become:
Step 1 read file A
Step 2 read file B
Step 3 call agent C
Step 4 execute command D
Step 5 modify file E
unless those steps genuinely have to occur in that order.
Instead:
Goal:
Add the required customer-account capability.
Constraints:
Reuse existing architecture.
Smallest safe change.
No unnecessary infrastructure.
Success:
Required behavior works.
Tests pass.
Architecture remains compliant.
Then let Claude reason.
That’s goal-oriented execution.
Use procedural orchestration when ordering, gates, side effects, retries, recovery, or failure consequences actually require it.
The Intent governs the destination. It doesn’t micromanage every turn of the steering wheel.
Now Context Passing Makes Sense
Before looking at the architecture this way, “context passing” sounds like another LLM optimization technique.
It isn’t.
It’s architecture.
Every boundary asks:
What does this component need to know?
And:
What does the next component need back?
For example:
MAIN → SUBAGENT
Intent
Relevant constraints
Relevant state
Expected output
Evidence requirement
Then:
SUBAGENT → MAIN
Finding
Recommendation
Evidence
Risk
Relevant references
That’s a contract.
It’s very similar to designing contracts between software services.
And the same principle applies:
Don’t couple systems by sharing their entire internal state.
That’s as true for agents as it is for microservices.
Context Windows Become Architecture Boundaries
That leads to an even larger realization.
A context window isn’t merely a model limitation.
Used deliberately, it becomes an isolation boundary.
One worker can deeply investigate security without filling the main context with every security file.
Another can investigate tests.
Another can investigate architecture.
Each performs specialized reasoning.
Each returns only what the orchestrating context needs.
Which gives us:
Deep local reasoning
+
Small structured handoff
=
Scalable agentic reasoning
That’s a much more useful way to think about multi-agent architecture than:
Let’s create five agents.
The Complete Architecture
Put everything together:
INTENT-DRIVEN ENGINEERING
|
DURABLE INTENT
|
+--------+--------+
| |
GOAL CONSTRAINTS
| |
+--------+--------+
|
MAIN CONTEXT
|
CONTEXT ENGINEERING
|
+------------------+------------------+
| | |
SKILLS SUBAGENTS MCP
| | |
reusable "how" isolated work external context
| | |
+------------------+------------------+
|
STRUCTURED HANDOFFS
|
TOOLS
|
ACTIONS
|
HOOKS
|
ENFORCEMENT
|
VALIDATION
|
DONE
That’s not simply prompt engineering.
It’s architecture for AI-assisted software delivery.
Why This Goes Beyond Claude Code
There’s another reason I want Intent separate from the execution engine.
Today the engine may be Claude Code.
Tomorrow it might be Cursor.
Gemini.
ChatGPT.
Or something that doesn’t exist yet.
The engineering goal:
Add customer-account integration.
doesn’t belong to Anthropic.
Neither do:
Inputs
Outputs
Constraints
Success Criteria
Evidence
Those belong to the engineering problem.
Conceptually:
|
+-------------+-------------+
| | |
Claude Code Cursor Gemini
| | |
+-------------+-------------+
|
Same engineering intent
The execution technology can change.
The Intent survives.
That’s why I believe Intent should become a first-class engineering artifact.
The Convergence
For me, this is where two ideas that initially seemed separate finally converge.
Anthropic’s work gives us increasingly sophisticated mechanisms for controlling:
what Claude knows
when Claude knows it
how knowledge enters context
how work can be isolated
how agents exchange findings
how reusable knowledge is supplied
how external systems are accessed
how non-negotiable rules are enforced
That’s Context Engineering.
Intent-Driven Engineering supplies the durable contract above that execution environment:
what must happen
what inputs matter
what outputs are expected
what constraints apply
what success means
what evidence proves completion
when the system should stop
That’s Intent Engineering.
Neither replaces the other.
They strengthen one another.
Intent tells the system what must be accomplished. Context Engineering makes sure each reasoning component receives exactly what it needs to accomplish its part.
Then Skills supply organizational knowledge.
Subagents provide isolated reasoning environments.
Tools perform actions.
MCP connects governed external systems.
Hooks enforce non-negotiable boundaries.
Validation proves that the Intent was satisfied.
From Prompt Engineering to Engineering Systems
We started by asking:
How do I write a better prompt?
Then:
How do I give the model better context?
Then:
How should context move between agents?
Now we’re asking:
What governs the purpose of the entire system?
That’s where Intent-Driven Engineering enters.
Prompt Engineering optimizes the instruction.
Context Engineering optimizes what the model knows.
Agent architecture optimizes how reasoning is distributed.
Intent-Driven Engineering governs what the entire system is trying to accomplish and what successful completion means.
Put those together and AI-assisted development stops looking like a developer having a long conversation with a coding assistant.
It starts looking like an engineering system.
And that’s the convergence I find most exciting:
Anthropic is giving us the Context Architecture. Intent-Driven Engineering gives that architecture a durable mission.
The Intent sits above the execution machinery.
Context flows downward only where needed.
Findings flow upward only where useful.
And the entire system remains anchored to one question:
What are we actually trying to accomplish?
Comments