Architecture 2.0
Designing AI-Assisted Loops for Computing Systems
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.
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, rejected candidates, failed runs, and the provenance that ties feedback to a decision. Data-driven methods become credible only when the data records the design loop, not just its successful endpoints.
What follows is an operating framework, not a catalog. The field is moving quickly, and a catalog of today’s agents, tools, and benchmarks would age before it was useful. The durable contribution is a way to describe an architecture design loop, judge its evidence, and decide what the architect still owns. Architecture 2.0 is therefore not primarily a survey of current AI agents for computer architecture. Agents are the forcing function. The foundation is a set of durable principles for making architecture design loops representable, governable, evidence-bearing, rejectable, and improvable as methods become more capable. The faster-moving record of who is doing what belongs with the community now forming around this topic, tracked in the living resource list of Appendix C — Architecture 2.0 Resource Catalog and Links. The book keeps the parts meant to last.
The recurring artifact is the design-loop card. The card is not a substitute for a paper, benchmark, simulator, or design review. It is the compact record that names the loop behind a claim, specifying the task, representation, environment, method role, feedback budget, evidence, negative traces, rejection authority, and human decision. The book develops those fields chapter by chapter, then collects the card and review rubric in Appendix B — Design-Loop Card and Review Rubric.
The book’s central act is computing-system synthesis: turning architectural intent into defensible computing-system designs for chips, accelerators, memory systems, and the toolchains and workloads around them. Inside the book, system synthesis is shorthand for this architecture-level computing-system synthesis. Logic synthesis turns logic into circuits. High-level synthesis turns behavior into hardware. Program synthesis turns specifications into programs. System synthesis operates at the architecture level, where intent, constraints, representations, tools, feedback, evidence, and human judgment have to be coordinated before a design deserves commitment.
The framework keeps returning to three reader questions. What state is visible to the loop? What actions and tools can change that state? What evidence can reject a result before a person or organization commits to it? Later chapters give those questions reusable names, such as loop contracts, architecture environments, method roles, evidence ledgers, rejection authority, commitment boundaries, and design-loop cards.
Book structure
The book is organized into ten chapters that build the Architecture 2.0 framework:
- Chapter 1 and Chapter 2 establish the paradigm shift. They show why classical design loops no longer scale against engineering costs, and why AI assistance requires treating the loop itself as an explicitly designed object.
- Chapter 3 introduces the core ontology, detailing the shift from artifacts to claims and the compact framework of intent, representations, environments, method roles, and evidence.
- Chapter 4, Chapter 5, and Chapter 6 operationalize the framework. They detail how raw data becomes actionable provenance, how ad-hoc tools become trusted environments, and how AI methods map to specific design roles.
- Chapter 7 and Chapter 8 focus on evaluation. They build a sequenced ledger for trust, from feedback budgets to rejection authority, and demonstrate a bounded, rejectable turn through the loop.
- Chapter 9 scales these concepts across the system stack, showing how the loop contract tightens as feedback cost and irreversibility increase.
- Chapter 10 concludes by identifying the architect’s nondelegable responsibilities and the shared community infrastructure the field needs next.
Who this book is for
This is a compact synthesis for readers who already know computer architecture and want a framework for AI-native architectural practice. It assumes fluency in architecture and does not re-teach it. It does not assume a machine-learning or reinforcement-learning background; the ML and RL ideas it borrows are glossed in margin footnotes at first use, so an architect can follow the argument without prior AI training. It is not a survey of today’s agents and tools, not a tutorial on building them, and not a forecast of future automation. It is an operating discipline for governing the design loops those tools run inside.
Within that scope, the book serves several readers. A graduate student entering the area should find the vocabulary and the lay of the land. A reviewer should find a way to ask what a project exposes and what could reject its result, not only what result it reports. Its author should find a way to state the architectural claim so its evidence, boundaries, and rejection conditions are visible. A practitioner should find a way to reason about where an agent may act and where the architect must still decide. If the book succeeds, each of these readers should be able to do something afterward that was harder before. They will be able to name a loop, judge its evidence, and state what remains an architect-owned commitment.
How to read this book
Each chapter is framed by a guiding question and a short What this chapter gives you list of the moves you will be able to make. One running example, the lighthouse prompt of 1 The Architecture 2.0 Moonshot, a compact design request for a mobile extended-reality (XR) subsystem, travels through the book as a shared example.
For a quick pass, read the Preface and 1 The Architecture 2.0 Moonshot, then skim the design-loop card in Appendix B — Design-Loop Card and Review Rubric. For a one-hour pass, read 2 Why Classical Architecture Loops Strain, 3 Architectural Claims and Design Loops, and 9 Loop Patterns Across the Stack to see why the loop becomes a first-class object of design alongside the artifact. For a first project pass, use Appendix A — Bootstrapping an Architecture 2.0 Loop to bound one loop before building a platform. For research review, read the chapters in order; the loop-role resource catalog and living link list in Appendix C — Architecture 2.0 Resource Catalog and Links show where the framework most needs better examples, tools, and evidence.
AI systems do not remove the architect. They raise what the architect must be good at. The work moves upward, toward intent, representation, evidence standards, rejection authority, and accountability for the final decision. The opportunity is not to wait for a system that designs a computer from a single sentence. It is to make the represented, instrumented, evidence-bearing design loop a first-class part of architectural practice, alongside the artifact it produces, and to build loops worthy of an architect’s judgment.
Vijay Janapa Reddi