Communication Dominates Compute
At every level of computing, moving data costs more than processing it. The same principle applies to governing intelligent systems.
Reiner Pope, in a recent conversation with Dwarkesh Patel, traces how chips work from fundamental logic gates upward. The primitives are simple: AND, OR, NOT. They combine into multiply-accumulate units, then systolic arrays, then complete processors.
The insight that emerges at every level is the same: communication dominates compute.
When a processor reads from a register file, the multiplexer circuit that selects which register to read costs six times more gates than the arithmetic unit that processes the data. The actual computation, the thing the chip exists to do, is a fraction of the work. The rest is moving data to where it can be processed.
This ratio holds at every scale. Inside a chip: data movement dominates logic. Between chips: interconnect bandwidth dominates processing throughput. Across a datacenter: network costs dominate compute costs. The pattern is fractal. The overhead of getting data to the right place, in the right format, at the right time, dwarfs the cost of processing it once it arrives.
The same ratio appears in software
Ask any developer building AI systems what they spend their time on. The answer is consistent: 5% intelligence, 95% plumbing.
The “plumbing” is the software equivalent of data movement: authentication, error handling, logging, monitoring, audit trails, permission checks, retry logic, state management, deployment pipelines. The intelligent part, the reasoning, the decision-making, the part that justifies the system’s existence, is a small fraction of the total effort.
This is not because developers are inefficient. It is because the architecture forces it. When programs execute effects directly, every effect needs its own governance wrapper. Send an email? Check permissions, log the action, record the audit trail, handle errors, retry on failure. Query a database? Same overhead. Call an external API? Same overhead again. Each effect carries its own communication cost: the overhead of making the effect governed, observable, and accountable.
The governance overhead dominates the intelligence, the same way data movement dominates computation in hardware.
How hardware solved it
Chip designers did not solve the communication problem by making data movement faster. They solved it by making data movement structural.
A systolic array is a grid of processing elements where data flows through in a fixed pattern. Each element performs a small computation and passes the result to its neighbor. The data movement is not an overhead layered on top of computation. It is built into the architecture. The pattern of data flow IS the computation. Communication cost per operation drops to nearly zero because the architecture eliminates the need for arbitrary data movement.
The key insight: you do not reduce communication overhead by optimizing communication. You reduce it by choosing an architecture where communication is structural rather than arbitrary.
Intent-driven computing is the software systolic array
Intent-driven computing applies the same principle to governance.
In traditional systems, governance is arbitrary: each effect needs its own governance wrapper, applied by the developer, configured per use case, monitored by a separate system. The governance overhead per effect is high because governance is layered on top of an architecture that was not designed for it.
In intent-driven computing, governance is structural. Programs produce intents. Every intent flows through a single governed boundary. The governance, the authorization check, the policy evaluation, the decision recording, the provenance chain, is built into the architecture. It happens to every intent, automatically, as a property of the execution model.
The governance cost per intent drops to nearly zero. Not because governance got faster. Because the architecture eliminated the need for arbitrary governance wiring. The developer writes zero governance code. The platform handles it. The pattern of governance flow IS the execution.
This is the systolic array principle applied to software: do not optimize the overhead. Choose an architecture where the overhead is structural.
The abstraction question
Pope raises a deeper point about abstraction. When a programmer writes a high-level instruction, they are implicitly making decisions about data movement, precision, parallelism, and communication costs. The abstraction hides these decisions. Sometimes that hiding is useful: programmers should not think about multiplexer gate counts. Sometimes it is harmful: programmers unknowingly waste resources because the abstraction obscures the cost.
The same tension exists in AI governance.
Current abstractions hide governance costs. A developer writing requests.post(url) does not see the governance overhead: the monitoring system that may or may not be observing this call, the audit log that may or may not be recording it, the permission check that may or may not be enforced. The abstraction hides the governance, which means the governance is optional, inconsistent, and incomplete.
Intent-driven computing makes governance visible in the abstraction. When a developer writes ask send_email { to: "[email protected]" }, the governance is in the keyword. ask means: propose this action to the governance boundary. The abstraction does not hide the governance. It IS the governance. The developer sees exactly what is happening: a proposal, a mediation, a decision.
The right abstraction is not the one that hides the most. It is the one that makes the important things visible and the unimportant things invisible. Data movement is important at the chip level (Pope’s point). Governance is important at the AI level (our point). Both should be visible in the abstraction, not hidden behind it.
What the hardware people know
The hardware community learned something decades ago that the software community is still learning: the architecture determines the overhead, not the optimization.
You cannot optimize your way out of a bad architecture. You cannot make arbitrary data movement efficient by building faster buses. You cannot make arbitrary governance efficient by building faster monitoring systems. You can only eliminate the overhead by choosing an architecture where the overhead is structural: where the communication pattern, or the governance pattern, is built into the design rather than layered on afterward.
Systolic arrays solved this for matrix multiplication. SQL solved it for data access. Intent-driven computing solves it for AI governance.
In each case, the solution was the same: stop trying to make the overhead faster. Change the architecture so the overhead disappears.