The agents run every shift. Your control plan assumes they don't.

CompositesWorld reported this week what I already see on my own floor: AI agents coordinating production scheduling, tooling changes, and material flow in composites manufacturing. The demos are polished. Feed an agent a constraint set—autoclave availability, prepreg out-time, cure window—and it sequences your shift better than any planner working a whiteboard with a migraine. I don't doubt the technology works. I've built multi-agent orchestration platforms myself. What I doubt is your change-control system's ability to survive it.

I govern this class of process change as Head of Manufacturing Engineering Technical Authority for Airbus in North America. The agents aren't coming. They're already on the floor. And your PFMEA doesn't know about them.

Every optimization is an engineering change you didn't file

Here is the mechanical problem. An agent adjusts an autoclave cycle by twelve minutes to clear a scheduling bottleneck. That is a process change. It reroutes prepreg kits from Cell 3 to Cell 1 because Cell 3 has a tooling conflict. Routing change. It resequences layup operations to flatten a throughput spike. That is a change to a validated work instruction.

AS9100 doesn't have an exception for "the algorithm improved throughput." Neither does EN 9100. Neither does any customer-specific requirement I've audited against. A process change is a process change whether a manufacturing engineer initiated it or a reinforcement-learning loop did. The standard asks whether the change was validated, whether risk was assessed, whether the PFMEA was updated, whether the customer was notified. The origin of the change is irrelevant to the standard. It should be irrelevant to your control plan.

Now multiply that across a production day. An agent running continuous optimization on a composites line can make hundreds of micro-decisions per shift. Some touch parameters inside your qualified process window. Some press against the edges. A few step outside entirely. Each one is technically an undocumented deviation until someone classifies it, reviews it, and either approves it retroactively or kills the optimization.

The speed mismatch is the defect

Agents optimize in milliseconds. Your engineering change board meets weekly. Your PFMEA review is annual. Your validation loop—first article inspection, capability study, customer sign-off—runs in weeks or months. This isn't a gap. It's a structural incompatibility.

A control plan that assumes human-speed change will not survive machine-speed optimization. The defect isn't the agent. The defect is the governance latency.

I've dealt with this scale problem before, in a different form. At Airbus, I built Routing Verification KPIs that reduced internal lead time by 97%—not by speeding up the process, but by catching routing deviations at the volume and velocity they actually occur. We were processing thousands of routing events across multiple lines. Manual review was never going to keep up. The system had to detect, classify, and escalate automatically, against a qualified baseline that didn't move unless engineering approved it.

The agent problem is the same problem at a different clock speed. A single agent shift on a composites line can generate more process-touching decisions than your current validation loop was designed to review in a quarter. If your change-control system was built around human-initiated deviations—a planner calls the ME, the ME writes an ECN, the change board reviews it Thursday—then its input bandwidth is roughly two to five changes per week. The agent is generating that every hour.

What bounded autonomy looks like on a qualified line

You don't shut the agents down. I built MultiPS—a platform running 63 models in parallel with consensus synthesis—because I understand multi-agent coordination from the builder's side, not just from the operator's clipboard. The technology works. The question is where you let it work.

Bounded autonomy means fencing the agent's optimization authority inside your qualified process windows. The agent operates freely within validated parameters: sequence A before B, route Kit 7 to Cell 3 if Cell 1 is occupied, hold the autoclave at soak within the qualified band. The moment a decision touches a validated tolerance limit or proposes a sequence outside the approved routing, it stops being autonomous. It becomes an engineering change request that lands in a queue for human review.

This requires things your current system probably doesn't have. Machine-readable process windows—every qualified parameter with its tolerance, coded so the agent can check against it before acting. Change detection on every agent decision that intersects a validated parameter, logged with enough detail that an auditor can reconstruct what was decided, when, and against what baseline. And the same APQP discipline you'd apply to any other process change—risk assessment, validation, customer notification where applicable—applied to algorithmic decisions at the speed they actually occur.

I've seen what regulators ask when they encounter process changes with no validation trail. In a previous cycle, we cut EASA audit findings by 50% in one round, and the biggest contributor was closing exactly this kind of gap: changes that happened on the floor, were defensible engineering-wise, but had no paper trail connecting the decision to a validation. Now picture an auditor asking you to explain six months of agent-driven autoclave cycle adjustments. "The algorithm improved throughput" is not a validated answer.

The composites line that runs on agents will pass every throughput KPI you've got. It will hit takt, clear bottlenecks, probably reduce WIP by double digits. It will also generate audit findings your quality system cannot explain—because it stopped tracking process changes the moment a human stopped making them. The technology isn't the risk. The governance vacuum is. And it is filling with unvalidated changes right now, at a rate your next audit will discover.