Intent-Driven Engineering Didn’t Start With AI: The Architecture Has Been Hiding in Networks for Years

Intent-Driven Engineering Didn’t Start With AI: The Architecture Has Been Hiding in Networks for Years

AI may have made intent executable. It did not invent the idea.

One of the most interesting things about working on Intent-Driven Engineering is discovering that some of its deepest architectural ideas have been developing in another part of computer science for years.

Not in generative AI.

Not in coding assistants.

Not in prompt engineering.

In network management.

In 2020, researchers Lei Pang, Chungang Yang, Danyang Chen, Yanbo Song, and Mohsen Guizani published an IEEE Access paper titled “A Survey on Intent-Driven Networks.”

The paper surveys the emerging field of Intent-Driven Networking (IDN): networks in which operators express desired outcomes at a higher level, while an underlying system translates those intentions into policies, configuration, orchestration, and ultimately changes to the network.

The authors deserve full credit for the work and the architecture described here:

Lei Pang, Chungang Yang, Danyang Chen, Yanbo Song, and Mohsen Guizani. “A Survey on Intent-Driven Networks.” IEEE Access, Volume 8, 2020, pp. 22862–22873. DOI: 10.1109/ACCESS.2020.2969208. (ResearchGate⁠)

Read “A Survey on Intent-Driven Networks” via DOI / IEEE⁠

What caught my attention was not simply the use of the word intent.

It was the architecture underneath it.

Because when you look at that architecture through the lens of modern AI-assisted software engineering, something becomes apparent:

We have seen this movie before.

From Configuration to Intent

Traditional network management is largely imperative.

An operator determines what needs to happen and then configures the individual pieces required to make it happen.

Change this parameter.

Configure this route.

Provision this resource.

Apply this policy.

Restart this component.

Verify the result.

The operator is effectively responsible for translating the desired business outcome into implementation instructions.

Software engineering has historically worked much the same way.

A requirement enters the organization and begins a long translation process:

Business Requirement → Epic → Story → Technical Design → Tasks → Code → Tests → Deployment

At every transition, humans translate meaning into increasingly detailed instructions.

Intent-driven systems challenge that model.

Instead of beginning with:

“Here are the steps the system should execute.”

they begin closer to:

“Here is the state I want the system to achieve.”

The machinery underneath determines how that state can safely be achieved.

That is an enormous architectural difference.

The Architecture in Intent-Driven Networking

The Pang et al. paper presents a particularly useful intent flow.

Conceptually, it progresses through:

Natural Language

↓

Intent Primitives

↓

Policy

↓

Verification

↓

Deployment

The paper’s broader architecture separates the system into layers that include applications, an Intent Northbound API, an intent controller, southbound APIs, and the underlying infrastructure.

The intent controller includes responsibilities such as intent-policy mapping, intelligent processing, automatic management/orchestration, and real-time verification. (ResearchGate⁠)

That means the human does not need to understand every implementation mechanism underneath the requested outcome.

There is a management abstraction between what is desired and how the infrastructure accomplishes it.

And that idea translates remarkably well into software engineering.

The Intent File Becomes the Management Interface

Consider the Intent File in Intent-Driven Engineering.

A good Intent File answers four fundamental questions:

Intent

What outcome should become true?

Inputs

What information and context are available?

Outputs

What should exist when the work is completed?

Success Criteria

How will we determine that the intent was actually satisfied?

That document isn’t supposed to contain every implementation instruction.

That’s the point.

It establishes a boundary between management intent and implementation mechanics.

In that sense, the Intent File begins to resemble the role played by an intent interface in networking.

Above it lives human meaning.

Below it lives execution machinery.

A Modern Intent-Driven Engineering Stack

Put the concepts together and a modern software engineering architecture begins to emerge:

Human / Business Intent

↓

Intent File

↓

Intent Compiler / Agentic Harness

↓

Enterprise Policies + Governance + Context

↓

Skills + Agents + MCP + Tools

↓

Repositories + APIs + Platforms + Infrastructure

↓

Tests + Telemetry + Verification

↺

Reconcile Result Against Original Intent

This is much more than AI generating code.

It is a management architecture for engineering.

And I think that’s an important distinction.

AI Is Not the Architecture

This also helps clarify something that is easily confused in today’s AI discussion.

Claude, ChatGPT, Copilot, Cursor, or whatever models and tools come next are not necessarily the architecture.

They are components inside the architecture.

The architecture is the operating model surrounding them.

The model might interpret intent.

An agent might create a plan.

A skill might provide reusable expertise.

An MCP server or other tool interface might connect the system to Jira, GitHub, ServiceNow, a database, or an internal API.

A deterministic hook might enforce a policy.

A workflow engine might orchestrate execution.

Telemetry might observe what happened.

Tests might verify the resulting state.

And an intent engine can compare that resulting state against what was originally requested.

That entire system is larger than the LLM.

The LLM is one engine inside an intent-driven operating system for engineering.

Intent → Translate → Execute → Observe → Verify → Adjust

This is perhaps the most important connection between Intent-Driven Networking and Intent-Driven Engineering.

Intent isn’t merely something you write at the beginning.

It remains relevant throughout execution.

The operating loop becomes:

Intent

↓

Translate

↓

Plan

↓

Execute

↓

Observe

↓

Verify

↓

Adjust

↺

The result feeds back into the system.

That creates a closed loop.

The Pang et al. paper describes IDN in terms of self-driving networks using decoupled network-control logic and closed-loop orchestration to automate application intents. It also discusses the need for self-configuration, self-management, and self-optimization. (ResearchGate⁠)

Those concepts should sound familiar to anyone building modern agentic engineering systems.

From a Development Tool to a Management System

This perspective changes how we think about Intent-Driven Engineering.

If we describe it merely as:

“Developers give AI better requirements.”

we undersell it.

The larger opportunity is:

Management declares desired engineering outcomes, while an intent-driven engineering system translates, governs, executes, observes, verifies, and continuously reconciles implementation against those outcomes.

That starts looking less like a coding assistant.

It starts looking like an engineering management system.

And importantly, management here does not mean people management.

It means system management.

The same way network management systems operate networks, an intent-driven engineering environment can increasingly manage the execution of software change.

The Developer Moves Up the Abstraction Stack

This does not eliminate developers.

It changes where their expertise is applied.

Consider networking.

Network engineers did not become unnecessary because software-defined networking abstracted individual device configuration.

Their work moved upward.

They design policies.

They establish constraints.

They define topology.

They manage reliability.

They investigate exceptions.

They determine architecture.

They govern the system.

Something similar can happen in software engineering.

Instead of spending most of the day translating requirements into thousands of implementation instructions, developers increasingly operate at the level of:

Intent.

Architecture.

Constraints.

Patterns.

Policies.

Interfaces.

Verification.

Exceptions.

The machine handles more of the translation.

The engineer becomes responsible for ensuring that the translation is correct.

Deterministic Controls Still Matter

This is another place where networking provides a useful lesson.

Intent does not mean:

“Tell an intelligent system what you want and hope for the best.”

Intent-driven architectures require control.

Some things can be probabilistic.

Others absolutely should not be.

An AI model might interpret an ambiguous requirement.

But a security policy may need deterministic enforcement.

An agent might propose an implementation.

But a deployment gate may require deterministic validation.

A model might generate code.

But tests determine whether that code satisfies defined behavior.

A workflow might perform multiple operations.

But idempotency, bounded retries, compensation, authorization, and auditability remain engineering responsibilities.

This gives us a clean architectural separation:

Probabilistic intelligence interprets and reasons.

Deterministic systems govern and verify.

Intent sits above both.

The Closed Loop May Be More Important Than the Agent

There is enormous attention today on autonomous agents.

But autonomy without verification isn’t particularly useful in enterprise engineering.

The more interesting system is the closed loop:

Desired State → Execution → Actual State → Verification → Correction

That loop exists in many mature engineering disciplines.

Kubernetes reconciles desired state against actual state.

Infrastructure-as-Code declares desired infrastructure.

Control systems continuously measure and adjust physical systems.

Intent-driven networking applies similar thinking to network management.

Intent-Driven Engineering extends that principle upward into software delivery.

The objective isn’t:

“Have an AI agent write some code.”

The objective becomes:

Continuously reconcile engineering reality with declared intent.

That is a much bigger idea.

The Intent Registry Makes More Sense Through This Lens

This perspective also provides a useful way to understand an Intent Registry.

The registry is not necessarily a giant command-and-control system through which every development action must pass.

It can be much simpler.

It is the historical record of declared desired states.

An Intent File says:

This is what we intended to become true.

The repository shows:

This is what we implemented.

Tests show:

This is what behaves correctly.

Telemetry shows:

This is what actually happened.

The registry can connect those pieces over time.

Now we can ask much more meaningful engineering questions.

Did the implementation satisfy the intent?

Did the production outcome satisfy the success criteria?

Which intents failed?

Which intents were modified?

Which architectural patterns repeatedly succeed?

Where are humans repeatedly intervening?

Where are agents failing?

Where should automation improve?

Intent becomes an organizing dimension for engineering telemetry.

This Also Explains Beacons and Orchestration

It even provides a cleaner way to think about the small background services and agents that operate throughout an intent-driven environment.

A Beacon does not need to be the intelligence of the entire system.

It can perform a narrow management responsibility:

Observe.

Validate.

Measure.

Reconcile.

Notify.

Record.

Repair.

A workflow orchestrator can coordinate a long-running process.

A policy service can validate constraints.

An observability Beacon can determine whether an implementation continues to meet its success criteria.

A registry Beacon can record intent lifecycle events.

A Saga can coordinate distributed execution and compensation.

The architecture becomes a collection of management capabilities operating underneath the intent layer.

That is much easier to reason about than imagining one enormous autonomous AI agent running the enterprise.

Networking Was Solving the Same Abstraction Problem

This is why the IEEE paper adds such an interesting perspective.

Networking had already encountered the underlying problem.

Modern networks became too complex for humans to efficiently manage every low-level configuration individually.

So researchers and vendors began moving toward higher-level abstractions.

Software engineering is reaching a similar point.

Modern enterprise systems contain:

microservices,

APIs,

cloud infrastructure,

event streams,

databases,

security policies,

CI/CD pipelines,

observability platforms,

third-party SaaS systems,

legacy applications,

and increasingly AI agents themselves.

Humans cannot economically micromanage every interaction forever.

We need another abstraction layer.

That layer may be intent.

And Now AI Changes What Is Possible

This is where generative AI becomes transformative.

Intent-based systems existed before modern LLMs.

The networking community is proof of that.

Indeed, the IETF later standardized terminology around Intent-Based Networking in RFC 9315, describing intent as a declarative way of expressing desired outcomes rather than prescribing specific implementation steps. (IETF Datatracker⁠)

But software intent has historically been difficult to interpret because human requirements are messy.

Natural language is ambiguous.

Business terminology changes.

Repositories contain enormous amounts of implicit knowledge.

Architectural conventions are rarely documented perfectly.

Modern language models dramatically improve our ability to bridge that gap.

They can reason across:

Natural Language → Repository Context → Architecture → Plan → Implementation

That may be the missing compiler.

Not a traditional compiler producing machine code.

An intent compiler translating human outcomes into governed engineering actions.

Define Intent → Compile Action → Deliver Impact

This leads back to a simple operating model for Intent-Driven Engineering:

Define Intent

Humans define the desired outcome, boundaries, inputs, outputs, constraints, and success criteria.

↓

Compile Action

AI-assisted engineering systems combine that intent with repository context, enterprise knowledge, policies, skills, tools, and architecture to determine the work required.

↓

Deliver Impact

The system executes, tests, observes, validates, and measures whether the requested outcome was actually achieved.

And then the loop continues.

Define Intent → Compile Action → Deliver Impact → Measure → Reconcile

That final reconciliation step is increasingly important.

Because software delivery isn’t finished when code is generated.

It is finished when the intended outcome becomes true.

Intent-Driven Engineering Didn’t Start With AI

And perhaps that’s the biggest lesson.

The architectural principle behind Intent-Driven Engineering isn’t dependent upon generative AI.

Intent-based systems have a much longer lineage across networking, autonomous systems, orchestration, policy management, desired-state systems, and control theory.

What generative AI changes is the economics and practicality of the translation layer.

We can finally take rich human intent and dynamically translate it into increasingly sophisticated machine action.

That makes something possible at the engineering level that networking researchers have been pursuing at the infrastructure level for years.

Not simply automation.

Not simply agents.

Not simply code generation.

A managed, governed, closed-loop system where humans increasingly specify what must become true, and the engineering platform determines, within defined boundaries, how to make it true and how to prove that it happened.

That is the larger opportunity behind Intent-Driven Engineering.

And sometimes the best way to understand where software engineering is going is to look at an architecture another discipline has already been building.

Credit and Further Reading

This article was inspired by the architecture and concepts presented in:

Lei Pang, Chungang Yang, Danyang Chen, Yanbo Song, and Mohsen Guizani, “A Survey on Intent-Driven Networks,” IEEE Access, Vol. 8, pp. 22862–22873, 2020. DOI 10.1109/ACCESS.2020.2969208. The paper was received in December 2019, accepted in January 2020, and published in IEEE Access in 2020. (ResearchGate⁠)

Read the original paper via DOI / IEEE⁠

The authors’ work concerns Intent-Driven Networking. The extension of those architectural ideas into Intent-Driven Engineering, Intent Files, agentic harnesses, engineering Beacons, and the software-development operating model discussed above is my interpretation and application of those concepts to modern software engineering.

That distinction matters.

Good ideas deserve lineage.

And this one has a fascinating lineage.