Multi-agent AI for EPC documentation packages

Multi-agent AI can compress the inter-discipline coordination that drives EPC rework – but only inside a semantic data fabric, behind deterministic code guardrails, and under a workflow that keeps the signing engineer accountable. Rohit Shinde explains

A client asks for 15% more rated flow to hold a revised column feed, and you make the change in minutes. What it costs is everything it touches afterwards: the mechanical datasheet, the suction line resized while rechecking NPSH, the control valve that has to match. The number goes out as a PDF attached to an email. Nobody gets the arithmetic wrong. The package still falls out of step at the interface.

The US National Institute of Standards and Technology estimated inadequate interoperability across US capital facilities at $15.8bn a year. It put two-thirds of that on owners and operators rather than the design office where the mismatch started.

Rework is where that shows up onsite. Across 359 projects in the Construction Industry Institute database, direct field rework came to about 5% of total construction cost. Weld repairs and late material take a share of that, as does a drawing set that disagreed with itself before it ever reached site.

None of that is a capability gap. Every discipline runs a capable tool (Aspen HYSYS, AFT Fathom for process and hydraulics, and so on.) Each is faithful inside its own lane. None of them hands off to another.

AI is already in this workflow. A knowledge-graph-grounded copilot can assemble P&ID configurations without fabricating components, provided the engineer stays in the approval loop.

That holds for one document at a time. But a documentation package is a connected system. It runs from P&IDs and civil drawings through structural, hydraulic and electrical calculations to equipment specifications and design reports.

'Teams of agents'

A multi-agent system distributes work the way an EPC organisation already does. A lead coordinates and discipline specialists execute.

The first architectural decision is topology because that choice sets the failure behaviour. A peer-to-peer mesh grows communication paths with the square of the agent count: 45 channels at ten agents, 190 at 2- (see Figure 1). No agent owns the global design state, so a piping-versus-structural disagreement has no arbiter and loops. Centralising the state fixes the arbitration and grows the channel count linearly, 19 at 20 agents, at the cost of one node that everything depends on.

That is the right trade. An EPC package needs a single authoritative design state more than it needs graceful degradation. It also argues for a small team, because every additional agent adds tokens to every commit. The hierarchy maps onto disciplines the project already runs:

Orchestrator (the project-engineering-manager agent) Owns global state, allocates tasks, escalates to a human, and commits only after validation.

Process agent Heat and material balance, hydraulics, line sizing and available NPSH.

Mechanical agent Equipment sizing, datasheets and nozzle loads against API and ASME rules.

Piping agent Routing, wall thickness, isometrics and pipe stress.

Structural agent Pipe racks, foundations and equipment supports against the governing code.

Electrical agent Load lists, cable sizing and hazardous-area classification. Instrumentation agent Instrument index, control loops and safety-instrumented functions.

Compliance agent Audits every proposal against the process-safety regime and the relief, flare and functional-safety codes that carry legal weight.

None of that division of labour is new. A 2026 survey of LLM orchestration frameworks maps the same three topologies (centralised, decentralised and hierarchical) and compares the leading implementations on token cost, state handling and failure recovery. What is new is a model fluent enough to run the traffic.

Only as good as the data

Agents that exchange free text will drift and hallucinate. Deterministic coordination needs a semantic data fabric: one machine-readable model of the plant, a knowledge graph in which every asset and connection carries a defined class and a persistent identity. Four established standards supply it, none proprietary:

ISO 15926-14 gives the shared ontology that lets a process agent and a piping agent mean the same thing by “centrifugal pump”.

CFIHOS tightens that vocabulary into a handover specification, the deterministic check on completeness.

DEXPI casts the P&ID as a traversable property graph of equipment, piping networks and instruments.

STEP AP242 carries the geometry with machine-readable tolerances, so clash checks run on boundary geometry.

If a pump is P-101A in the P&ID, 101-PA in the control system and “Pump A” in procurement, no agent can connect the three. Bind them to one reference-data class and the change resolves to the same object in every model. Tag reconciliation comes first, as scoped work with an owner and a date.

The gatekeeper

Left alone, agents will not produce correct engineering. Language models generate plausible output, and plausible is a poor standard for a relief valve, a flow orifice or a pipe schedule.

The fix is neuro-symbolic. Pair the model’s fluency with a symbolic layer that enforces the physics and the code. In practice that is a validation node between each agent and the shared state, running one invariant: generate, then validate, then commit (see Figure 3). Nothing reaches the package until a hard rule confirms it.

Pipe wall thickness 

The piping agent proposes Schedule 40 for a high-pressure hydrocarbon line. The validation node computes the minimum required thickness from the pressure-design equation in ASME B31.3 Para. 304.1.2, taking allowable stress from a materials database rather than the model’s memory. It adds the corrosion allowance, divides by 0.875 to cover the 12.5% mill undertolerance, and compares the result against the nominal wall of the proposed schedule. Schedule 40 falls short. The node returns a FAIL with the exact deficit, the agent reselects a heavier schedule, and the recheck passes before anything commits. The model gets no vote on the arithmetic.

Pump NPSH margin

The process agent proposes a suction arrangement. The node confirms that available NPSH clears NPSH3 by at least the 0.6 m API 610 requires at rated flow, or by the larger margin the project specification carries for high-suction-energy service. The compliance agent is adversarial by design. Which process-safety regime it enforces depends on where the plant sits: COMAH in the UK, Seveso III across the EU, OSHA process safety management at 29 CFR 1910.119 in the US. On top of that sit API 520 and 521 for relief and flare sizing, and IEC 61511 for safety-instrumented functions. It hunts the undersized relief line and the interlock that misses its integrity level, and blocks the package until that closes.

Where the hours come back

The value case has to be honest. Figure 3 sets the rework and clash numbers against the projections. A federated-model clash run on a large project returns results by the thousand, and a widely cited study of building projects found up to 50% of them irrelevant. Sorting that list is structured, high-volume work, and it is what agents are good at. If triage removes half of the noise, a quarter of the list never reaches the coordination meeting. What that is worth depends on your own clash logs rather than on this arithmetic: the 50% comes from building projects, and no clash statistic transfers between projects intact.

The two red bars, right of the divider, are projections. Reductions of that order, lead time down 70% and change orders down 40%, have not been demonstrated by any production EPC deployment, and a firm quoting them should test them against its own baseline. Savings concentrate in retrieval and cross-referencing and thin out where judgement takes over. The defensible near-term claim is loop compression, backed by the rework economics above.

Where the liability sits

The engineer who puts their name to a deliverable carries the professional and legal liability for it is responsible, and no AI assistance transfers any part of that. The mechanism varies by jurisdiction: a PE stamp in the US, a CEng signing off under an employer’s design-authority scheme in the UK. The accountability does not vary.

Three mechanisms defend that signature:

1 Bounded blast radius. Every automated change carries a scope that sets its autonomy level. Rerouting a small-bore utility line resolves silently. A change touching a vessel footprint or a safety envelope halts the workflow.

2 Immutable audit trail. Every proposal, rule verdict and human decision is logged append-only.

3 Escalation gates. Any code violation or unresolved conflict stops the workflow and hands the engineer the decision. Built this way, the technology strips search and coordination toil from the signing engineer so judgement lands where it matters. The agent does not sign the drawing. The engineer does.

Three questions to consider

1 Is the coordination burden across packages large enough to justify the data fabric underneath them?

2 Is your data ready? If tags do not resolve across your legacy P&IDs, control system and procurement records today, that reconciliation is the first investment.

3 Can you enforce the human-in-the-loop gates that your governance and your client’s process-safety case demand? Meet these conditions, keep the engineer’s signature at the centre, and a team of agents becomes a measured, auditable way to build document package right first time.