Two organizations can have access to essentially the same cloud platforms, AI models, engineering talent and budget — and still produce radically different outcomes.
One moves quickly. It experiments, learns, reuses what works, and steadily increases its ability to deliver value. The other adds AI tools, launches pilots and increases engineering capacity, yet decisions remain slow, platforms become more complex, and teams struggle to turn new capability into measurable business outcomes.
The difference is not the technology. It is the system the technology operates in. And as AI makes implementation dramatically cheaper, that difference stops being a nuance and starts being the whole game.
The question is no longer simply:
If we can build almost anything, what should we build?
The deeper question is:
When implementation stops being the primary constraint, what becomes scarce?
I believe the answer is intent.
Most of the individual pieces of this argument are not new. What I think is underexplored is what happens when you put them together — and what that implies for the people who build internal platforms.
Fig. 1 — Identical inputs, opposite trajectories. The difference is the system around them.
The bottleneck moves upstream
For decades we have invested in the ability to implement: better languages and IDEs, cloud, CI/CD, infrastructure as code, internal developer platforms, AI coding assistants, and now autonomous agents. Each generation removed friction from implementation. Each was worth doing.
But removing a constraint does not eliminate the need for a constraint. It moves it.
When implementation becomes abundant, organizations increasingly struggle with a different class of question:
What outcome are we actually trying to achieve?
Which problem is worth solving?
What context does the person or agent making the decision need?
Which constraints matter?
Who has the authority to act?
What can an agent change autonomously?
How do we know whether the result created value?
What should we learn and reuse?
The bottleneck has moved from “Can we build it?” toward “Do we know what should happen next?” That is a very different problem, and it does not respond to more compute.
Fig. 2 — Cheaper implementation did not remove the constraint. It moved it from build to intent.
Intent is more than a requirement
When I use the word intent, I do not mean a vague business requirement or a ticket in a backlog.
Intent is the combination of:
what outcome should be achieved, in which context, under which constraints, with which authority to act — and how we will know whether the outcome was actually achieved.
A traditional requirement might say:
“Build an API that allows customers to change their address.”
Intent asks a much richer question:
“Enable customers to maintain their address without contacting support, subject to these regulatory, security and data-quality constraints, while preserving the integrity of downstream processes.”
The first describes something to build. The second describes an outcome, a context, a boundary and a reason for action.
AI agents are exceptionally good at implementation. They are much less useful when the intent they receive is ambiguous, the context is incomplete, the constraints are unstated or the feedback loop is weak. This is why more execution capacity does not automatically translate into more business value.
One clarification, because this argument is easy to misread. Clear intent is not the same as complete upfront specification. Most product intent is discovered by building, and cheap implementation makes discovery cheaper, not less necessary. The correct response to abundant code is often more experiments, not longer documents.
What has to be clear is narrower than a specification: the outcome being pursued, the constraints that must hold, and how we will know. The solution is allowed to be unknown. “We don’t know yet, and here is the experiment that will tell us” is a perfectly well-formed intent. “Build the thing we discussed” is not.
Fig. 3 — The same request twice. The requirement names a solution; intent fills the five slots around it.
The multiplier matters more than the inputs
A useful way to think about this is:
Outcome = Inputs × Multiplier
Organizations have become very good at increasing inputs: more engineers, more cloud, more data, more models, more tools, more automation. But the multiplier determines whether those inputs compound or merely accumulate.
I use the following model to describe it:
Outcome = Inputs × (A × C × E)
Where:
A = Adaptive Organization
C = Compounding Foundation
E = Evolving Flywheel
None of these are precise metrics. But each has a usable proxy:
A — Decision latency. How many working days pass between a signal arriving and an authorized actor being able to act on it?
C — Second-team cost. When a second team needs the same capability, what fraction of the first team’s work do they get for free?
E — Learning half-life. How long before an operational insight exists as something reusable — a pattern, a policy, a platform capability — rather than as tribal knowledge?
Measure those three and you usually find the real constraint within an afternoon.
The relationship matters more than the precision. If one multiplier approaches zero, adding inputs does not solve the underlying problem. That is why two organizations can make near-identical technology investments and experience completely different outcomes.
Fig. 4 — Multiplied, not added. One multiplier at zero collapses the whole chain.
A — Adaptive Organization
The first multiplier is the organization’s ability to sense, decide and act.
An adaptive organization does not make every decision quickly. It makes the right decisions at the right level, with enough context and authority to act.
Consider a team that discovers a customer problem on Monday but needs three approvals, a platform review, an architecture board decision and a funding discussion before it can respond. The engineers may be excellent, the platform modern, the AI agents powerful. The system still has a long distance between signal and action — and AI shortens the implementation step without changing that distance at all.
So the questions worth asking are structural:
How many layers sit between a signal and an empowered decision?
How expensive is it to change direction?
Which decisions can be delegated?
Does the person or agent making a decision have the context required to make it well?
Can teams act within clearly defined boundaries without waiting for central approval?
AI raises the value of organizational adaptability precisely because it raises the speed at which action is possible. Decision latency becomes both more visible and more expensive.
C — Compounding Foundation
The second multiplier is the technology foundation — and this is where Platform Engineering becomes critical.
A platform is not valuable because it provides more capabilities. It is valuable when those capabilities can be reused safely and repeatedly, so the organization stops solving the same problem twice. Good architecture compounds. Poor architecture compounds too — in the wrong direction.
This leads to a principle I keep returning to:
Architecture sets the sign of the multiplier. Tools mostly set the size.
The sign is deliberate. A bad foundation does not merely add less value than a great one — it actively subtracts, because every new capability makes the next change harder. Tools can make a positive multiplier larger. They cannot flip a negative one.
You can install a world-class data platform inside an organization that takes four months to approve a decision. The platform will be technically excellent and strategically irrelevant.
This is also why Platform Engineering should not be reduced to Developer Experience. Developer Experience matters enormously. But the deeper question is whether the platform makes the system of value creation more effective — and those are not the same question.
E — Evolving Flywheel
The third multiplier is the organization’s ability to learn.
Every technology organization runs some version of a loop:
Sense → Decide → Build → Run → Learn
The problem is that most organizations treat each iteration as independent. A team solves a problem, the solution disappears into production, and another team meets the same problem six months later. The organization learned something. It just never turned the learning into an asset.
A compounding organization converts learning into things that can be picked up again: architecture patterns, platform capabilities, automation, data, policies, operational knowledge, product knowledge, decision context. Each cycle makes the next cycle cheaper.
This becomes particularly powerful with AI, because agents can run more cycles, analyze more data, generate more options and operate continuously. But unless the organization captures what those cycles teach it, additional execution capacity produces motion rather than momentum.
Why intent stays scarce
If intent were merely an information-quality problem, it would already be solved. Write better tickets. Add acceptance criteria. Done.
It is not solved, and the reason is uncomfortable: in most large organizations, intent is ambiguous on purpose.
Vague intent is what unresolved stakeholder conflict looks like once it has been written down. Two executives want different things. The wording that survives the meeting is the wording both can live with — which means the wording that decides nothing. The ambiguity is not a drafting accident. It is the compromise.
Teams have historically absorbed that ambiguity. Someone senior interpreted it, made a call, and the organization never had to admit a decision was missing.
Agents do not absorb ambiguity. They act on it — quickly, at scale, and in whichever direction the prompt happened to lean.
This is why making intent explicit is a political act before it is a technical one. It forces deferred conflicts into the open. That is the real cost, and it is also the real value.
The agentic twist: agents amplify the system
AI agents do not fix a weak organization. They amplify the system they are placed into.
This is not a new observation. Google Cloud’s DORA research program reached the same conclusion in its 2025 State of AI-assisted Software Development report, based on nearly 5,000 technology professionals: “AI’s primary role in software development is that of an amplifier.” It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. And the report locates the returns not in the tools but in the organizational system underneath them — starting with the quality of the internal platform.
What I want to add is the structural consequence.
If your architecture is modular, agents exploit that modularity. If your platform offers reusable capabilities, agents consume them. If your feedback loops are tight, agents learn faster.
But if your architecture is tightly coupled, agents make more changes across a tightly coupled system. If your policies are unclear, agents act with unclear boundaries. If your decision processes are slow, agents produce enormous amounts of work that waits. And if your feedback loops are weak, agents accelerate the production of things nobody can tell whether they should have built.
The equation does not disappear. Agents multiply it. That makes platform and organizational architecture more important, not less.
Fig. 5 — The same agent in two systems. One compounds; the other queues more work in front of the same decision gate.
From Developer Experience to Intent
This creates a significant shift for Platform Engineering.
The traditional platform consumer is a developer. The platform helps them provision infrastructure, deploy software, access services, observe systems, manage environments and automate repetitive work.
Increasingly, a second consumer is arriving: the AI agent.
An agent does not need a nicer developer portal. It needs a machine-accessible environment in which it can safely act — and that environment has three parts.
Know — what the actor can find out:
Context — what does the agent need to know?
Capabilities — what can it do?
Do — what the actor may change:
Constraints — what must it not do?
Permissions — what is it authorized to change?
Policies — which organizational rules apply?
Learn — how the system finds out what happened:
Observability — what did it do, and why?
Feedback — did the action achieve the intended outcome?
Human escalation — when must a person decide?
So the platform question is no longer only:
How do we make it easier for developers to build?
It becomes:
How do we create an environment in which humans and agents can safely turn intent into governed action?
That is a considerably bigger platform problem.
Fig. 6 — Two consumers, one platform: what an actor can know, what it may do, and how the system learns.
Intent becomes the scarce resource
The emerging value chain looks roughly like this:
Signal → Intent → Context → Decision → Action → Outcome → Learning
AI dramatically increases capacity on the Action side. Agents write code, create infrastructure, analyze information, execute workflows, test systems and operate services.
Which makes everything upstream more consequential. If the signal is misread, the agent solves the wrong problem. If the intent is ambiguous, it builds the wrong solution. If the context is incomplete, it decides badly. If constraints are missing, it acts unsafely. If the outcome is not observable, nobody learns anything.
The more powerful the execution engine, the more valuable the quality of the instructions and the environment around it.
This is the paradox of abundant implementation:
The cheaper it becomes to build, the more expensive it becomes to be unclear about what should be built.
Fig. 7 — AI inflates the action stage. Everything upstream decides whether that capacity creates value.
The other side of the loop: verification
There is a fair objection to all of this.
If agents can produce unlimited output, the binding constraint is not intent — it is verification. Review capacity. Test coverage. The ability to trust what came back.
I think that objection is correct, and I think it is the same problem.
Intent and verification are two ends of one loop. Verification is only possible against a stated outcome: you cannot review code against a vague requirement, you can only review it against your private assumption of what it was supposed to do. Weak intent does not just produce the wrong software. It makes the wrong software undetectable.
The pair is inseparable. Intent defines what “correct” means; verification is how the organization finds out. An organization that scales execution without scaling either one is not moving faster. It is accumulating unreviewed work.
What this means for Platform Engineering
Platform Engineering has traditionally focused on reducing friction for software teams. The next evolution is broader: platforms become the place where organizational intent is translated into executable capability.
Kaspar von Grünberg and Luca Galante make the platform side of this case at full scale in Thinking in Platforms: platform engineering as the operating model for recurring knowledge work, with paths, capabilities, policy and state that let humans and agents operate reliably. I find that argument convincing.
Their book describes the production system. This post asks what sits in front of it. Where does the intent come from that the production system executes? How do scattered signals become a decision, and how does that decision become an artifact something can act on? Paths make answered questions cheap to reuse. Intent Architecture is about how the questions get answered in the first place — and who is authorized to answer them.
That does not mean turning the platform into a giant orchestration system. It means providing primitives that let autonomous actors operate inside a clearly defined system:
reusable capabilities instead of one-off implementations
machine-readable interfaces instead of undocumented dependencies
policy and governance as executable constraints
identity and authorization that work for humans and agents alike
context that can be discovered and trusted
observability that connects actions to outcomes
feedback loops that turn operational experience into reusable knowledge
This is where Platform Engineering intersects with architecture, organizational design, product operating models and AI. The platform becomes part of the organization’s decision-to-action system.
A practical diagnostic
Before adding another AI tool or platform capability, run three checks.
1. Where is the constraint?
Run the three proxies against your own organization:
Healthy Worth investigating Your constraint Decision latency days weeks months Second-team cost mostly free partial reuse rebuilt from scratch Learning half-life days to a pattern a quarter never leaves the team
Whichever row is worst is where your next investment belongs — regardless of where the budget currently sits.
2. Are we creating reusable capabilities?
After an AI initiative succeeds, what does the second team get for free? If the answer is “nothing”, you are increasing execution capacity without creating compounding value.
3. Can humans and agents safely act on intent?
Can an authorized actor discover what it needs to know, what it is allowed to do, what it must not do, which capabilities it can use, how success is measured, and when it needs a human? If not, increasing autonomy mostly increases risk and rework.
The next architectural problem
Software architecture originally focused on implementation. Distributed systems forced us to think about communication, consistency and resilience. Cloud changed how infrastructure was consumed. Platform Engineering changed how teams consumed capability. Agentic AI is now changing the economics of execution itself.
That creates a new architectural question:
How do we design enterprises in which intent can reliably become governed action — through humans, agents and platforms?
The answer is not another tool. It requires architecture, organizational design, platforms, governance — and far greater clarity about intent than most organizations currently tolerate.
This is the direction I have started calling Intent Architecture: the emerging discipline of designing the enterprise so that intent can reliably become governed action through humans, agents and platforms.
This is adjacent to, but not the same as, the spec-driven development work happening in the tooling space. Spec-driven development operates at the artifact level: a specification per feature, precise enough for an agent to implement against. That is genuinely useful and largely solved in principle.
Intent Architecture asks the level above it. A perfect spec is worthless if nobody was authorized to commission it, if the constraints it inherits are undocumented, or if nothing downstream reveals whether the outcome was achieved. Specs govern a unit of work. Architecture governs who may commission work, under which constraints, and how the result feeds back. You need both — one without the other produces either well-specified irrelevance or well-governed vagueness.
The name matters less than the problem. The strategic question is what matters:
When implementation becomes abundant, which organizations will be able to turn intent into action, action into learning, and learning into better intent — faster than everyone else?
That may become one of the defining technology leadership questions of the agentic era.
Code was never the goal. Value comes from decisions.
Your point that intent is ambiguous on purpose rings true in government. Policy intent often arrives as the wording everyone could agree to, and delivery teams have always quietly made the missing decisions. In public services, user research, content design and interaction design are where much of that intent gets made clear. If agents act on ambiguity instead of absorbing it, those disciplines matter more, but they need to work closer to the build.
Your intent-and-verification loop matched my own experience too. With a coding agent, shared documentation of decisions mattered more than the speed of the code.