Tulip's agent builds factory apps after an engineer approves its plan. In GxP plants, that gate is the product

In a plant that makes medicines or medical devices, the app an operator uses to record a batch step is part of a validated system. Changing a field, a check or the order of two steps is a controlled change, with a reason, a review and a record. An AI agent that edits such apps is useful only if it fits that discipline.

Tulip, whose frontline operations platform runs apps on many factory floors, announced AI Authoring on October 9 at its Operations Calling conference in Boston. The design choices say a lot about what agents need to look like in regulated manufacturing.

Four pieces, none generally available

The announcement has four parts, each at a different stage:

• Projects proposes a plan for a value stream, line or process from a team’s existing material: SOPs, layouts, process documents, existing apps, libraries and best practices. It is entering customer testing.
• The Authoring Agent, a chat panel in the app editor, drafts new apps and changes existing ones from an uploaded SOP or a process description, on the team’s existing data model. Also entering customer testing.
• Composable AI Agents give reviewers a first pass on testing, documentation and evaluation. Open beta.
• Code-Based Apps let engineers build apps in their own IDEs with AI coding agents and run them on Tulip, as frozen, fully audited versions that Tulip says are “designed for GxP environments.” Preview, with design partners.

That spread matters for planning. Nothing here should enter a validated environment as if it were finished.

The plan is the first controlled record

The most important sentence in the announcement is about what the agent does not do: “Nothing changes until the engineer approves it.” The Authoring Agent asks clarifying questions, proposes a build plan, and only after approval drafts the changes, which the engineer reviews one by one, with the option to take over in the editor and the final say on what gets published.

In regulated terms, the approved plan is valuable on its own. It states what will change, why, and on the basis of which SOP, before any change exists. That is the shape of a change request, and if the platform keeps it, the plan becomes evidence rather than chat history. The question to ask Tulip is precisely that: are the plan, the agent’s drafts and the engineer’s edits retained as a reviewable record linked to the published version?

This is the pattern we described in agents as authors of production changes: the control for agent output already exists, and in manufacturing it has a name, change control. An agent that produces a plan before it produces a change fits it naturally.

Review agents assist; they do not sign

Composable AI Agents are positioned as a first pass for reviewers on testing, documentation and evaluation. That is a reasonable use, with a boundary worth keeping explicit. In a validated process, the review that counts is performed and signed by a qualified person; an agent can prepare it, highlight gaps and draft documentation, but it cannot be the evidence that the app is fit for use. As we put it in regulated AI, proof comes from outside the model.

Code-based apps bring software supply chain questions

Code-Based Apps open Tulip to code written with external coding agents in engineers’ own IDEs. The frozen, audited versions address part of the regulated requirement. The rest is the familiar software question: which agent wrote which code, what it was allowed to access, and how that code was tested before it reached the floor. Those questions belong in the validation plan, not after it.

Tulip does not describe a validation process in detail, and none of the four components is generally available, so regulated manufacturers have time to ask the right questions. The design direction is right: plan first, approve before change, human review at publication. The validation work is still yours.