Architect's agents sit above the EDA stack, not beside it. We chose this deliberately: Architect coordinates place-and-route, verification, and tape-out without replacing the tools that execute those operations.
In practice, the coordination layer reads what an EDA tool produced, interprets the result, decides what should happen next, and prepares the inputs for another invocation. The agents do not simulate device behavior, calculate physical effects from first principles, or reproduce the tool's internal models. They orchestrate the sequence of work around those capabilities.
"Above" and "around" describe different architectures. Above means reading tool outputs and writing tool inputs. Around means building a replacement for the tool itself. Architect chose the first model.
What a Coordination Layer Does
The agents work with concrete artifacts. They can inspect timing reports, review DRC summaries, prepare constraint changes, and determine whether another iteration is warranted or the flow should stop. Their operating surface is the file interface between tool invocations.
That differs from a conventional automation script. A script may look for a pass or fail string. An agent can interpret report content, retain context across several runs, and route the flow using patterns distributed across timing, placement, and verification outputs.
Why We Did Not Replace the Tools
Consider incremental timing after each ECO buffer insertion. An agent can watch the results, recognize that hold fixes are beginning to damage setup paths, and stop the loop before the cascade expands. An engineer would recognize the same pattern, but often only after manually reviewing several reports.
Agents coordinate. Tools execute.
The other option was to build around the EDA stack by re-implementing place-and-route, LVS, or STA in a new tool layer. That would discard decades of physical and electrical model development. It would also ask the AI system to solve problems the existing tools already solve and validate.
An architecture built around replacement tools would need its own device-physics models, parasitic extraction, timing-arc calculations, and DRC rule encoding. Those are substantial engineering efforts, but they do not address the coordination problem between completed tool runs.
The File Boundary Is the Trust Boundary
The maintenance burden would continue as process technology changed. EDA vendors update models through PDK releases and tool versions. A parallel physics layer would need its own matching updates. By coordinating above the stack, Architect receives those changes through the existing tools instead of maintaining a second physical model.
This choice has a clear tradeoff. Architect cannot alter what occurs inside a tool invocation. It can shape the inputs and interpret the outputs. We accept that boundary because coordination, rather than internal tool behavior, is the problem we set out to address.
What the Agents Actually Do
SPEF, SDC, DEF, timing reports, and DRC summaries are the surfaces where agent judgment meets tool execution. The agent works on one side of each handoff, and the EDA tool works on the other. The agent does not write directly into internal tool state.
That boundary supports auditability. If an agent makes a poor decision, the resulting file shows what it supplied to the next step. The downstream tool then applies its known rules to that file. The artifact preserves the path from judgment to result.
For example, an agent can read a timing report, identify the paths that need attention, write an updated SDC, and pass it into the next invocation. The tool treats that SDC as its input authority. The agent's judgment is expressed through the file, not through hidden changes inside the tool.
What This Means for Physical Design Teams
The agents can select the next tool from the current convergence state, revise constraints when timing closure stalls, adjust floorplan hints between placement passes, and flag report patterns for human escalation.
They do not alter foundry PDK parameters, change internal tool state, bypass DRC checks, or make tape-out decisions without a human review gate.
For teams evaluating an AI flow, the existing EDA chain remains in place. Library preparation, design rules, signoff criteria, and tool setup do not change. The change is the coordination overhead between invocations, where engineers currently decide what to run, inspect, revise, and review.
AI in physical design is not doing the job of EDA tools. It is doing the job that currently falls between EDA tools, the coordination work that engineers perform but no tool owns.