Electronics AI agent · Design and EDA
Design & EDA Copilot AI Agent
Draft RTL, constraints and review notes against the repository the querying engineer is authorised to reach, and hold anything touching a safety-related item for the named engineer who owns it.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named engineer
- Access-scoped
- After launch
- Agent Care
What this agent does
Drafts inside the boundary, decides nothing
In
- 01
Ingesting the repository files, constraint sets and review history the querying engineer is authorised to reach.
- 02
Normalising block names, revisions and tool versions, and carrying each suggestion forward with its source file.
Reason
- 03
Drafting RTL, constraint edits, schematic notes and testbench scaffolding as proposals, never as committed work.
- 04
Applying the design rules, naming conventions and review checklists configured for the programme.
- 05
Binding each suggestion to the file, revision and section behind it, and marking what the repository leaves open.
Decide
- 06
Flagging anything that reaches a safety-related item, an unclear requirement or a claim the sources do not carry.
- 07
Routing every suggestion to the named engineer who owns the block.
Out
- 08
Retaining the model version, the retrieved inputs, the suggestion and the engineer's decision on the design record.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
The agent proposes; the named engineer decides what enters the design, and your organisation stays responsible for what ships.
Example workflow
One request, query to design record
- 1Design request receivedRTL query, constraint change, layout note or review request
- 2Context retrievedRepository files, revisions and review history inside the querying engineer's access set
- 3Suggestion draftedProposed edit, the files behind it, flagged lines and confidence
- 4Controls appliedAccess-set checks, source-binding checks, safety-item flags and confidence threshold
No human action required
Stages 1 to 4 run unaided and nothing enters the design at any of them — the agent is drafting, and the engineer's lane opens at the confidence gate.
Goes to the named engineer to accept.
Adds a verification-lead read first.
Engineer acceptance
The suggestion is held with its retrieved sources, its flagged lines and the confidence.
Accept · Edit · Send to verification review
Accepted — merged by the engineer
- 6Design systems updatedOnly where write access and approval policy allow it
- 7Outcome evaluatedEdit distance, flagged-line outcomes, review findings and defects found after acceptance
Edits
Every engineer edit is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Releasing technology to anyone outside the access set.
- Signing off verification, coverage or a formal proof.
- Accepting a change into a safety-related item.
- Deciding an engineer's export or citizenship status.
Automation boundary
Agent acts unaided
- ✓Draft RTL, constraints and notes inside the permitted repository.
- ✓Search and explain what the repository already holds.
- ✓Lint drafts against the programme's configured rules.
- ✓Flag what a named engineer should weigh, and hold the suggestion.
Any write happens inside the boundaries agreed at implementation, never ahead of acceptance.
- Judging what your EDA tool licences permit.
- Claiming ownership or inventorship of its output.
- Taping out or releasing to manufacturing.
- Changes to access sets, rules or approval policy.
Example output
One suggestion, annotated
Everything the agent proposes is attached to the files it was drawn from.
Design copilot output · single suggestion
Illustrative example- Block
- Clock-domain crossing
- Suggested edit
- Add a synchroniser on the control handshake before the capture domain
- Stated value
- 2 stages
- Source of record
- Programme design rules
- Confidence
- 89%
- Held for
- Named block owner
As received
Taken from the repository and the design rule on record — nothing on this side is written by the agent.
Source files used
- Block RTL revision
- Programme design rules
- Prior review finding
Why this suggestion
It restates a rule the programme holds, on a revision the engineer can open.
What the score decides
Below the threshold the suggestion picks up a verification read before the engineer sees it.
Action
AcceptEditSend to verification reviewValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every request
From the design repository
Draft from the repository
Draw on the files the engineer may reach and the design rules configured for the programme.
Draft inside the boundary
Routine drafting, repository search and lint arrive already done.
Send review to the risky changes
Safety-item touches and low-confidence suggestions are marked, and that review — not the agent — is what earns confidence in the tool.
Build an evidence trail
The suggestion, the technology it drew on and the engineer who accepted it stay in the design record.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Design data management
- Perforce Helix Core
- Git
- Subversion
Requirements and issues
- Jama Connect
- Polarion
- Jira
- Azure DevOps
PLM and release
- Teamcenter
- Windchill
- Altium 365
- Aras
Agent
Design & EDA copilot
- Reads inside scope
- Drafts the change
- Holds for the engineer
Verification and CI
- Jenkins
- GitLab CI
- Confluence
- SharePoint
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the design
The controls sit inside one another. What none of them catches is set out below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a suggestion may stand
- L3
- Puts entry in an engineer's hands
- L4 – L5
- Keep the suggestion and what it was drawn from
- L6
- Narrows to lint and search when signals degrade
How Nestack evaluates it
Evaluate the design workflow — not only the finished suggestion.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the change that reaches the design
- E1Final-output evaluationDid every claim in the suggestion match the file it cited?
- E2Step-level evaluationDid the agent read the right repository, revision and rule set?
- E3Tool evaluationDid it retrieve inside the querying engineer's access set?
- E4Confidence calibrationDo low-confidence suggestions actually attract more engineer edits?
- E5Slice evaluationHow does performance change across specific design cohorts?
- E6Business outcomeHow many suggestions needed an edit, or a fix found in later review?
Floor — the outcome the programme answers for
Failure modes
Where each failure originates in the agent
Seven failure modes, placed at the stage each one originates.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- EV-03
Out-of-scope retrieval
A file outside the engineer's access set is reached.
Stage gathers
Repository files, revisions, rules and review history
02 · Reasoning
2 modes
- EV-04
Unsupported design reference
A rule or revision is asserted that the repository does not hold.
- EV-06
Over-stated correctness
An unproved property is described as verified.
Stage proposes
Proposed edit, retrieved sources and confidence
03 · Tool / write
2 modes
- EV-02
Write outside the boundary
A change is staged where the boundary excludes it.
- EV-05
Cross-project carry-forward
Material from another project's repository enters a suggestion.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- EV-01
Provenance omitted
The suggestion arrives without the file and revision behind it.
Stage returns
The suggestion the engineer accepts into the design
05 · Change / Version
1 mode
- EV-07
Silent capability drift
A model or index change widens what the agent will assert.
Stage tracks
Model, prompt, retrieval index and design rules
- Sev-1 · technology released outside the set
- Sev-2 · a wrong change enters the design
- Sev-3 · retrieval degrades, suggestion held
Affected slices
Overall quality can hide one bad cohort
An aggregate edit rate can sit over one cohort carrying the rework — mixed-signal and analogue blocks, where the repository is thinnest. Nestack reports the edit rate by slice.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Mixed-signal and analogue blocks | 7.0% | 3.6× | Review | |
| Third-party IP integration | 5.8% | 3.0× | Review | |
| Clock-domain crossings | 3.5% | 1.8× | Watch | |
| Documented digital blocks | 1.6% | 0.8× | Normal |
Bar: engineer-edit-rate lift vs. documented-digital baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
Every cycle ends by adding a test
The cycle ends when a case exists in the suite, not when the miss was discussed. That suite is what the next suggestion into the design is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Engineer-edit rate rises in a design slice.
- 02
Diagnose
The suggestion is the unit — read beside the files it cited until one cause is left.
- 03
Improve
Changes carry a version and the designs that prompted them.
- 04
Verify
Release is held until the affected cases pass.
- 05
Learn
The case is kept permanently, and the review rules move with it.
Learn → Detect
The return edge. What comes next is tested against a longer suite.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. The week structure follows the six-week plan — discovery, repositories, drafting workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Design workflow discovery and automation-boundary definition.Week 1
- 02Repository and access-set assessment.Week 1, Week 2
- 03Design-rule, review-checklist and provenance mapping.Week 1, Week 2
- 04Repository ingestion and normalisation.Week 2
- 05Drafting logic and source binding.Week 2, Week 3
- 06Confidence scoring and flag routing.Week 3
- 07Engineer acceptance workflow.Week 3, Week 4
- 08Design-management system integration.Week 5
- 09Boundary and provenance cases.Week 4, Week 5
- 10Guardrails and access controls.Week 4
- 11Design-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne block, one team | ProductionProduction design repositories | AdvancedMultiple programmes / sites |
|---|---|---|---|
| Introduced at Pilot | |||
| Drafting inside the access set | ✓ | ✓ | ✓ |
| Engineer acceptance | ✓ | ✓ | ✓ |
| Suggestion-quality baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by block and owner | — | ✓ | ✓ |
| Acceptance workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Design-management integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-programme rule sets | — | — | ✓ |
| Multi-stage engineering approvals | — | — | ✓ |
| High request volume | — | — | ✓ |
| Multi-site project controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, request volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your repository structure and access sets
→Repository ingestion and access-set mapping
Week 102Representative accepted design changes
→Drafting baseline, rule extraction and source binding
Week 203Your design rules and tool entitlements
→Design-rule mapping and automation-boundary definition
Week 104Access to relevant repositories, APIs or exports
→Repository and access-set assessment, then integration setup
Week 205Suggestions that should never have surfaced
→Provenance cases and failure-mode testing
Week 406What must reach a named engineer before it lands
→Confidence scoring, flag routing, guardrails and access controls
Week 307Named engineers to review suggestions
→Engineer acceptance workflow, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
The bands follow the actual work, which is why the fifth week doubles rather than pads.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Design workflow discovery, rule mapping and the automation boundary
W2Repository integration and the drafting baseline
W3Drafting workflow, confidence logic and access controls
W4Evaluation suite, provenance checks and failure-mode testing
W5Design-system integration, pilot blocks and targeted corrections
W6One block taken through review under the design lead, then handover
- Reading the band
- Each bar covers only the weeks its work is named in. The week 5 overlap is real, not padding.
- At the end of W6
- The block closes validation and Agent Care owns the running agent.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Electronics AI agent
Build a design copilot around who may query what, and against what.
Show us your repositories, your design rules and who accepts a change. Which engineers may reach which technology, and can you evidence that today? We map the boundary from there.
- Typical delivery
- 4–6 weeks
- Deployment
- Your repositories
- Engineer acceptance
- Access-scoped
- After launch
- Agent Care available
Nestack Agents · Design and EDA copilot
AGT-EL-09 · Agent Care available after launch