The Book Describes the Destination. Your Team Chooses the Road.

In Intent-Driven Engineering, the book describes a canonical version of Intent-Driven Engineering.

That distinction matters.

A canonical architecture describes what a mature implementation should be capable of doing. It establishes the principles, controls, artifacts, evidence, governance, and feedback loops that allow Intent-Driven Engineering to operate across an enterprise.

It does not mean every organization needs to implement every component on day one.

And it certainly doesn't mean every developer should have to ask permission from a central system every time an AI agent wants to do some work.

The book intentionally focuses heavily on what should happen:

  • Intent should be explicitly defined.
  • Intent should be durable.
  • Intent should be structured.
  • Intent should be versioned when appropriate.
  • Intent should be validated.
  • Execution should trace back to Intent.
  • Success should be measured against the Success Criteria.
  • Evidence should demonstrate whether the Intent was actually achieved.
  • Organizations should eventually be able to measure the business impact of AI-assisted engineering.

Those principles remain. But implementation is deliberately open.

A highly regulated financial organization might implement a stringent Intent Registry and require validation at multiple lifecycle gates. A 20-person development organization might keep Intent files in Git, run a local validator, and capture evidence at the end of delivery.

Both can practice Intent-Driven Engineering.

The architecture should support governance. It should not become the work.

Learn more about the methodology and book at LearnTeachMaster.org.

The Canonical Model Can Be More Than You Need on Day One

A mature Intent-Driven Engineering environment could eventually look something like this:

Business Intent
      ↓
Intent Artifact
      ↓
Schema Validation
      ↓
Intent Registry
      ↓
Version Validation
      ↓
Planning
      ↓
Implementation
      ↓
Verification
      ↓
Success Criteria
      ↓
Evidence
      ↓
Registry Update
      ↓
Business Metrics
      ↓
Outcome Measurement

Architecturally, there is nothing wrong with this. In fact, for a mature enterprise implementation, there is a lot that is right about it.

The problem appears when we interpret every box as:

STOP. CALL CENTRAL SYSTEM. WAIT FOR PERMISSION.

Do that enough times and we've created a Mother-May-I architecture.

That's not the objective.

Intent-Driven Engineering is supposed to make AI-assisted software delivery clearer, faster, repeatable, measurable, and more reliable. If our governance implementation makes delivery dramatically harder, we've missed part of the Intent ourselves.

A Lighter Implementation

There is a simpler way to preserve the important principles.

Start with the artifact that matters most: the Intent File.

The Intent file remains the execution contract. At minimum, a strong Intent file should clearly contain four elements:

Intent

What are we trying to accomplish and why?

Inputs

What information, events, requests, dependencies, or conditions enter the capability?

Outputs

What must the capability produce?

Success Criteria

How will we objectively determine that the Intent was achieved?

Those four elements give humans and AI agents a shared definition of the work.

Add lightweight identity where appropriate:

---
id: INT-BILL-042
name: Billing Adjustment
version: 1.3.0
owner: billing-platform
---

Now we have enough information to establish lineage without turning the Intent file into a governance encyclopedia.

Validate Locally

The first control doesn't need AI. It doesn't even require a central registry lookup.

A simple hook or validation utility can verify:

✓ Intent exists
✓ Inputs exist
✓ Outputs exist
✓ Success Criteria exist
✓ Intent ID exists
✓ Owner exists
✓ Version is valid

If something critical is missing:

INTENT VALIDATION FAILED
✓ Intent
✓ Inputs
✗ Outputs
✗ Success Criteria
✓ Owner
✓ Version

Complete the required Intent contract before implementation.

That's valuable governance. And it happened locally in milliseconds.

No agent reasoning. No token consumption. No central database query. No waiting.

Then Let the Intent Drive the Work

Once validated, the Intent file should do what it was created to do. Drive execution.

                 INTENT
                   │
             Local Validate
                   │
                   ▼
                  PLAN
                   │
                   ▼
               EXECUTE
                   │
                   ▼
                VERIFY
                   │
                   ▼
        SUCCESS CRITERIA CHECK
                   │
                   ▼
                EVIDENCE

Claude Code can work from it. Cursor can work from it. GitHub Copilot can work from it. Another agentic engineering platform can work from it.

The methodology should not depend on the AI vendor. The Intent remains durable while the execution technology changes.

Stop Asking the Registry for Permission

This is an important refinement.

The Intent Registry should not necessarily sit synchronously between every stage of execution.

Instead of:

Intent → Ask Registry → Plan → Ask Registry → Implement → Ask Registry → Verify

Use:

Intent → Validate → Plan → Implement → Verify → Evidence → Registry

The registry becomes an evidence and enterprise-memory layer. That is a very different responsibility.

The Intent drives execution. Evidence feeds the registry.

Record Where You Can, When You Can

The implementation doesn't have to capture everything synchronously.

Meaningful lifecycle events can be recorded when they occur:

INTENT_CREATED
INTENT_VALIDATED
PLAN_CREATED
IMPLEMENTATION_STARTED
IMPLEMENTATION_COMPLETED
SUCCESS_CRITERIA_VERIFIED
PR_CREATED
DEPLOYED

Each event can carry a very small amount of information:

intent_id
intent_version
repository
commit
timestamp
status
evidence

That information can be pushed to a Registry API. Or published as an event. Or processed asynchronously.

The developer doesn't need to manage it. The coding agent doesn't need to reason about it. The engineering workflow simply produces evidence as a natural consequence of doing the work.

The Registry Becomes Enterprise Memory

This makes the Registry much more useful.

It isn't merely: “Does INT-BILL-042 exist?”

Instead, over time it can answer:

  • What did we intend to accomplish?
  • Which version was implemented?
  • Who owned it?
  • When did implementation begin?
  • When did it reach production?
  • Did it pass its Success Criteria?
  • What evidence demonstrated completion?
  • How much rework occurred?
  • How much did AI-assisted delivery cost?
  • Did the resulting capability produce the intended business outcome?

Now we're getting somewhere.

The Real Measurement Isn't Registry Compliance

Ultimately, an executive isn't going to ask: “How many Intent Registry validations did we perform?”

The executive question is much simpler:

What has AI done for me lately?

That's the question an Intent-Driven Engineering measurement system should eventually answer.

Imagine being able to report:

127 Intents entered delivery
112 reached production
103 satisfied their defined Success Criteria
81% first-pass success rate

Intent-to-production time:   ↓ 31%
Rework:                      ↓ 24%
Cost per successful Intent:  ↓ 22%
Shared-service reuse:        ↑ 18%

Those numbers mean something to the business.

Token counts alone don't. Prompt counts don't. Number of AI users doesn't. Lines of AI-generated code certainly don't.

The important unit becomes: Successful Intent Delivered.

That's one of the reasons Success Criteria are so important. They connect the original statement of Intent to measurable evidence at the other end of the delivery loop.

Three Layers Instead of One Giant Governance System

A practical implementation can therefore be understood as three layers.

Layer 1 — Intent Contract

This is what developers and AI agents work from: Intent, Inputs, Outputs, Success Criteria, Identity, Version.

Keep it understandable. Keep it portable. Keep it close to the code.

Layer 2 — Execution Loop

This is where the engineering happens:

Understand → Plan → Implement → Test → Verify → Produce Evidence

The Intent file remains the contract throughout the loop.

Layer 3 — Evidence and Intelligence

This is where the enterprise learns:

Registry
   + Lifecycle Events
   + Delivery Evidence
   + Success Results
   + Cost Metrics
   + Business Metrics
            ↓
Enterprise Intelligence

This layer can become increasingly sophisticated without continuously adding friction to the developer workflow.

Two Levels of Governance

Not every application needs identical governance. That's another place where organizations should be pragmatic.

Light Governance

The default for many teams could be:

Local validation → Execute from Intent → Verify Success Criteria → Publish evidence

The central registry is updated when practical. A registry outage doesn't stop someone from writing code.

Strict Governance

Certain workloads may require more, for example: financial transactions, security-sensitive systems, regulated workloads, critical production APIs, personally identifiable information, and high-risk infrastructure.

Those organizations might require:

Intent
  ↓
Central Validation
  ↓
Approved Version
  ↓
Implementation
  ↓
Verification
  ↓
CI/CD Governance Gate
  ↓
Deployment

Same methodology. Different implementation rigor. That's exactly what an enterprise engineering framework should allow.

Shared Services Should Follow the Same Philosophy

The same principle applies to reusable enterprise capabilities.

Suppose an organization has: /create-api, /create-tmf, /create-event, /create-microservice.

Those skills can already understand enterprise standards. They can generate properly structured Intent files. They can validate them locally. They can use approved architecture patterns. They can produce implementation plans. And they can emit evidence when the work progresses.

They don't need to constantly ask the Registry what they're allowed to do.

When discovery, reuse analysis, dependency analysis, or governance requires central intelligence, then call the Registry or Intent Control Plane.

Use central intelligence when central intelligence provides value. Don't create network traffic and process ceremony merely because an architecture diagram contains a registry box.

Let Background Agents Do the Administrative Work

There is another powerful opportunity.

Much of the deeper Intent intelligence does not have to happen inside the developer's interactive session at all. Background agents can do it.

For example, Python-based agents running inside Kubernetes could consume Intent lifecycle events.

Developer / AI Coding Tool
           │
           ▼
       Intent File
           │
           ▼
    Engineering Loop
           │
           ▼
      Intent Events
           │
           ▼
       Queue / Bus
           │
     ┌─────┼─────┐
     ▼     ▼     ▼
 Registry Metrics Analysis
  Agent   Agent   Agent
     └─────┼─────┘
           ▼
  Intent Control Plane

These agents can work asynchronously without slowing the developer down.

What Could the Background Agents Do?

A Registry Agent could:

  • Register new Intent artifacts.
  • Reconcile ownership.
  • Maintain history.
  • Detect stale records.
  • Update deployment state.

A Metrics Agent could:

  • Calculate Intent-to-production time.
  • Calculate first-pass success.
  • Track rework.
  • Track cost per successful Intent.
  • Aggregate Success Criteria results.

An Intelligence Agent could eventually:

  • Generate semantic embeddings.
  • Detect similar Intent.
  • Identify possible duplication.
  • Discover dependencies.
  • Analyze impact.
  • Recommend REUSE, EXTEND, or CREATE.

A Validation Agent could:

  • Compare implementation evidence against Success Criteria.
  • Find missing evidence.
  • Identify inconsistencies.
  • Flag Intent that appears complete but has not demonstrated the expected outcome.

The developer doesn't need to wait for most of that. The platform learns in the background.

The Registry Can Still Become the Intent Control Plane

None of this diminishes the long-term importance of the Registry. It actually makes the Registry more valuable.

The progression can still be:

V1  VALIDATE + REGISTER
          ↓
V2  VERSION + HISTORY
          ↓
V3  SEMANTIC INTELLIGENCE
          ↓
V4  IMPACT + DECISION INTELLIGENCE

But the important architectural change is this:

The Registry informs the engineering loop. It does not need to dominate the engineering loop.

That's a much healthier relationship.

Canonical Does Not Mean Mandatory Implementation

This is an important distinction when reading Intent-Driven Engineering.

A canonical architecture is intended to answer: “What would a complete implementation look like?”

It does not mean: “Every company must implement every component exactly this way before they can practice Intent-Driven Engineering.”

Organizations should adapt the implementation to their environment, maturity, risk, regulatory obligations, architecture, and engineering culture.

What should remain consistent are the principles:

  • Define Intent before execution.
  • Make Intent durable.
  • Give Intent sufficient structure.
  • Define Success Criteria before implementation.
  • Execute against the Intent.
  • Verify against the Intent.
  • Produce evidence.
  • Measure outcomes.

Everything around those principles can evolve.

The Lighter Intent-Driven Engineering Model

The practical model can be summarized in four sentences:

Define Intent rigorously. Don't compromise the quality of the Intent simply because we're reducing process.

Execute locally. Let engineers and AI tools work without unnecessary centralized dependencies.

Capture evidence continuously. Every meaningful stage of delivery should leave evidence when practical.

Centralize intelligence gradually. Start with a simple Registry. Add history. Add metrics. Add semantic intelligence. Add impact analysis. Add autonomous background agents when the organization is ready.

That gives us enterprise rigor without enterprise bureaucracy.

Don't Build a Registry Nobody Uses

There is a larger lesson here.

Architects love complete architectures. Boxes. Arrows. Control planes. Registries. Agents. Policies. Databases. Governance services.

All of those things can have value. But the architecture only matters if engineering teams actually use it.

Intent-Driven Engineering should therefore follow its own philosophy. Start with the Intent. Ask what outcome we're trying to achieve.

The outcome isn't: “Build an impressive Intent Registry.”

The outcome is: help humans and AI consistently deliver the right software, prove that it achieved its intended result, and give the business evidence that AI-assisted engineering is producing value.

If a lightweight implementation accomplishes that today, use it. If greater maturity requires stronger governance tomorrow, add it. If background agents can remove administrative work from developers, use them. If regulation requires a hard gate, enforce one.

The methodology provides the discipline. The architecture provides the possibilities. The organization chooses the implementation.

That was always the point.

Intent drives execution. Evidence feeds the registry. Intelligence grows over time.

Learn More

Intent-Driven Engineering was written as a practical framework for moving beyond prompt-driven development toward structured, repeatable, governed AI-assisted engineering. The methodology emphasizes defining clear Intent, creating durable engineering context, executing systematically, validating results, and producing evidence rather than simply generating code.

Explore Intent-Driven Engineering and the book at LearnTeachMaster.org.

Intent-Driven Engineering — by Mark Kendall