Design & EDA Copilot AI Agent

What this agent does

Drafts inside the boundary, decides nothing

Ingesting the repository files, constraint sets and review history the querying engineer is authorised to reach.

Normalising block names, revisions and tool versions, and carrying each suggestion forward with its source file.

Reason

Drafting RTL, constraint edits, schematic notes and testbench scaffolding as proposals, never as committed work.

Applying the design rules, naming conventions and review checklists configured for the programme.

Binding each suggestion to the file, revision and section behind it, and marking what the repository leaves open.

Decide

Flagging anything that reaches a safety-related item, an unclear requirement or a claim the sources do not carry.

Routing every suggestion to the named engineer who owns the block.

Out

Retaining the model version, the retrieved inputs, the suggestion and the engineer's decision on the design record.

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

AgentHuman

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.

5DecisionBranches at the confidence threshold

High confidence

Goes to the named engineer to accept.

Low confidence

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 required8 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 boundaryAgent 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 suggestionIllustrative example

Block

Suggested edit

Stated value

Source of record

Confidence

Held for

Clock-domain crossing

Add a synchroniser on the control handshake before the capture domain

2 stages

Programme design rules

89%

Named block owner

As receivedTaken 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 suggestionIt restates a rule the programme holds, on a revision the engineer can open.

ActionAcceptEditSend to verification review

What the score decidesBelow the threshold the suggestion picks up a verification read before the engineer sees it.

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value landsValue 01 – 04

Every requestFrom the design repository

03Drafting

Draft from the repository

Draw on the files the engineer may reach and the design rules configured for the programme.

01Approved path

Draft inside the boundary

Routine drafting, repository search and lint arrive already done.

02Human review

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.

04Build 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 managementPerforce Helix Core
Git · Subversion

Requirements and issuesJama Connect · Polarion
Jira · Azure DevOps

PLM and releaseTeamcenter · Windchill
Altium 365 · Aras

Agent

Design & EDA copilot

Reads inside scope
Drafts the change
Holds for the engineer

Verification and CIJenkins · GitLab CI
Confluence · SharePoint

Observability & evaluationOpenTelemetry · 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 defenceInward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to lint and search when evaluation or production signals degrade.Roll back

L5Version monitoringTrack model, prompt, retrieval-index and design-rule changes.Track

L4TraceabilityRecord the retrieved inputs, the suggestion, the flags, the edits and who accepted.Record

L3Engineer acceptanceHold suggestions for the named engineer; it governs entry, not whether an accepted change is right.Gate

L2Access guardrailsTest each retrieval against the engineer's access set in your own tenant index; a failure returns nothing.Restrict

L1Confidence thresholdsRoute low-confidence suggestions to a verification read before the engineer sees them.Require review

Model coreSuggestion produced — proposed edit, retrieved sources, flagged lines and confidence

L1 – L2Test whether a suggestion may stand

L3Puts entry in an engineer's hands

L4 – L5Keep the suggestion and what it was drawn from

L6Narrows 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

Depth of coverage ▼

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 lifecycleDirection of processing →

01 · Retrieval1 mode

EV-03

Out-of-scope retrieval

A file outside the engineer's access set is reached.

Stage gathersRepository files, revisions, rules and review history

02 · Reasoning2 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 proposesProposed edit, retrieved sources and confidence

03 · Tool / write2 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 writesOnly where write access and approval policy allow it

04 · Output1 mode

EV-01

Provenance omitted

The suggestion arrives without the file and revision behind it.

Stage returnsThe suggestion the engineer accepts into the design

05 · Change / Version1 mode

EV-07

Silent capability drift

A model or index change widens what the agent will assert.

Stage tracksModel, 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

See the complete Electronics failure-mode catalogue →

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 aggregateIllustrative example

Slice	Failure rate	Lift	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 stagesSwitchback — the path turns at Improve and returns at Learn

01Detect

Engineer-edit rate rises in a design slice.

02Diagnose

The suggestion is the unit — read beside the files it cited until one cause is left.

03Improve

Changes carry a version and the designs that prompted them.

04Verify

Release is held until the affected cases pass.

05Learn

The case is kept permanently, and the review rules move with it.

Learn → DetectThe 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.

02Repository and access-set assessment.

03Design-rule, review-checklist and provenance mapping.

04Repository ingestion and normalisation.

05Drafting logic and source binding.

06Confidence scoring and flag routing.

07Engineer acceptance workflow.

08Design-management system integration.

09Boundary and provenance cases.

10Guardrails and access controls.

11Design-trail instrumentation.

12Deployment, documentation and Agent Care handover.

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 priceConfirmed after discovery based on integrations, workflow complexity, request volume, approval controls and deployment requirements.

Separate from buildBuild 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 bringWe build with it

01Your repository structure and access sets → Repository ingestion and access-set mappingWeek 1

02Representative accepted design changes → Drafting baseline, rule extraction and source bindingWeek 2

03Your design rules and tool entitlements → Design-rule mapping and automation-boundary definitionWeek 1

04Access to relevant repositories, APIs or exports → Repository and access-set assessment, then integration setupWeek 2

05Suggestions that should never have surfaced → Provenance cases and failure-mode testingWeek 4

06What must reach a named engineer before it lands → Confidence scoring, flag routing, guardrails and access controlsWeek 3

07Named engineers to review suggestions → Engineer acceptance workflow, then pilot and production validationWeeks 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 W1W2W3W4W5W6

Discovery W1

Build W2 – W3

Evaluate W4 – W5

Pilot & Launch W5 – 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 bandEach bar covers only the weeks its work is named in. The week 5 overlap is real, not padding.

At the end of W6The block closes validation and Agent Care owns the running agent.

DurationSix-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.

Discuss this agent →

Nestack Agents · Design and EDA copilotAGT-EL-09 · Agent Care available after launch