Something is happening to your work that has happened only a handful of times in the history of software. A layer of it is being absorbed by machines. Not the meetings about the work, not the judgment inside it, the production itself, the drafting and building and testing that has filled the middle of every org chart for seventy years. And if history is any guide, what happens next is not that the people disappear. A new discipline forms around what machines cannot do, it gets a name, and the people who move toward it early spend the next decade looking prescient.
What follows names that discipline. The pattern is the argument, and I have watched it run at least three times.
The first time was agile. In 2001 I was running my first software company, a company called Jaxara, and we worked in small iterations for the least philosophical reason there is. Short cycles were how I made sure customer dollars met customer need before the money ran out. When the Manifesto was published and named what was keeping us alive, I signed it [1], one among thousands.
The second time was 2009. Two engineers from Flickr, John Allspaw and Paul Hammond, gave a talk at the Velocity conference called "10+ Deploys per Day" [2], and the wall between development and operations, a wall entire org charts had been built on, started to look like a choice rather than a law of physics. Within three years the choice had a name, DevOps, then a hiring category, then a conference circuit. Google formalized its own version and wrote the book on Site Reliability Engineering [3].
The third time was the data engineer. Somewhere in the mid-2010s, the person who wrangled pipelines stopped being a database administrator having a bad decade and became a discipline with its own titles, tools, and career path.
The pattern underneath all three has a name in operations theory. In his Theory of Constraints, Eliyahu Goldratt taught a generation that every system is governed by its binding constraint, and that improving anything else is an illusion of progress [4]. Each naming I watched was the industry following the constraint. The web made shipping cheap, so learning became the constraint, and the discipline that formed around it was agile. The Manifesto was a constraint diagnosis before anything else, and the ceremonies were implementations of that bet. Automation made deployment cheap, so flow became the constraint, and DevOps formed. Cloud infrastructure made data cheap, so trustworthy pipelines became the constraint, and the data engineer appeared. When machines absorb a layer of work, the discipline does not disappear. It moves up, concentrates around what stays scarce, and gets a name.
AI is now absorbing the layer nobody expected to industrialize this soon, the production of software and analysis itself. Google reported that AI generated a quarter of its new code in late 2024, then a third, then half, then three quarters this year [5]. Whatever discount you apply to one company's accounting, the trajectory is the point. Which raises the question. What concentrates above it, and what is its name?
Ambiguity at machine speed
There is a sentence I have watched arrive at delivery teams my whole career. It comes down from strategy in slightly different costumes, but it is always the same sentence. "Improve the customer experience." A worthy wish. Nothing in it can be built, checked, or accepted. It needs interpretation, and every interpreter hears it differently. The product owner hears a UI refresh. The architect hears a data problem. The delivery lead hears a quarter of roadmap.
This was always the expensive part. The Standish Group's original CHAOS report found incomplete requirements to be the single most cited factor in impaired software projects, and that was in 1994 [6]; three decades of process innovation never dislodged the finding, only renamed it. Fred Brooks made the deeper version of the point in 1986. The hardest single part of building a software system is deciding precisely what to build [7]. We built an entire profession, requirements engineering, around the problem, and it produced documents, which is to say artifacts that humans had to interpret, which is to say the ambiguity survived with better formatting.
What kept the whole arrangement survivable was slowness. When humans did all the building, a team could only build the wrong thing so fast. Interpretation errors surfaced in weeks, got argued about in reviews, and were corrected before too much damage compounded. The coordination ceremonies I wrote about in Scaling Frameworks and the Reality of AI were, among other things, an ambiguity-absorption system. Expensive, slow, and load-bearing.
AI removes the slowness and keeps the ambiguity. A fleet of agents pointed at "improve the customer experience" will produce an enormous volume of confident, plausible, wrong work before lunch. The cost of an unclear ask used to be a bad meeting. Now it is a bad system, delivered quickly. Ambiguity used to be absorbed. Now it compiles. Taiichi Ohno called overproduction the worst of all wastes because it manufactures inventory nobody asked for while hiding every other problem [17]. Abundance without judgment is not acceleration. It is overproduction with better tooling.
So the layer that concentrates above machine production is exactly the one Standish and Brooks pointed at, with a new requirement attached. It is no longer enough to decide precisely what to build and write it in a document for humans. What the organization means now has to be structured well enough for machines to run against and for humans to judge against. That is a different standard, and meeting it at the scale of an enterprise, across hundreds of concurrent intentions, thousands of constraints, and every level from board strategy to a Tuesday build, is a discipline.
The first namings I watched from the audience. This one I am doing myself. I am naming the discipline Intent Architecture. The people who practice it are Intent Architects.
The ancestry of Intent Architecture
New fields never come from nowhere, and this one has a richer ancestry than most. Naming the ancestors is the fastest way to understand what the field is, because each one solved a piece of the problem in a narrower domain.
Enterprise architecture is the closest chair. Since Zachman's 1987 framework [8], organizations have accepted that systems need someone who owns the topology: what connects to what, which standards everything meets, what the whole must satisfy that no single part can see. Nobody expects the enterprise architect to write the code. Intent Architecture makes the identical move one layer up, for what the organization means rather than what it runs. Topology, standards, and coherence, for intent.
Design by Contract supplied the checkability standard. Bertrand Meyer's insight [9] was that a software interface should state its obligations precisely enough that violations are detectable, not describe them in prose and hope. Intent Architecture applies the same discipline to business intent. An acceptance criterion either can have a check written against it or it is not done being written. In the field's working vocabulary, an adverb in an acceptance criterion is a defect. "Gracefully" is a wish. "Returns the named gap the same day" is a contract.
The formal specification tradition supplied the deeper lesson that writing specs is thinking, not paperwork. Leslie Lamport's "Who Builds a House Without Drawing Blueprints?" [10] argued that the act of specifying above the code is where errors get found cheaply. That was a hard sell when specs were for other humans. It stops being a hard sell when the spec is executable intent that a fleet will amplify. The blueprint is no longer optional documentation. It is the input.
Domain-Driven Design supplied the language discipline. Eric Evans showed [11] that the hard, valuable move in complex software is making business meaning precise, a ubiquitous language, with explicit boundaries where meanings change. Intent Architecture inherits this directly. An organization's intent topology is, among other things, a map of bounded contexts: where "customer" means the same thing, where it silently does not, and which constraints hold everywhere versus in one domain only.
Declarative infrastructure proved organizations will trust machines to reconcile declared intent, in narrow domains. SQL declared what you wanted and let the optimizer decide how. Kubernetes runs on desired state, with controllers forever reconciling what is toward what was declared. Every one of these was a rehearsal for pointing the same pattern at business intent itself.
Intent-based networking brought the word into enterprise vocabulary, and it is worth knowing even if you never ran a network. For decades networks were configured box by box, an engineer at each switch, hoping the sum matched the design. In 2017 Gartner named the alternative [12] and Cisco built its flagship launch around it [13]. The operator declares what the network must guarantee, which users may reach which systems, what gets priority. The controller computes the configurations, pushes them, and then continuously checks the running network against the declared intent, flagging drift. Declare, translate, enforce, verify, remediate. That is the harness loop at infrastructure scale, in production for nearly a decade, and it proved something this field depends on: organizations will hand machines the reconciliation of declared intent in a domain where a mistake takes the whole company offline.
Context engineering is the youngest ancestor and the near-term on-ramp. When Tobi Lütke defined it in mid-2025 as the art of providing all the context for the task to be plausibly solvable, and Andrej Karpathy endorsed the term over "prompt engineering" [14], they named the session-scale version of the problem. What does this model need to know, right now, for this task? Intent Architecture is what that discipline becomes at organizational scale, when the context that must be supplied is not one task's briefing but the whole structure of what the enterprise means, with authority, constraints, and evidence attached, maintained over years rather than assembled per prompt.
And beneath all of it sits the oldest root. Winograd and Flores argued in 1986 [15] that organizations essentially are networks of commitments made in language, requests, promises, declarations, and that computer systems should be understood as tools for conducting those conversations. Forty years later that framing stops being philosophy. When machines participate in the network of commitments, the commitments have to be architected.
What the field thinks about
A field is defined by its concerns. Intent Architecture has seven.
Topology. Intent in a large organization has a shape whether anyone tends it or not. Strategic outcomes decompose into portfolio outcomes, outcomes into units of work, work into daily contracts, and every piece inherits constraints and authority from above. Untended, the shape does what untended structure always does: outcomes overlap, two portfolios pursue contradictory conditions without knowing it, constraints get restated differently at each level until the daily work enforces something the officers never said. The first concern of the field is that the trace from any day's work back to strategy actually walks, Conway's law [16] stands as the warning. Left alone, your intent topology will mirror your org chart rather than your strategy.
Checkability. The standard that separates intent from wishes. Every criterion pushed until a check can run against it, re-proven on every change, forever. This is Meyer's contract discipline applied to business meaning, and it is the field's sharpest departure from requirements engineering. The output is not a document that describes. It is a contract that executes.
The field has a name for the path intent travels from the enterprise to the fleet. The authorship cascade. Enterprises have always had a cascade, strategy falling through layers of translation until it reached a builder, and every layer was a handoff that lost meaning. The authorship cascade keeps the shape and changes the mechanism. Intent is not passed down. It is re-authored at each altitude by the person who owns that altitude, with agents doing the drafting and the architect's standards holding the line. An outcome statement becomes an outcome brief. The brief becomes Effort specs. A spec becomes the technical specs that drive the fleet. Decomposition by authors, never translation by intermediaries.
In practice it runs like this. The Decision Owner works with spec agents until the outcome statement becomes a brief in hand. The owner decomposes the brief into Effort specs, each one day's testable contract. The Fleet Lead may decompose an owner's spec further, into the technical specs that drive the fleet, criteria intact. And around the whole cascade sits the architect's actual work: the process design, the standards each artifact is held to, the monitoring that runs through the system, and the learnings that come back to make the next pass better. The architect authors none of it and is accountable for how well all of it gets authored.
The second half of the picture is where the machines take over and the loop closes.
The spec briefs two machines differently. Its criteria go to the harness, where they become checks that run on every push, forever. The whole spec goes to the fleet as the work order, and the context pack rides with it, the curated briefing on the situation being built into. The fleet's output flows into the harness, the harness produces evidence, and a human accepts it, daily. Then the learnings return through the system, context packs refreshed, standards revised, the next spec smarter. A requirements document produced words for humans to interpret. This produces artifacts machines run and build from, closed by a human judgment and improved by its own record. That is the whole difference.
Context economics. What must a machine know to do this work correctly, and what is noise? The field's finding, inherited from context engineering and confirmed everywhere fleets run, is that failures are overwhelmingly context failures, something known but unstated, rather than capability failures. Curation beats volume. Dumping documents into a briefing and calling it context is the amateur tell. And the concern runs at two altitudes at once. An organization's context has a global layer, what every fleet and every person must know, and a local layer, what this domain and this Effort need today. The architect tends both, and the economics are now literal. Context is metered in tokens, and an organization that briefs its fleets wastefully pays for the same knowledge again every morning. Curation serves correctness and conserves the budget in the same motion.
The model landscape. Which model is best for which task is real, consequential knowledge, and it changes monthly. Reasoning depth, context window, cost, latency, and characteristic failure modes differ by model and shift with every release, and pointing the wrong model at a task wastes either money or trust. Someone has to tame that volatility, keep the organization's choices current, and know when the answer changed. A model whisperer, if you like. The councils still decide which models are approved for which categories of work, and the leads still choose per task. The architect is the reason those decisions are informed rather than folklore.
Authority boundaries. Intent includes who may decide. A declared outcome without a declared decision boundary is incomplete intent. It will either stall while everything escalates or run ungoverned while nothing does. The field treats the envelope, what may be accepted alone, what escalates, what never proceeds, as part of the intent artifact itself, not as process bolted on afterward.
Evidence semantics. When machines produce and checks pass, what has actually been proven? The field's discipline here is refusing to let green and right collapse into one word. A passing check proves the contract was met. Whether the contract captured the intent is a human judgment, and keeping that judgment sharp, attributable, and fed with readable evidence is an architectural concern, not an afterthought. The science underneath is also young. What a harness can prove expands with every generation of tooling, and behaviors that were matters of opinion last year are checkable this year. Part of the concern is watching that frontier and growing the organization's proof discipline to meet it, because verification is not a solved problem being applied. It is a maturing science being practiced.
The conversation record. The exchanges between people and the system are a new class of data, and almost nobody treats them as one. Those conversations are intent in its rawest form. They hold the moment a wish got clarified, the question the fleet asked that revealed missing context, the reasoning behind a judgment call that no ledger entry fully captures. Over time that record becomes the organization's memory of how it decides. It is the source material for better context packs, the audit trail behind the audit trail, and the training ground for the next generation of authors. Today it evaporates in chat scrollback. The architect is the one who notices it is an asset.
Take those five together and a familiar silhouette appears. The five are the concerns of a control plane, held by humans. Some organizations will run software that maintains the graph, carries the context, and keeps the evidence connected. Many will not, at first. The field exists either way, the same way enterprise architecture existed before and after the tools arrived. The tooling industrializes the bookkeeping. It does not decide what good looks like.
The practitioners
Fields get named before they get staffed, and then the first practitioners turn out to have been practicing all along under other titles. The guilds are recognizable. Enterprise, solution, and system architects make the closest jump. The instinct for decomposition and standards is already there, and what must grow is business depth. Program leaders and RTEs carry years of cross-team peripheral vision that becomes topology sense, once the value stops being facilitation and becomes structure. Senior business analysts and product owners carry the authorship craft, the shortest path from writing requirements to writing contracts. And the coaches carry the teaching instinct, because half the discipline is raising the organization's authorship, not doing its authoring.
What every origin has to build is evidence literacy, because nobody arrives fluent in asking whether the checks were the right checks. And what the role looks like in operating terms, its artifacts, its boundaries, its anti-patterns, its first ninety days, is specified in the operating model, where a role definition belongs.
The arc from here
DevOps in 2010 was a conference talk and an argument. By 2015 it was a department. Data engineering in 2015 was a job posting anomaly. Within five years it was one of the fastest-growing titles in software. Fields that form around a genuine constraint move fast, because the constraint does the recruiting.
Intent Architecture sits on the oldest constraint the industry has. The one Standish measured in 1994, that Brooks called essential in 1986, that requirements engineering institutionalized, that agile softened with proximity and iteration, and that AI has now stripped of every protective layer of slowness. Deciding precisely what should be true, structuring it so machines can run against it and humans can judge it, was always the hardest part. It is now also the part that is left.
And here is the heart of it. Every organization is about to run on the same models, rented from the same vendors, with the capability curve rising for everyone on the same schedule. For the first time in the history of the industry, execution is not a differentiator. It is a utility.
What cannot be rented is what your organization means. The clarity of its outcomes. The precision of its constraints. The fidelity of the trace from a boardroom sentence to a Tuesday build. The judgment that stands behind every acceptance. That layer is yours alone, and its quality now sets the ceiling on everything the machines can do for you. Point a fleet at architected intent and it compounds. Point the same fleet at ambiguity and it manufactures confusion at industrial scale. Same models, opposite outcomes, and the whole difference is the intent.
That is what the field is for. Not better requirements. Not tidier process. It exists so that what an organization means is engineered as seriously as what it builds, because meaning is the only asset the machines cannot supply.
When intent is architected, alignment stops being an event. No big room, no quarterly ceremony, no string on a board. Just a structure of meaning, tended by people whose job it is, clear enough that the machines can build against it and the humans can stand behind it.
That is the field. The organizations that staff it first will look, from the outside, like they simply stopped having alignment problems.
References
- Beck, K., et al. (2001). Manifesto for Agile Software Development. agilemanifesto.org.
- Allspaw, J., & Hammond, P. (2009). 10+ Deploys per Day: Dev and Ops Cooperation at Flickr. Velocity Conference. Video.
- Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly.
- Goldratt, E. M., & Cox, J. (1984). The Goal: A Process of Ongoing Improvement. North River Press.
- Alphabet earnings calls and Google announcements, October 2024 through April 2026. AI-generated share of new code reported at 25%, then above 30%, then 50%, then 75%.
- The Standish Group (1994). The CHAOS Report. Incomplete requirements cited as the leading factor in impaired projects.
- Brooks, F. P. (1986). No Silver Bullet: Essence and Accidents of Software Engineering. Proceedings of the IFIP Tenth World Computing Conference.
- Zachman, J. A. (1987). A Framework for Information Systems Architecture. IBM Systems Journal, 26(3).
- Meyer, B. (1992). Applying "Design by Contract". IEEE Computer, 25(10).
- Lamport, L. (2015). Who Builds a House Without Drawing Blueprints? Communications of the ACM, 58(4).
- Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
- Skorupa, J., Lerner, A., & Ganguli, S. (2017). Innovation Insight: Intent-Based Networking Systems. Gartner, February 2017.
- Cisco (2017). Intent-Based Networking: The Network. Intuitive. Launched June 2017.
- Lütke, T. (June 2025), with endorsement by Karpathy, A. On "context engineering" over "prompt engineering." X (formerly Twitter).
- Winograd, T., & Flores, F. (1986). Understanding Computers and Cognition: A New Foundation for Design. Ablex.
- Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(4).
- Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
Alex Petty is the founder of Singularics. He has spent 20 years leading enterprise transformations and now helps organizations redesign how work is defined and coordinated when AI changes the operating model.
Ready to see the discipline in practice? The Intent Architect role, its artifacts, boundaries, and first ninety days, is specified in The AI-Native Operating Model™. Take the free Readiness Assessment to see where you stand, or book a call to talk about what the shift looks like for your organization.