Five teams, three process nodes, and one shared observation defined our first month of early access: the bottleneck was coordination between EDA tools, not the tools themselves. We entered the program expecting to learn about agent performance in active flows. We also learned where the surrounding work was harder to see.
The First Cohort
Across all five teams, the difficult work appeared in the space between invocations. An engineer had to choose the next run, read the result, prepare revised inputs, and decide whether another pass was warranted. Tool capability and execution speed mattered, but neither was the common constraint. Every team found that manual coordination consumed more attention than expected, and none had predicted that at the outset.
Most teams arrived prepared for technical integration. They expected the main effort to be connecting Architect with their existing EDA environments and making sure the required tools could run together. Instead, the harder work was exposing the handoffs they had managed from memory. Their flow contained many unwritten decisions, so making those decisions explicit became the first task.
The Coordination Gap
The cohort included five custom silicon teams working across three process nodes. Team sizes varied, from a two-person group to somewhat larger organizations. All were engaged in active chip design rather than evaluation-only setups, and they represented different points on the path to tape-out. We are not naming them during early access. They shared standard EDA toolchains spanning place-and-route, verification, and timing closure.
The first month followed a defined sequence. We began with an integration check, then asked each team to map its flow and identify decision points before moving into active use of Architect agents on real work. That mapping exercise exposed more variation in coordination habits than we expected. It showed that similar toolchains could still depend on very different assumptions between steps.
For every team, the interval between tool runs was larger than anticipated compared with the execution itself. Someone had to determine the next action, inspect outputs, prepare new inputs, and launch another run after a change. In effect, the teams were serving as the coordination layer connecting their own tools. That is the gap Architect agents are intended to address.
Where Onboarding Slowed
Consider one timing-closure iteration. An engineer runs STA, reviews the report, selects paths for attention, edits the SDC, and decides whether to run STA again or move to routing. Each choice may take only minutes. Repeated across corners, modes, and many iterations, those minutes become a substantial workload. The tool logs record the commands and results, but not the reasoning that links one invocation to the next.
The teams had already identified work they wanted to automate, including routing passes, DRC closure, and parasitic extraction cycles. Coordination did not appear on those lists because it was not visible in any single tool output. Engineers performed it continuously, without naming it as a separate workload. The documentation phase made that hidden layer visible.
We expected integration to be the hard part. Instead, friction came from documenting inter-tool decisions that lived in personal experience and had never been written down.
A Two-Person Team
Writing down the flow was not a blocker, but it took longer than planned. A process that felt obvious often turned out to be a chain of judgment calls. Once teams recorded those calls, they could identify which inputs mattered, which results changed the next step, and where ownership remained with an engineer. That visibility was required before the agents could operate against the process.
Our initial expectation was simple: connect the environment, then run. The actual sequence was connect, document decision logic, then run. We have made that documentation phase a formal part of onboarding instead of leaving it as an implicit step. That change came directly from the first cohort and from the time teams spent reconstructing their own handoffs.
A two-engineer team covered the full flow together, unlike the larger teams. Their challenge was not distributed coordination, but lacking a second person to cross-check decisions.
What We Can Support
In a larger team, a handoff between domain owners can expose a mistaken assumption. With two engineers, the person who makes an interpretation may also receive the result, without an independent review. The coordination issue remained, but its shape changed. Here, the agents offered another perspective on reports rather than simply reducing the number of handoffs.
For that team, independent readings of timing reports and DRC summaries provided a useful cross-check. The agent did not guarantee that an interpretation was correct. It preserved what had been read and concluded earlier, giving the engineer something to revisit when later results were unexpected. That record supplied a second viewpoint where the team had not previously had one.
Changes for Cohort Two
We are reporting what we observed with five teams over one month. We are not claiming that these findings apply to every team, every flow, or every process node. The coordination pattern may differ with another tool configuration or a different level of process discipline. The two-person observation comes from one team. Our claim is limited to the cohort, the work we saw, and the changes that followed.
For the second cohort, documentation is now a structured onboarding step supported by a template. We also changed expectations for the opening days: the first three are dedicated to mapping decision logic, not running tools. Our materials now reflect where the first cohort found the real work. One month cannot tell us how these observations will hold in later flow stages. The second cohort will test that boundary.