Design Conductor 2.0: AI Agent Builds Hardware Accelerator in 80 Hours

Paper: 2605.05170 Authors: The Verkor Team, Ravi Krishna, Suresh Krishna, David Chin Categories: cs.AR, cs.AI

The Gap

Prior work (Design Conductor 1.0, Dec 2025) showed LLM agents could autonomously design a 5-stage RISC-V CPU in 12 hours. But that system hit a complexity ceiling: it couldn’t handle designs with thousands of compute units, deep pipelines, or implementations derived from research papers rather than specifications. The gap is scale and abstraction — moving from toy demonstrations to production-grade accelerators that require understanding algorithmic papers, making architectural tradeoffs, and managing massive state spaces.

Problem: Agent-designed hardware stuck at toy complexity
   |
   v
Assumption: Frontier models (Apr 2026) + better harness = 80x scale jump
   |
   v
Method: Multi-agent system reads papers -> designs accelerator -> maps to FPGA
   |
   v
Evidence: VerTQ accelerator (5129 FP units, 240-cycle pipeline) from TurboQuant paper
   |
   v
Conclusion: Autonomous hardware design now handles production-scale complexity

The Increment

One sentence: Before this paper, AI agents designed simple CPUs from specs; after, they design production-scale accelerators from research papers.

Core Mechanism

Design Conductor 2.0 is a multi-agent orchestration system. One agent reads the TurboQuant paper and extracts the algorithm’s computational requirements. Another agent translates those requirements into a microarchitecture — deciding pipeline depth, parallelism, memory hierarchy. A third agent generates RTL (register-transfer level) code in Verilog. A verification agent runs simulations and catches bugs. A synthesis agent maps the design to FPGA and reports timing/area. The orchestrator coordinates these agents, passing intermediate artifacts between them and iterating when verification fails.

Paper (TurboQuant) 
   |
   v
[Algorithm Agent] ---> computational graph, data dependencies
   |
   v
[Architecture Agent] ---> pipeline stages, FP unit allocation
   |
   v
[RTL Agent] ---> Verilog modules (5129 FP16/32 units)
   |
   v
[Verification Agent] <---> [RTL Agent] (iterate on bugs)
   |
   v
[Synthesis Agent] ---> FPGA bitstream (125 MHz, 5.7 mm^2 in 16FF)

Think of it like a construction company building a skyscraper. The algorithm agent is the structural engineer reading blueprints and calculating load requirements. The architecture agent is the general contractor deciding how many floors, where to place elevators, how to route utilities. The RTL agent is the crew pouring concrete and welding steel. The verification agent is the inspector catching code violations. The synthesis agent is the city planner checking zoning and issuing permits. The orchestrator is the project manager keeping everyone synchronized and handling change orders when inspections fail.

Key Concepts

• RTL (Register-Transfer Level): Hardware description at the level of registers (storage) and combinational logic (operations between registers). It’s one abstraction above transistors, one below algorithmic pseudocode. Think of it as the “assembly language” of hardware — you specify what happens every clock cycle. Example: always @(posedge clk) sum <= a + b; means “on every rising clock edge, store the sum of a and b into register sum.”

• Pipeline depth: Breaking a computation into sequential stages so multiple operations overlap in time. A 240-cycle pipeline means an operation takes 240 clock cycles to complete, but a new operation can start every cycle. Like an assembly line: each car takes hours to build, but one rolls off every minute. Deeper pipelines increase throughput but add latency and complexity (more state to manage, harder to verify).

• Multi-agent harness: The scaffolding that lets multiple LLM instances collaborate. Each agent has a specialized prompt and tool access. The harness manages message passing, artifact storage, and retry logic. It’s not just “run multiple agents” — it’s the protocol that lets them build on each other’s work without stepping on toes. The harness decides when to fork agents in parallel vs. chain them sequentially.

Framework Shift

Before (Design Conductor 1.0):        After (Design Conductor 2.0):

Spec doc                              Research paper (TurboQuant)
   |                                     |
   v                                     v
Single agent                          Algorithm extraction agent
   |                                     |
   v                                     v
Simple CPU                            Architecture planning agent
(5 stages)                               |
   |                                     v
   v                                  RTL generation agent
Verification                             |
   |                                     v
   v                                  Verification agent (iterate)
Done (12 hours)                          |
                                         v
                                      Synthesis agent
                                         |
                                         v
                                      Production accelerator
                                      (5129 FP units, 240 stages)
                                         |
                                         v
                                      Done (80 hours)

From monolithic agent to specialized pipeline, the core shift is decomposition by expertise — each agent masters one phase rather than one agent fumbling through all phases.

Expert Assessment

Problem choice: Real gap. The Dec 2025 result was impressive but obviously hit a wall — you can’t scale a single-agent approach to designs with 5000+ compute units. This paper tackles the natural next question: can agents handle production complexity? The timing is opportunistic (riding April 2026 model releases) but the problem is genuine.

Method maturity: Mostly engineering, not algorithmic novelty. The multi-agent harness is solid systems work, but the core insight — “decompose by design phase” — is obvious in hindsight. The paper doesn’t explore alternative decompositions (e.g., by hardware module rather than design phase). The reliance on frontier models means results will age quickly as models improve. No ablation on which agents contribute most to success.

Experimental integrity: The VerTQ accelerator is real (FPGA-verified, area numbers from synthesis tools), but the paper only shows one full design. The other three designs mentioned in the abstract are barely described. No comparison to human-designed accelerators on the same algorithm. No analysis of design quality beyond “it works” — is the microarchitecture efficient? Are there obvious optimizations the agent missed? The 80-hour runtime is impressive but not contextualized (how long would a human team take?).

Writing quality: The paper front-loads results but buries the harness architecture in later sections. The reader wants to know *how the agents coordinate before seeing what they built. Section 4 (key new characteristics) reads like a feature list rather than principled design choices. The limitations section is refreshingly honest but too brief — this is where the paper should dig into failure modes and boundary conditions.

Verdict: weak accept — Solid engineering demonstration with real artifacts, but lacks depth in analysis and alternative exploration. Feels like a progress report rather than a research contribution.

Takeaways

Decompose by phase, not by module: When building complex systems with LLMs, split by workflow stage (design → implement → verify) rather than by component (memory controller, ALU, etc.). Each agent becomes an expert in one transformation rather than a generalist struggling with everything.

Verification as a first-class agent: Don’t bolt verification onto the end. Make it a peer agent that can reject work and force iteration. The paper’s verification agent caught bugs that would have been invisible until FPGA synthesis — by then, debugging is 10x harder.

Frontier models unlock scale, not capability: The 80x jump came from better models, not better algorithms. If you’re building agent systems today, assume your architecture will need to scale with model improvements. Design for composability and parallelism, not for squeezing performance from current models.

Concrete steal: The paper’s approach to reading research papers (extract computational graph, identify data dependencies, map to hardware primitives) transfers directly to other domains. If you’re building agents that implement algorithms from papers, this three-step decomposition is a template.