Product AI agent · Spec drafting
Spec & PRD Drafting AI Agent
Write the requirement that would otherwise never exist — the default, the misuse case, the retention period — and hold each draft, with the finding it came from, for a named engineering owner.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Owner approval
- Source-bound
- After launch
- Agent Care
What this agent does
Writes the requirement, never approves it
In
- 01
A requirement is drafted from the finding that raised it, and the finding travels into the document with it.
- 02
A section is written for the default state, because a default nobody specifies is set by whoever writes the code.
Reason
- 03
A hazard is logged, and the control that answers it is drafted as a requirement with its acceptance criterion.
- 04
A security default is drafted, since the Cyber Resilience Act binds that default from December 2027.
- 05
A retention period is stated, since minimisation by default under Article 25(2) is drafted, not coded.
Decide
- 06
A misuse section is written, because reasonably foreseeable misuse is a section and not a bug report.
- 07
A clause is marked not applicable, and the justification for scoping it out is drafted in the same line.
Out
- 08
A requirement cannot be stated without a decision nobody has taken, and that is raised as the finding.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
Drafting, tracing and versioning belong to the agent. Approval belongs to a named engineer or quality owner, who takes the requirement into the design record and owns it there.
Example workflow
One requirement, finding to approval
- 1Source material receivedA hazard log entry, an interview note, a standard clause, a support finding or a change request
- 2Context assembledThe document now in force, the requirements it already carries, the hazards open against it and the clauses it answers
- 3Requirement draftedThe requirement, its acceptance criterion, the source it came from and confidence
- 4Controls appliedCoverage checks, duplicate-requirement checks, testability checks and drafting confidence
No human action required
Stages 1 to 4 run unaided, and nothing is approved at any of them — the agent is drafting, and the owner lane opens at the approval gate.
Goes to the named owner to approve.
Adds a quality owner read first.
Owner review
The requirement is held with its source, its acceptance criterion and the coverage it closes.
Approve · Amend · Send to quality review
Approved — by the named owner
- 6Repository and tracker records updatedOnly where write access and document control allow it
- 7Outcome evaluatedCoverage closed, requirement churn, owner amendments and what review found
Amendments
Each owner amendment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Taking a requirement into the design record.
- Deciding a device software safety classification.
- Judging whether a standard applies to a product.
- Signing a technical file for a regulator.
Automation boundary
Agent acts unaided
- ✓Draft the requirement and bind it to its source.
- ✓Attach an acceptance criterion to each hazard control in scope.
- ✓Flag a default state that no requirement specifies.
- ✓Report each standard clause the document has not answered yet.
Nothing enters the design record except by a named owner, inside the agreed boundaries.
- Accepting that a hazard has been controlled.
- Declaring a requirement out of scope.
- Setting the risk a product is allowed to carry.
- Changes to the document, the baseline or the rules.
Example output
One requirement, annotated
Our SOP and process documentation agent writes down how work is done; this one writes down what must be true of a thing before it is built, and below is one requirement as it leaves it.
Requirement draft · single item
Illustrative example- Requirement
- Default telemetry and its retention
- Stated as
- One testable sentence, imperative
- Drawn from
- Hazard log, 4 August 2026
- Acceptance criterion
- Bound to a named test case
- Confidence
- Held unapproved
- Held for
- The named engineering owner
As received
Taken from the hazard log and the clauses the regulations name; no paywalled standard is quoted here.
What the draft carries
- Hazard log entry
- Interview note
- Standard clause
Why no approval here
Taking a requirement into the record is a judgement an owner makes.
What the score decides
Below the configured threshold a draft gets a quality read before the owner sees it.
Action
ApproveAmendSend to quality 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 requirement
From the finding that raised it
Where the requirement lands
The agent does not decide that a requirement is right. When one is approved and the build meets it exactly, the fault sits in the document, and the amendment is filed against the shipped release.
The requirement nobody wrote
Ask which side of the fork you are on. For ordinary software the document is private and discretionary. For a device — and a class I device counts once it is automated with computer software — it is the design input, and the duty attaches at drafting, not at build.
What was checked, and not found
For ordinary software no statute was found that requires a specification to exist, to be complete, to be accurate or to be traceable. What binds instead is the contract: the statement of work, and the acceptance criteria written into it.
Build an evidence trail
The requirement, the source it came from and the owner who approved it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Requirement repositories
- Jama
- Polarion
- Codebeamer
- DOORS
- requirement management APIs
Issue and change trackers
- Jira
- Azure DevOps
- Linear
- Change requests and defects
Risk and hazard records
- Hazard logs
- FMEA
- risk registers
- Design and post-market findings
Agent
Spec and PRD drafting
- Reads the findings
- Drafts the requirement
- Holds for the owner
Standards and regulations
- Clause libraries
- guidance texts
- Regulatory and standard clauses
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six gates between the finding and the record
Six gates along one corridor, the last the narrowest. What passes is set out in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a draft may go forward
- L3
- Leaves the approval to a named owner
- L4 – L5
- Keep the requirement and the source behind it
- L6
- Leaves the section unwritten when signals degrade
How Nestack evaluates it
Evaluate the whole drafting run — not only the document that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the document an auditor reads
- E1Final-output evaluationDid the requirement record the source it was actually drafted from?
- E2Step-level evaluationDid the agent read the live document, the open hazards and the right clause?
- E3Tool evaluationDid it read and write the correct document and the correct requirement?
- E4Confidence calibrationDo low-confidence requirements actually attract more owner amendments?
- E5Slice evaluationHow does performance change across specific requirement classes?
- E6Business outcomeHow many requirements needed an amendment before the owner approved?
Floor — the record the build answers to
Failure modes
Where each failure originates in the agent
Seven failure modes, set at the stage where each one first shows.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- QE-03
Stale clause read
The clause read is not the one now in force.
Stage gathers
The findings, the hazards, the clauses and the draft
02 · Reasoning
2 modes
- QE-04
Requirement stated, not sourced
A requirement appears with no finding behind it.
- QE-06
Untestable requirement drafted
The wording admits no acceptance criterion.
Stage proposes
The requirement, its source and its criterion
03 · Tool / write
2 modes
- QE-02
Thin draft passed forward
A draft moves on without the quality read.
- QE-05
Requirement bound to wrong document
The line is filed against another release.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- QE-01
Approved, source unrecorded
The record shows approval but not the finding under it.
Stage returns
The document a build reads and an auditor opens
05 · Change / Version
1 mode
- QE-07
Silent baseline drift
A clause moves while the stored requirement keeps the old one.
Stage tracks
Model, prompt, drafting rules and clause dates
- Sev-1 · a requirement approved on no source
- Sev-2 · a stale clause reaches the document
- Sev-3 · source degrades, draft held back
Affected slices
Hazard controls absorb the amendments
A document-level coverage figure can read clean while safety and hazard controls carry most of the owner amendments. Nestack reports the amendment rate by requirement class, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Safety and hazard controls | 12.1% | 3.7× | Review | |
| Security and default states | 8.6% | 2.6× | Review | |
| Privacy and retention rules | 5.4% | 1.7× | Watch | |
| Routine functional requirements | 2.3% | 0.7× | Normal |
Bar: amendment-rate lift vs. routine-requirement baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What an unwritten requirement costs
The loop shuts when the hazard that reached build unspecified is a regression case. That suite is what the next document drafted is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Amendment rate rises on safety and hazard controls.
- 02
Diagnose
The requirement nobody wrote, which is the hazard nobody controlled, is traced back through the drafting run until one cause remains.
- 03
Improve
Every change goes out numbered, with the requirements that caused it attached.
- 04
Verify
Nothing releases while one touched requirement case is still red.
- 05
Learn
The case stays on, and the drafting rules are rewritten alongside it.
Learn → Detect
The return edge. The next document is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, requirement drafting, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Requirement discovery and automation-boundary work.Week 1
- 02Hazard, interview and standard sources.Week 1, Week 2
- 03Finding-to-requirement and clause-coverage mapping.Week 1, Week 2
- 04Requirement source intake.Week 2
- 05Source, clause and hazard binding.Week 2, Week 3
- 06Coverage scoring and review routing.Week 3
- 07Owner approval workflow.Week 3, Week 4
- 08Repository and tracker integration.Week 5
- 09Requirement and coverage cases.Week 4, Week 5
- 10Guardrails and approval controls.Week 4
- 11Requirement-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 document, one release | ProductionProduction document control | AdvancedMultiple products / standards |
|---|---|---|---|
| Introduced at Pilot | |||
| Requirement drafting to your document rules | ✓ | ✓ | ✓ |
| Named owner approval | ✓ | ✓ | ✓ |
| Document-inventory baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by requirement class | — | ✓ | ✓ |
| Quality review workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Repository-and-tracker integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-source requirement drafting | — | — | ✓ |
| Cross-release requirement packs | — | — | ✓ |
| Large document estates | — | — | ✓ |
| Multi-standard drafting controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, document 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 live documents and the standard each answers to
→Requirement-class capture and clause mapping
Week 102Representative hazard logs, interviews and clauses
→Source binding, drafting logic and the coverage baseline
Week 203Your release calendar and the owners it names
→Clause mapping, source binding and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Repository, tracker and hazard-log assessment, then integration setup
Week 205Requirements you would not want traced
→Coverage cases and the evaluation round
Week 406What no draft may assume
→Coverage scoring, review routing, guardrails and release controls
Week 307A named owner who approves the requirement
→Release to the named owner, 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
Widths answer to the work and not to the grid, which is why a band sits beneath another in week five.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Requirement discovery, clause mapping and the automation boundary
W2Source integration and the document-inventory baseline
W3Requirement drafting, coverage logic and release controls
W4Evaluation suite, coverage cases and failure-mode testing
W5Repository integration, pilot documents and targeted corrections
W6One release cycle run under the engineering lead, then Agent Care handover
- Reading the band
- A bar spans the weeks its own work is named in, and week five carries two by design.
- At the end of W6
- Once the requirement record validates, Agent Care assumes the agent.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Product AI agent
Build a spec and PRD drafting agent around the requirement your last release never wrote down.
Show us one document you ship against and the hazard log beside it. If what you ship is a device, a vehicle or a product sold into the EU, then an omission is not a gap in the document but a gap in the thing. A requirement nobody can state comes back as a finding.
- Typical delivery
- 4–6 weeks
- Deployment
- Your live documents
- Owner approval
- Source-bound
- After launch
- Agent Care available
Nestack Agents · Spec and PRD drafting
AGT-PRD-02 · Agent Care available after launch