MES integration with AI agents works as one MCP server per system, MES, LIMS and QMS, behind one agent that reads, correlates and drafts but never signs. For batch release readiness it joins batch record exceptions, lab results and open deviations into a review packet; EU GMP Annex 11 leaves certification to a Qualified Person's electronic signature.
Where it breaks
01 · Split record
Batch record exceptions sit in the MES, test results in the LIMS, open deviations and CAPAs in the QMS. None of the vendor servers we found on 19 September 2026 crosses that boundary: Veeva's Vault MCP server reads Vault, and Körber's PAS-X K.AI is a documentation assistant in a pilot phase, not an agent on batch data.
02 · Join key
The MES knows an order and a batch, the LIMS knows samples drawn from it, and a deviation often names the batch in a text field. An agent that guesses the join will put the wrong result next to the wrong batch, which is the one error a release review cannot absorb.
03 · Identity
Vault's MCP server accepts only API access tokens and applies the Vault user's permissions. MES and LIMS integrations are commonly built on a technical account. Mixed together without care, the agent answers one reviewer with another reviewer's rights.
04 · Signature
Annex 11 expects only Qualified Persons to certify batch release, with an electronic signature, and 21 CFR 11.100(a) makes a signature unique to one individual and not reassignable. Any design that ends with the agent pressing release has failed before it is built.
The first answer is to wait for each vendor's assistant. It is the cheapest start and it produces three assistants, each fluent inside its own product. The QA reviewer still opens three screens, copies a batch number between them and does the correlation by hand, because that correlation sits between vendors. Veeva's server does not read PAS-X, and Körber's assistant does not read Vault.
The second answer is to copy everything into a data lake and point the agent at the copy. This one is attractive to IT, because it looks like one integration instead of three. It fails for release work on two counts. The copy is not the validated record, so every answer carries the question of whether it matches the system of record at the moment of review. And Annex 11 asks that data moved between systems keeps its value and meaning, which turns the pipeline itself into something to validate.
Neither is wrong everywhere.
The copy is the right tool for trends across months of batches. Vendor assistants are the right tool for questions that never leave their product. For release readiness and deviation triage, the design that holds is live, read-only access to each system of record through a small set of named operations, with the correlation done in the agent and the result delivered as a draft.
The architecture
01
An MES server with operations such as get_batch_exceptions, get_order_status and trace_genealogy. A LIMS server with get_results_for_batch and get_oos_status. For the QMS, where the vendor already ships a server, use it: Vault's MCP server exposes only agent actions flagged for API access, which is a tool list you can restrict rather than rebuild. Where an MES exposes a read-only model, as Execution Foundation-based Siemens Opcenter products do through an OData reading model, the server is built on that.
02
A mapping from the MES batch to its LIMS samples and to the QMS records that reference it, maintained as data, not inferred by the model. The agent asks each server for one batch, joins on the mapping and marks every gap it cannot close rather than filling it.
03
The output is a document for the reviewer: open exceptions, results against specification, deviations and their status, each line with the system and record it came from. It is written nowhere as a GMP record. The reviewer acts in the MES and the QMS as before, under their own signature.
Covered, and still needed
| Use case | What the agent covers | What is still needed |
|---|---|---|
| Batch release readiness | Exceptions, results and open deviations for one batch in one packet, each line traced to its source record | Review and certification by a Qualified Person, with an electronic signature, in the system of record |
| Deviation triage | The deviation next to the batch record, the lab result and equipment history; a draft root-cause hypothesis | An investigation owner who confirms or rejects it; CAPA raised in the QMS by a person |
| Genealogy question | Which serial numbers or batches contain a given lot, read live from the MES | Limits on traversal depth and result size, set per plant, or a recall question becomes a runaway query |
| Audit | A log of every tool call with the person who asked | The GxP audit trail stays the one inside each system; the tool log does not replace it |
21 CFR 11.10(e) asks for computer-generated, time-stamped audit trails of entries and actions that create, modify or delete electronic records. A read-only agent creates none, which is the point.
The configuration is the argument
Illustrative, not a product manifest. Three lines carry the design: writes are none on every server, the QMS leg is the vendor's own endpoint with an allow-list, and signatures are not exposed at all.
# batch-release-readiness: server set (illustrative)
# Every server read-only; the agent drafts, a Qualified Person signs.
servers:
mes:
tools: [get_batch_exceptions, get_order_status, trace_genealogy]
writes: none
lims:
tools: [get_results_for_batch, get_oos_status]
writes: none
qms:
endpoint: <your-vault>/api/ai/mcp # Veeva Vault MCP server
agent_actions: allow-list only # actions with API access enabled
writes: none
correlation:
batch_key_map: managed table, not model inference
output: draft_review_packet # a document, not a GMP record
signatures: not exposed # EU GMP Annex 11 cl. 15; 21 CFR 11.100(a)If a reviewer can find a tool on this list that changes a record, the list is wrong. The packet is the only thing the agent produces.
When one of the rejected answers is right
If the question never leaves one system, one server is enough and the correlation layer is overhead. Genealogy in a discrete plant is the typical case: the answer sits in the MES and nowhere else, which is what an Opcenter integration on the reading model covers. And if what you need is trend analysis across months of batches rather than one batch today, the data-lake copy wins, because nobody signs off a trend.
No. It can prepare the release and nothing more. EU GMP Annex 11 expects the computerised system to let only Qualified Persons certify batch release, using an electronic signature, and 21 CFR 11.100(a) says an electronic signature is unique to one individual and may not be reassigned. The agent's job ends at a review packet: exceptions, results and open deviations for one batch, in one place, for the person who signs.
It is enough for questions that live in Vault. The Vault MCP server, generally available since release 26R1.4, exposes Vault agent actions under the user's Vault permissions. It does not read the batch record in the MES or the result in the LIMS, and batch release needs all three. Use Veeva's server as the QMS leg of the architecture rather than building a second one.
Usually yes, and your quality unit decides how far. Annex 11 asks for an up-to-date inventory of GMP-relevant systems and, for critical ones, a description of their interfaces and data flows. A server that reads batch records and feeds a release decision belongs in that inventory, with a risk assessment that sets the validation depth. Read-only lowers the risk; it does not remove the system from scope.
It starts with one system. The two-week Readiness Blueprint is fixed at €4,900 and covers one source system: tool list, identity test and a costed build plan. A first production server is usually a use-case pilot from €15,000. Each further system reuses the identity and audit work, so the second server costs less than the first. Validation effort sits with your quality unit and is not in these figures. Prices are net of VAT.
Then someone else runs them, but in your network, not in theirs. The servers sit next to validated systems, so hosting them in a third party's cloud adds a supplier to your Annex 11 agreements and a data flow to your inventory. We hand over code, tests and runbook; if you want us to operate them, monitoring and on-call start at €3,000 per month, on your infrastructure.
Next step
Two weeks, fixed price: one source system, the tool list agreed with its owner, a test of whose identity each call runs under, and a costed plan for the server. The architecture for the second and third system comes with it.