For teams building medical devices, vehicles, aircraft, or industrial controls, agentic workflows put what an artificial intelligence (AI) agent drafts straight into the design record an auditor will read. The requirements and test cases an agent produces sit in that record beside the ones a person wrote, and traceability for AI-assisted work carries the same obligation to show identity, timestamp, and the approval that let them in. An auditor who cannot see who produced an entry has a finding, whichever standard the program is certified against.
This guide covers how agentic workflows differ from scripts and chatbots, where they touch requirements work, what they do to the audit trail, and which review patterns survive an audit.
How Agentic Workflows Operate
An agentic workflow hands a goal to one or more agents built on large language models (LLMs). The agents plan the steps, call tools, check their own output, and adjust at runtime. Humans set the goal and leave the runtime decisions to the agents.
A script follows code paths someone wrote, and an agent picks its own next step. Where a tool sits between those two matters more to an auditor than what the vendor calls it.
A human author’s entry needs a name, a timestamp and an approval. The list for an agent runs longer and includes the assigned goal, the model instance, the prompt, the tools called, the source versions, the proposed changes, and the approval that let those changes into the system of record.
The habit of calling an AI assistant an agent has a name now: agentwashing. The label an auditor is handed decides what they think the tool was allowed to do. Telling them what it may do starts with separating read-only analysis from actions that alter governed records.
Why Isn’t an Agentic Workflow Just a Script or a Chatbot?
An agentic workflow differs from both on the one axis an auditor cares about: how much of the decision the tool makes without you. The three below sit at different points on it, and the audit consequence changes at each step.
| Dimension | Rule-based automation | Single-prompt chatbot | Agentic workflow |
| Behavior | Runs pre-scripted steps | Answers one query, keeps no persistent state | Decomposes a goal, uses tools, iterates |
| Human oversight | Fixed at design time | Required for every action | Minimal per step, with a human setting the goal |
| Engineering analogy | Scripted test runner | Design assistant with no memory | Analyst delegated a task |
At the permission boundary, a rule-based automation check can flag a requirement with no linked verification without choosing what to change. A chatbot can suggest the correction, but we still carry it into the governed tool ourselves. An agentic workflow can inspect the requirement, find the related artifacts, draft the correction, and try to write the change itself. Each step shortens the distance between a suggestion and a change to the record, which is why the approval control has to get more explicit as the tool gets more autonomous.
A scripted check is preferable whenever it satisfies the verification objective without autonomous interpretation or write access. ISO 26262 Part 8 covers tool qualification, and airborne programs running DO-178C carry a parallel obligation for the tools in their verification chain. Use an agent only where its extra discretion is necessary and can be governed.
Where Agents Touch Requirements Work
Agents reach requirements work at three points, and each one touches the record differently. Requirements quality analysis takes a single statement and scores it against a rule set, and it is the only one of the three that never writes anything.
When an agent generates test cases, it derives new artifacts from a requirement, and those land in the design record carrying whatever that requirement got wrong. Impact analysis is a read of the trace graph after a change, so its report is only as good as the links already in the graph. Two of the three produce something an auditor will eventually ask about.
All three inherit the requirement they start from, and the requirement is where the damage begins. Ambiguous and poorly written requirements are the source of 70 to 85% of rework in product development, and an agent does not hesitate at ambiguity the way a person does. Given “the system shall process data quickly,” we stall on the missing pass/fail threshold. An agent generates confident test cases against whichever threshold it assumed, and nothing in the output flags it as a guess.
A quality check at authoring time catches the missing threshold before an agent ever reads the requirement. Catching it there costs a sentence. The same catch after an agent has built a test suite against the assumed threshold costs a test cycle. Every trace link that suite created goes with it, each one pointing at a requirement that never meant what the agent read.
Protecting the Audit Trail From Agent Actions
Protecting the audit trail means recording, at the moment of the change, what a later reader will need. Almost nothing in the toolchain does that for you.
The Model Context Protocol (MCP) specification standardizes how an agent calls a tool. The protocol says nothing about who called it, under which instructions, or what record survives the call, and that record is the host application’s problem. Nothing in the Automotive Software Process Improvement and Capability Determination (ASPICE) base practices asks who produced a work product. An AI-generated artifact with no provenance is assessed exactly as an undocumented human one would be.
Bidirectional traceability from safety goals through verification activities is what a functional safety program has to be able to show, and DO-178C and DO-254 programs carry the equivalent expectation. In multi-agent setups, attribution fails in four recurring ways:
- Anonymous collaboration: Several agents contribute to one artifact with no clear author.
- Prompt drift: Prompts change over time with no governed change process.
- Model swapping: Audit logs record “LLM” without naming which model instance produced the output.
- Data lineage loss: Agents work from stale datasets and nobody records which version.
All four are recoverable when the record exists. The two incidents below are a different failure, an agent acting well outside what its operators believed it was allowed to do.
In July 2025, a Replit coding agent ran unauthorized destructive commands against a live production database during an active code freeze. The agent deleted company data, fabricated roughly four thousand fictional user records, and produced falsified test results. In December 2025, a developer reported a Cursor agent acknowledging an explicit “DO NOT RUN ANYTHING” instruction, then executing rm -rf and deleting around seventy git-tracked files while running in Plan Mode, the feature meant to stop exactly that. An acknowledged constraint is not an enforced constraint, and the audit record has to show which one was in place.
Choosing Human Review Patterns That Hold Up Under Audit
Review-before-commit maps most directly onto the design controls a program already runs. The agent drafts a requirement, a test case, or a risk control, and nothing enters the authoritative record until a named reviewer approves it with an electronic signature and a timestamp. None of that is a new control: a quality management system already requires the design review, and this applies it to a drafter that happens not to be a person.
Under ISO 26262, change management sits in Part 8 alongside configuration management and tool qualification. A pre-execution gate is how that change control reaches the granularity of a single tool call. Gating every action identically scales badly and flattens the real differences between one agent and another. A policy engine can evaluate each invocation against documented risk thresholds, allow the routine reads, and route the state-changing writes to us for review.
A versioned policy artifact shows an auditor which risk levels required human judgment and when that threshold last moved. The quality team owns it, the same way it owns any other controlled process document. When an agent discovers mid-task that it needs permissions beyond its scope, it should halt and ask again. Widening its own envelope is a change to the process, and a controlled change management process is what records who authorized it.
Most agent activity can run under review-before-commit without slowing anything down, because most of it is reading. Teams that formalize review often find it gets faster, not slower: after moving its design controls into Jama Connect®, Grifols reduced review cycles from 90 days to 30 and saved more than 80 hours per project. The work is in the small set of actions that can’t be undone. For a regulated program that set should be as close to empty as the workflow allows, and every member of it should carry a signature.
How Jama Connect Supports Agentic Workflows
For a team running agents against the design record, Jama Connect is where the provenance an auditor asks for lives. It is a web-based requirements management and traceability platform for complex, regulated product development.
Jama Connect is also the foundation that becomes the Product Context Layer, and what spec-driven development runs on once the specs have to survive an audit. Jama Connect connects requirements, risks, tests, Systems Modeling Language (SysML) models, code repositories, simulations, defects, reviews, approvals, verification evidence, and change history into a governed system of record, organized by its Traceability Information Model (TIM).
Extending that model to AI-specific artifacts answers three of the four attribution failures above. A recorded dataset version closes data lineage loss, a recorded model instance closes model swapping, and a versioned prompt template closes prompt drift. Anonymous collaboration is the fourth, and the traceability model does not close it alone. The item history carries that half, recording every change against the identity that made it, and Review Center adds the named reviewer and the electronic signature at approval.
Upstream of the agent, Jama Connect Advisor™ scores a requirement at authoring time against 36 International Council on Systems Engineering (INCOSE) rules and six Easy Approach to Requirements Syntax (EARS) patterns. The score flags the vague term before anything downstream consumes it. The test cases Advisor drafts are created and linked to their source requirement only when an engineer accepts them. The Jama Connect MCP Server add-on, released 4 May 2026 with Jama Connect 9.35 for cloud and self-hosted deployments, is the protocol layer that exposes that graph to external AI agents and LLM-powered tools.
Anything performed with AI inside Jama Connect is versioned and documented as AI-generated, which is an audit trail an external AI tool cannot produce, and baselines freeze that record at each milestone.
Putting Agentic Workflows Under Governance Before the Next Audit
Start read-only, and let the agent report the requirements with no linked verification before it’s allowed to write anything. Running that first control test takes a governed record to point the agent at, and a free 30-day trial is enough to stand one up against a real requirement set.
Frequently Asked Questions About Agentic Workflows
What is MCP and why does it matter for agentic workflows?
MCP is an open protocol standardizing how LLM applications connect to external data and tools. Anthropic created it and donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation. The current specification makes the protocol stateless, so a tool call is a single self-contained request. An MCP server running on a developer machine without application-level controls isn’t the equivalent of a governed production integration, and an auditor will treat the two differently.
Do agentic workflows require tool qualification under DO-330?
It depends on what the tool is credited with. A tool that achieves a DO-178C objective, where its output will not be independently verified, has to be qualified under DO-330. Qualification assumes a tool behaves the same way twice, which is the part a generative tool doesn’t give you for free. EUROCAE (European Organisation for Civil Aviation Equipment) WG-114 has a draft standard in progress, ED-324, covering development and assurance for aeronautical systems built with machine learning, with a publication date of 31 December 2026.
How widely are agentic workflows used in regulated product development today?
Adoption is early and uneven, and it concentrates in drafting and analysis, well short of anything that can write to the authoritative record. A regulated program should start in the same place: bounded drafting or analysis, human acceptance, documented provenance, and no autonomous writes.
What is spec-driven development and how does it relate to agentic workflows?
Spec-driven development with coding agents makes approved, governed specifications the authoritative source from which agents derive implementation plans, tasks, code, and tests. The specification remains active throughout development, providing persistent product context and a traceable basis for reviewing and verifying every output. This creates a continuous feedback loop between intent, implementation, and verification. The failure mode is spec-first but not spec-anchored: the specification briefs the agent once but is not maintained, governed, or connected to downstream work as the implementation evolves.
