Architecture 2.0
v0.1.1
Preface
Computer architecture has a new question. For decades the field asked what machines should be built for new kinds of computation. Capable AI systems now pose the reverse question: what can those systems do for the practice of architecture itself? The reversal changes the scarce engineering act. When plausible artifacts become cheap to generate, the hard problem is no longer only producing a candidate accelerator, kernel, floorplan, or design report. It is deciding which artifact-backed claim deserves belief, comparison, rejection, escalation, or commitment. This book is about that shift from artifact scarcity to commitment scarcity. The destination is to make AI-assisted architecture claims credible, comparable, and reviewable. The mechanism is to treat the design loop as a first-class architectural object alongside the artifact, creating a structure with visible state, allowed actions, evidence, rejection authority, and commitment boundaries. The artifact still matters. The loop matters because it determines how that artifact is produced, evaluated, rejected, and justified.
Architecture 2.0 is not a debate about whether we use AI, nor a catalog of what today’s agents can do. It is the discipline of governing the design loop so that an AI-produced claim carries the evidence, boundaries, and rejection conditions a human needs to commit to it.
The broader shift is already underway. The Architecture 2.0 foundations article argues why AI methods and agents belong in modern computer system design, especially for computer architecture and hardware/software co-design, and sets out the vision, history, ecosystem, capability horizons, and levels of autonomy that could follow (Janapa Reddi and Yazdanbakhsh 2025). This book takes up the next question and treats it on its own terms. Suppose an AI-assisted loop proposes a faster accelerator configuration, a lower-energy kernel, or a plausible physical-design move. What state did it inspect? What could reject the result? Who accepts the commitment if the evidence is wrong? Those are the questions this book treats as the practical core of Architecture 2.0.
Janapa Reddi, Vijay, and Amir Yazdanbakhsh. 2025. “Architecture 2.0: Foundations of Artificial Intelligence Agents for Modern Computer System Design.” Computer 58 (2): 116–24. https://doi.org/10.1109/MC.2024.3521641.
That credibility question is familiar from a different field. Machine learning systems faced the same problem a decade ago. Claims were everywhere and comparison was hard. The answer was not a better model. It was measurement discipline, requiring shared workloads, defined scenarios, provenance, and rules that made a performance claim mean the same thing across systems. Benchmarking efforts mattered because they turned enthusiasm into evidence. Architecture 2.0 needs the same move one level up. The task is to make AI-assisted architecture claims as credible, comparable, and reviewable as the community learned to make AI-systems claims. One caveat travels with the analogy. Benchmarking earned comparability by fixing tasks, workloads, metrics, and submission rules, so two loop claims are directly comparable only when those match too. When they do not, the design-loop card, the compact loop record this book develops, still makes a claim reviewable and contrastable, which is often the achievable goal at the loop level. Two things earned MLPerf’s comparability, and a self-attested card supplies neither: it fixed the output so only the system varied, one level below where the loop now sits, and it added adversarial peer review, a submission round under shared rules in which competitors could reject each other’s claims. In that sense MLPerf is already a worked Architecture 2.0 loop, a versioned workload packet with provenance and an independent rejection authority, and naming that governance is what the loop level still owes.
The central problem sits at the boundary between computer architecture, machine learning systems, benchmarking, and tool-based design. AI methods are powerful, but architecture progress depends on hardware and software interfaces, workload definitions, toolchains, evidence standards, and human judgment. That is why the unit of analysis here is the design loop, not the isolated model.
When the text or a figure draws a single agent, read it as a participant in the loop, not a claim about implementation. That participant might be one model, one tool-using agent, a workflow of models and scripts, or several specialized agents. The same test applies in every case: each participant needs visible state, legal actions, evidence obligations, a rejection path, and an architect-owned commitment boundary.
The argument is therefore data-centric in a specific sense. The limiting question is not only which model or agent is used. It is which parts of architecture work are made observable, including workload traces, design artifacts, tool outputs, constraints,...