The Intent-Driven Enterprise Needs an Operating Model
- Mark Kendall
- 3 days ago
- 12 min read
Why Intent-Driven Engineering Must Extend Far Beyond the Developer
Intent-Driven Engineering first became visible inside software development.
Developers began moving beyond isolated prompts and informal AI experimentation. They started capturing intent in durable files, giving AI agents the context required to inspect repositories, develop plans, implement bounded changes, run validations, and prepare software for human review.
That was an important beginning.
But it was only the beginning.
If Intent-Driven Engineering remains centered on developers generating code, it cannot become an enterprise operating model. It becomes another development technique—powerful and potentially transformative, but still limited to one role and one portion of the organization.
The enterprise is much larger than the engineering workstation.
It includes business leaders, product owners, delivery leads, scrum masters, architects, developers, quality engineers, security teams, DevOps engineers, platform teams, release managers, operations personnel, governance leaders, and financial stakeholders.
Every one of these groups influences what is built, why it is built, how it is validated, how it reaches production, how it is governed, and whether it delivers the intended result.
The future, therefore, is not merely intent-driven development.
It is not even limited to intent-driven delivery.
The future is the Intent-Driven Enterprise.
Forbes Saw the Enterprise-Level Shift Coming
In the Forbes Technology Council article “The Rise of the Intent-Driven Enterprise,” Manish Garg, cofounder and chief product officer of Skan.ai, describes an organizational shift from systems that require people to navigate rigid processes toward systems capable of understanding desired outcomes and helping orchestrate the work required to achieve them.
That is an important signal.
The concept is no longer confined to prompt engineering, software generation, or isolated AI agents. The conversation is moving toward an enterprise in which intent can guide processes, decisions, systems, digital workers, and organizational execution.
Forbes gives us the larger destination:
The Intent-Driven Enterprise.
Intent-Driven Engineering provides a practical operating model for reaching it.
The distinction matters.
The Intent-Driven Enterprise is the organizational vision.
Intent-Driven Engineering is the discipline that makes human purpose explicit, executable, governable, and verifiable as it moves through the enterprise.
It connects strategy to execution.
It connects business outcomes to software.
It connects human decisions to AI agents.
It connects delivery activity to production evidence.
It connects technology spending to measurable value.
This is where the model becomes much larger than the developer.
From Intent-Driven Engineering to the Intent-Driven Enterprise
The Intent-Driven Enterprise begins with a simple idea:
The enterprise should organize work around clearly expressed outcomes rather than forcing people and AI systems to reconstruct purpose from fragmented instructions, disconnected tools, and inherited processes.
Today, most organizations distribute intent across dozens of locations:
Executive presentations
Product roadmaps
Jira tickets
Confluence pages
Architecture diagrams
Figma designs
Source-code repositories
Test plans
Security policies
Helm charts
Deployment pipelines
Operational runbooks
Monitoring dashboards
Email threads
Meetings
Individual experience
Each artifact contains part of the truth.
No single role sees the complete intent.
The business understands the desired result.
Product understands the capability.
Architecture understands the structural constraints.
Developers understand the implementation.
Quality understands the evidence.
Security understands the risk.
DevOps understands the deployment.
Operations understands the production reality.
The enterprise problem is not that these roles exist.
The problem is that their intent is fragmented.
Intent-Driven Engineering creates a shared structure through which that intent can travel.
Enterprise intent
↓
Strategic intent
↓
Business outcome intent
↓
Product and delivery intent
↓
Architecture and engineering intent
↓
Quality and security intent
↓
Deployment and operational intent
↓
Production evidence
↓
Measured enterprise outcome
That is the foundation of the Intent-Driven Enterprise.
The Enterprise Cannot Operate Through Developer Intent Alone
Software developers were the natural starting point because generative AI first created an obvious transformation in code production.
But code is only one expression of enterprise intent.
A development agent may generate technically correct software while misunderstanding the desired business outcome.
A testing agent may create hundreds of tests without proving the behavior that truly matters.
A deployment pipeline may successfully release an application without understanding whether two active consumers will create duplicate messages.
An observability platform may collect millions of signals without knowing which signals indicate that the original outcome was achieved.
A delivery dashboard may report that every task is complete while the initiative still fails to produce value.
AI does not automatically eliminate organizational fragmentation.
Uncontrolled AI can accelerate it.
Speed without shared intent produces faster divergence.
The Intent-Driven Enterprise needs every major role to express, refine, execute, validate, and measure the intent for which it is responsible.
One Enterprise, Multiple Forms of Intent
Not every role should write the same file.
Not every role should interact with the same AI agent.
Not every role should become a software engineer.
Instead, every role should express its responsibilities in a form that is:
Explicit
Understandable
Reviewable
Traceable
Governable
Verifiable
Usable by humans and AI systems
The business expresses outcome intent.
Product expresses capability intent.
Delivery expresses coordination and completion intent.
Architecture expresses structural intent.
Development expresses implementation intent.
Quality expresses validation intent.
Security expresses protection and prohibition intent.
DevOps expresses deployment and recovery intent.
Operations expresses runtime intent.
Finance expresses economic intent.
Governance expresses authority and accountability intent.
Together, these forms of intent create the operating model of the Intent-Driven Enterprise.
The Intent-Driven Delivery Lead
The traditional delivery lead is often responsible for schedules, milestones, dependencies, staffing, risk, and status reporting.
Those responsibilities remain important, but the Intent-Driven Enterprise requires a broader mandate.
The modern delivery lead becomes the Intent-Driven Delivery Lead.
This role owns the integrity of intent from the original business request through production realization.
The delivery lead is no longer merely asking whether tasks were completed.
The delivery lead asks:
Are we solving the right problem?
Is the expected business outcome measurable?
Are all disciplines working from the same intent?
Are assumptions and dependencies visible?
Are the required controls in place?
Does sufficient evidence exist to authorize release?
Did the production result create the intended value?
Core responsibilities
The Intent-Driven Delivery Lead:
Establishes the delivery outcome with business and product leadership.
Ensures that scope, exclusions, assumptions, and dependencies are visible.
Coordinates product, architecture, engineering, quality, security, DevOps, and operations.
Resolves conflicts among different forms of intent.
Defines release-readiness expectations.
Maintains end-to-end intent traceability.
Owns delivery exceptions and material deviations.
Measures whether the initiative produced its intended result.
Example delivery intent
initiative: Customer Order Modernization
business_outcomes:
reduce_manual_processing: 40%
reduce_order_errors: 25%
included_scope:
- order validation
- downstream event publishing
- operational monitoring
excluded_scope:
- billing platform replacement
success_measures:
- production error rate below 1%
- no duplicate downstream events
- order processing completed within 3 seconds
release_authority:
delivery_lead: required
quality_lead: required
operations_lead: required
The delivery lead owns the complete outcome—not merely the schedule used to pursue it.
The Scrum Master Becomes the Guardian of Intent Flow
The scrum master traditionally facilitates ceremonies, helps remove blockers, protects the team, and keeps work moving.
In the Intent-Driven Enterprise, this role becomes even more consequential.
The scrum master becomes the Intent Flow Facilitator.
This person protects the clarity, readiness, movement, and synchronization of intent throughout delivery.
Core responsibilities
The Intent Flow Facilitator:
Ensures backlog items describe outcomes, not merely activity.
Facilitates intent-refinement sessions.
Identifies hidden assumptions and unresolved decisions.
Exposes dependencies before implementation starts.
Ensures acceptance expectations are testable.
Tracks changes to intent after work begins.
Prevents undocumented scope from entering delivery.
Coordinates intent across product, development, quality, and DevOps.
Maintains assumption, decision, and blocker records.
Measures rework caused by unclear or changing intent.
The refinement conversation changes.
The team does not ask only:
Is this story ready?
It asks:
Why are we doing this?
What outcome must change?
What must remain unchanged?
What assumptions are we making?
What evidence will demonstrate completion?
Which systems and teams are affected?
What result would cause us to reject the implementation?
What must happen after the capability reaches production?
This does not discard Agile.
It gives Agile a coherent operating model for an AI-enabled enterprise.
Quality Engineering Becomes Intent Assurance
Quality cannot remain a testing phase positioned near the end of delivery.
AI can now generate code, infrastructure, tests, documentation, and configuration at extraordinary speed.
That makes independent validation more important, not less.
The critical question is no longer:
Did all the tests pass?
The stronger question is:
Do the tests and evidence prove that the approved intent was fulfilled?
This creates the role of the Intent Assurance Engineer.
Core responsibilities
The Intent Assurance Engineer:
Converts business and technical outcomes into verifiable evidence.
Challenges ambiguous and untestable requirements.
Defines positive, negative, boundary, performance, security, and recovery expectations.
Verifies that AI-generated work remains within authorized scope.
Detects unintended behavior introduced by agents.
Protects existing behavior that must remain unchanged.
Establishes regression boundaries.
Defines post-deployment validation.
Maintains traceability among intent, tests, code, and production evidence.
Determines whether the evidence truly proves the desired outcome.
Example quality intent
feature: Order Event Publishing
required_behavior:
- publish one event for each completed order
- preserve the original correlation ID
- reject malformed payloads
- record failed delivery attempts
prohibited_behavior:
- duplicate business events
- publishing before transaction completion
- exposing customer information in logs
required_evidence:
- automated contract tests
- idempotency validation
- retry and recovery tests
- rollback verification
- production smoke test
Quality engineering becomes the independent assurance system for enterprise intent.
DevOps Becomes Intent-Driven Platform Engineering
The DevOps and platform layers demonstrate why intent cannot stop at the developer.
At this level, the objective is not simply:
Build the feature.
The operational intent is:
Deploy, protect, observe, scale, stop, recover, and reverse this capability according to declared rules.
This creates the role of the Intent-Driven Platform Engineer.
Helm charts, Kubernetes manifests, infrastructure definitions, pipelines, policies, security scans, observability controls, and recovery procedures all become implementations of declared operational intent.
Core responsibilities
The Intent-Driven Platform Engineer:
Translates release requirements into deployment intent.
Defines environment-specific constraints.
Establishes promotion and approval rules.
Defines scaling, shutdown, rollback, and recovery behavior.
Creates reusable Helm charts, pipelines, platform services, and policies.
Ensures that only approved artifacts reach production.
Establishes health checks and observability requirements.
Prevents unsafe cutovers and conflicting workloads.
Produces deployment evidence.
Makes recovery executable before production begins.
Example deployment intent
service: order-consumer
deployment:
platform: kubernetes
package: helm
namespace: production
minimum_replicas: 2
maximum_replicas: 8
consumer_ownership:
lambda_enabled: false
kubernetes_enabled: true
dual_active_consumers_allowed: false
rollback:
first_release:
immediate_action: scale_to_zero
complete_reversal: helm_uninstall
later_releases:
preferred_action: helm_rollback
health_requirements:
readiness_probe: required
liveness_probe: required
startup_probe: required
observability:
structured_logs: required
application_metrics: required
distributed_tracing: required
duplicate_event_alert: required
This is not simply infrastructure automation.
It is executable enterprise intent at the production boundary.
Developers Remain Central, but They Are Not the Enterprise
Developers remain foundational to Intent-Driven Engineering.
Their evolved role is the Intent Implementation Engineer.
The developer converts approved intent into working software while preserving architecture, constraints, protected behavior, and traceability.
Core responsibilities
The Intent Implementation Engineer:
Reviews and challenges feature intent.
Produces an implementation plan before changing code.
Identifies missing technical decisions.
Separates explicit requirements from assumptions.
Uses repository-aware AI agents for bounded implementation.
Maintains traceability among intent, code, tests, and evidence.
Records significant deviations.
Protects existing behavior.
Produces implementation evidence for quality and operations.
The developer implements an essential portion of the intent.
The developer does not independently own the entire enterprise outcome.
That distinction is what separates an AI coding practice from an enterprise operating model.
Security Expresses Protective Intent
Security is often treated as a collection of policies, scans, approvals, and controls added late in delivery.
The Intent-Driven Enterprise moves security intent upstream.
Security teams explicitly define:
What information may be accessed
What information may be retained
Which AI models and tools may be used
Which actions agents may perform
Which actions require human approval
What must never be written to logs
Which vulnerabilities block release
How credentials must be protected
How security events must be detected
How incidents must be contained
That intent can then become:
Agent permissions
Repository policies
CI/CD gates
Infrastructure controls
Runtime protections
Audit requirements
Automated compliance evidence
Security stops being a late-stage obstacle.
It becomes an active contributor to enterprise intent.
Operations Closes the Intent Loop
A capability is not complete when its code is merged.
It is not complete when the pipeline turns green.
It is not complete when Helm reports a successful release.
It is not complete merely because the Kubernetes pods are running.
It is complete when the capability behaves correctly in production and produces the intended result.
Operations owns the runtime truth.
The operations team defines:
What healthy behavior looks like
Which signals indicate degradation
Which thresholds require intervention
How incidents are escalated
How processing is safely stopped
How messages and transactions are reconciled
How recovery is validated
What production evidence returns to delivery and business leaders
This closes the enterprise intent loop:
Enterprise intent
↓
Implementation
↓
Validation
↓
Deployment
↓
Production behavior
↓
Measured outcome
↓
Enterprise learning
↓
Improved future intent
Without this loop, intent ends at deployment.
With it, intent becomes a continuously learning enterprise operating model.
Finance and FinOps Connect Intent to Economic Value
An Intent-Driven Enterprise must also understand the economic consequences of its decisions.
AI introduces new forms of variable consumption:
Tokens
Models
Agent execution
Cloud infrastructure
Vector storage
Tool calls
Automated testing
Observability volume
Human review time
The organization must be able to connect those expenses to meaningful units of value.
Enterprise objective
↓
Initiative
↓
Feature
↓
Repository and delivery team
↓
Human and AI activity
↓
Infrastructure and token consumption
↓
Production outcome
↓
Cost per unit of enterprise value
FinOps intent defines:
Budget boundaries
Model-selection policies
Team and project attribution
Usage thresholds
Exception authority
Showback and chargeback rules
Cost-to-outcome measurements
This turns AI spending from an unexplained vendor invoice into governed enterprise investment.
One Capability, Multiple Intent Views
The organization should not place every decision from every discipline into one enormous intent file.
That would recreate the oversized requirements documents of the past.
A better approach is a connected collection of smaller artifacts with clear ownership.
/features/ORDER-1427/
│
├── feature.md
├── decisions.md
└── evidence/
├── test-results.md
Each artifact answers a different question.
Role
Primary question
Executive leadership
What enterprise result are we pursuing?
Product
Why should this capability exist?
Delivery Lead
How will the complete outcome be delivered?
Scrum Master
Is the intent clear, ready, and flowing?
Architect
What structural constraints govern it?
Developer
How will the software fulfill it?
Quality Engineer
What evidence proves it works?
Security
What must be protected or prohibited?
DevOps
How will it be deployed and reversed?
Operations
How will we know it is healthy?
Finance
Was the outcome worth the investment?
The views remain distinct.
The intent remains connected.
The Intent-Driven Enterprise Lifecycle
The Intent-Driven Enterprise needs a lifecycle that extends from strategy through production learning.
1. Establish Enterprise Intent
Leadership defines:
The problem or opportunity
The desired enterprise outcome
Strategic boundaries
Investment constraints
Measures of success
Accountable ownership
2. Translate Intent
Product and delivery translate enterprise intent into:
Capabilities
Initiatives
Value streams
Delivery outcomes
Priorities
Dependencies
3. Refine Intent
Delivery leads and scrum masters ensure:
Assumptions are visible
Decisions have owners
Dependencies are identified
Outcomes are measurable
Acceptance expectations are testable
Unresolved questions are not buried in implementation
4. Plan Execution
Architecture, development, quality, security, DevOps, operations, and finance define:
Implementation
Validation
Protection
Deployment
Observability
Recovery
Cost controls
5. Execute
Humans and AI systems:
Implement software
Configure infrastructure
Create tests
Apply controls
Deploy capabilities
Produce evidence
6. Validate
Each discipline validates its portion of enterprise intent.
Development validates implementation.
Quality validates behavior.
Security validates protection.
DevOps validates deployment.
Operations validates runtime readiness.
Finance validates economic boundaries.
Delivery validates the complete outcome.
7. Release and Operate
The capability reaches production only when required evidence exists and accountable people authorize the transition.
8. Measure the Outcome
Production evidence is compared with the original enterprise intent.
Did the outcome occur?
Did customers receive the intended benefit?
Did quality remain acceptable?
Did operational risk remain controlled?
Was the investment economically justified?
What unintended consequences appeared?
9. Learn and Adapt
The results improve:
Future intent
Agent skills
Templates
Policies
Quality strategies
Platform controls
Security rules
Cost models
Enterprise decisions
That is how the Intent-Driven Enterprise becomes more capable over time.
A Practical 90-Day Starting Plan
No organization needs to transform every role and process at once.
The transition should begin with one cross-functional delivery team.
Days 1–30: Move Beyond Developer Intent
Introduce five connected artifacts:
Assign a clear owner to each.
The immediate objective is to ensure that every production feature has explicit business, implementation, quality, deployment, and recovery intent.
Days 31–60: Establish Role-Based Intent
Create templates and AI-assisted workflows for:
Business-outcome review
Delivery-intent review
Feature readiness
Assumption detection
QA evidence generation
Security validation
Deployment readiness
Rollback verification
Production health review
Cost attribution
Begin measuring:
Clarification cycles
Rework
Escaped defects
Deployment failures
Recovery readiness
Intent changes after implementation starts
Cost per delivered outcome
Time from approved intent to production
Days 61–90: Establish the Enterprise Control Loop
Introduce two cross-functional control points.
Intent Review
Before implementation, confirm that the outcome, scope, assumptions, constraints, validation, deployment, recovery, and economic boundaries are sufficiently clear.
Intent Evidence Review
Before production, confirm that each discipline has produced the evidence required to demonstrate that its portion of the approved intent was fulfilled.
Connect the artifacts to the existing enterprise ecosystem:
Strategy and portfolio systems
Jira
Confluence
Figma
GitHub or GitLab
CI/CD
Security scanning
Kubernetes
Helm
Cloud platforms
Observability systems
FinOps platforms
Production support tools
At that point, intent is no longer passive documentation.
It becomes the enterprise control plane.
Intent-Driven Engineering Is the Engine
Forbes has helped elevate the conversation to the appropriate level: the rise of the Intent-Driven Enterprise.
That is the destination.
But an enterprise vision still needs an operating model.
It needs roles.
It needs artifacts.
It needs authority.
It needs lifecycle controls.
It needs evidence.
It needs a way to connect business purpose to technical execution and production results.
That is where Intent-Driven Engineering fits.
The Intent-Driven Enterprise is the vision. Intent-Driven Engineering is the operating model that makes the vision executable.
Intent-Driven Engineering does not replace Agile.
It gives Agile an AI operating model.
It does not replace DevOps.
It gives DevOps explicit deployment, operational, and recovery intent.
It does not replace quality engineering.
It gives quality a stronger standard than test completion.
It does not replace architecture.
It makes architectural constraints durable and executable.
It does not replace governance.
It makes governance visible throughout execution.
It does not remove human responsibility.
It makes responsibility clearer.
The Future Is the Intent-Driven Enterprise
Intent-Driven Engineering may have first emerged through developers and AI coding agents, but its future extends across the entire enterprise.
A mature Intent-Driven Enterprise works differently:
Leadership establishes the desired outcome.
Product translates it into capabilities.
Delivery coordinates it.
Scrum protects its clarity and flow.
Architecture defines its structural boundaries.
Developers implement it.
Quality proves it.
Security protects it.
DevOps deploys and reverses it.
Operations measures it.
Finance connects it to economic value.
The enterprise learns from it.
That is the complete model.
Intent-Driven Engineering is not a developer workflow built around a better requirements file. It is the operating model through which the Intent-Driven Enterprise transforms human purpose into governed, verifiable, secure, operational, and economically accountable outcomes.
Forbes has identified the rise of the Intent-Driven Enterprise.
Now the enterprise needs a practical way to operate as one.
That is the work ahead.
And that is where Intent-Driven Engineering leads.
:::
The critical positioning is now unmistakable: Forbes identifies the destination; Intent-Driven Engineering supplies the enterprise operating model.
Comments