Leucine · AI Engineer · 2023–26
Pharma Workflow Builder
A “Lovable for Pharma,” built before Lovable existed: plain English into auditable, GMP-compliant apps
Leucine's flagship AI bet: a no-code app-builder for GMP cleaning validation. Each manufacturer describes its process in plain English, or uploads its SOPs, and the platform generates a working, fully auditable, role-based application at runtime, replacing bespoke per-client engineering with self-serve configuration.
The chronicle
In pharma, every drug manufacturer must follow cleaning-validation processes: at each step of manufacturing, equipment surfaces are cleaned of microbes and active pharmaceutical ingredients (APIs) and documented to GMP compliance. Every manufacturer runs its own roles and standard operating procedures (SOPs), and configuring that, per client, is exactly where the Pharma Workflow Builder came in.
There are two halves to the system: an app-builder engine and an application-rendering engine. Think of the builder as a “Lovable” for pharma: the client configures the workflow and its steps in plain English (or by uploading its SOPs) and adds its users and roles, the users being the end employees on the manufacturing floor. The hard constraint is regulatory: every action on a form or page must be auditable, digitally signed, and strictly role-gated. So the way the LLM generated forms, pages and their actions had to be predictable, deterministic, and configurable, and we had to achieve that on the weaker models of the time, with their hallucinations and small context windows.
The product went live at Piramal Pharma in India and Revlon in the USA, on a deal totalling around $500K. I was on it from the first sketch of the idea, working directly with the CPO and CTO and a small team of a couple of developers and a QA, owning the work across schema design, AI integrations, the orchestration engine, UI/UX, and prompt engineering, and experimenting across models to learn each one's strengths and where it belonged in the system.
Movement I
Two engines, deterministic by design
The system splits cleanly: an app-builder engine that produces configuration, and an application-rendering engine that draws forms and pages from that configuration at runtime.
- Configuration can be set manually or generated by the LLM under specific instructions, so the platform never depends on the model getting everything right
- A form step, for example, is defined by its form fields from a fixed set, each field's behaviour from a fixed set, and an action/effect list of SQL queries that fire on submission, an approach inspired by Palantir's architecture
- Constraining generation to those fixed vocabularies is what kept output predictable, deterministic and configurable on the weaker, hallucination-prone, small-context models available at the time
Movement II
Agents over one ontology
The app-builder engine resolves into three cooperating agents, each generating configuration that a runtime engine renders.
- Ontology & Workflow Builder: the admin describes the whole process in plain English or a document; the workflow agent breaks it into steps, then generates the ontology where the data lives (entities, attributes, relationships, lifecycle states), combining our system's predefined tables with the new ones it suggests. It's saved per tenant, each tenant's data in its own schema, which is what gave us multi-tenant isolation
- Form Engine & Action/Effect Engine: the form agent generates the field configuration and the actions that run after submission, each action transitioning the entity from one lifecycle state to the next. Inspired by Palantir's ontology-and-actions model, where actions produce ordered side-effects on submission
- Retrieval-grounded forms: when the admin uploads the SOPs, the agent runs RAG over those documents while the workflow is being described, pulling finer details like formulas and step constraints into the forms
- Page Builder Engine: for read-only, dashboard-like pages, the page agent picks the section type, configures the SQL against the tenant's ontology, binds it into the predefined design language, and saves a section configuration the page-renderer engine draws dynamically at runtime
Movement III
The indexing pipeline
The SOPs the admin uploads are messy (scanned, tabular, deeply sectioned), so the retrieval is only as good as the ingestion.
- Many SOPs and manufacturing records are scanned, so IBM's Docling does layout-aware OCR, preserving section hierarchy and structures like tables
- Chunking follows Docling's section tags (titles and depth), capped by character limits so no chunk grows too large; each carries section, page-range and other metadata, keeping tables and sections intact
- OpenAI 1536-dim embeddings per chunk are persisted with their metadata in PostgreSQL via pgvector for semantic similarity search at query time (more dimensions = finer semantic resolution, at more storage and compute)
- We chose pgvector over a dedicated vector DB like Pinecone: pharma's regulatory and data-residency constraints, a modest vector volume, and latency not being a concern made Pinecone overkill
Movement IV
Self-healing generation
Deterministic configuration still has to actually run, so the architecture verifies the LLM's SQL before any of it ships.
- The submission query the LLM writes is first executed against fake data generated in a sandboxed environment
- If it errors, the error log is handed back to the LLM and the query is repaired, a closed verification loop, not a hope-it-works hand-off
- The same self-healing governs the page engine, where the LLM generates the data query for a chosen section type against the fixed set of sections and design language
Movement V
The LLM orchestration harness
The agentic universe wasn't mature yet, so I built the entire LLM orchestration architecture from scratch, the layer that turns unreliable model output into reliable, production-grade configuration.
- Input guardrails for prompt injection and off-policy intent from the end user
- An LLM gateway routing across OpenAI, Gemini, Anthropic and Mistral, with the infrastructure to log every request's input, output, cost, and errors
- Rate limiting per user and per model, with fallback routing on context-limit hits, provider errors, and failures
- Output guardrails and output formatting before anything reached the application
Movement VI
Compliance by construction
GMP auditability wasn't bolted on at the end: the rendering engine enforced it on every interaction.
- Every submission captured audit data: who changed what, old value versus new value
- E-signatures were configured per action and demanded before submission in the UI, enforced through re-authentication so each change is tied to a verified identity
- Strict role-based access governed every form, page and action, as in Piramal's RST workflow, split across the QC Analyst and QC Supervisor roles