OpsPilot
An AI operations inbox that turns each incoming email or document into a case with evidence, a proposed action, and a person who has to say yes.
The 82 second recording runs on a fictional property maintenance company. Every name, document, policy and amount in it is synthetic demo data. It is not a production deployment.
The situation
Support questions, sales leads and supplier invoices all land in the same inbox. Someone reads each one, works out what it is, finds the right policy, and hopefully routes it correctly. Most AI automation requests I get are this same lifecycle wearing a different costume. Receive a messy event, decide what it means, pull it into structured data, get context, propose an action, pause when it is risky, update a system, keep a record.
OpsPilot was commissioned by a contractor and customised to their workflow. The version here is the reusable core, demonstrated on a fictional property maintenance company with three intake types. Service inquiries become leads, warranty and scheduling questions become support cases, and supplier invoices go through validation.
How it works
The diagram is the pipeline. The frames below it are taken from the recording.
- IntakeGmail, uploads, forms and webhooks arrive through an n8n workflow that owns triggers, auth and retries and nothing else.
- StoreCaseA FastAPI service stores the raw object immutably and opens a durable case with a status.
- Classify and extractThe model identifies the intent and pulls schema bound facts. Invoice line items go to a deterministic validator.
- RetrieveVersioned company policy is searched and the relevant passages are attached as evidence.
- GateDraftA response or action is drafted with citations. If nothing clears the evidence threshold, the case escalates instead of guessing.
- GatePolicy engineDeterministic rules decide whether the action can auto run, needs approval, or is blocked.
- GateApproveA person reviews the exact payload. The approval is bound to its hash, so an edited action needs a new approval.
- StoreExecute and recordAn n8n execution workflow calls the connector and every step writes an append only audit event.
Everything lands in one inbox
Email and document intake is classified on arrival. Each row is a case with a type, an intent and a status.
A support case with its evidence
A warranty question is matched against the policy library. The retrieved passages sit beside the draft reply, each with a relevance score.
Escalate instead of guessing
When no policy passage clears the evidence threshold, no reply is drafted. The case goes to a person with the reason attached.
Validate an invoice with code
Extracted line items pass through deterministic rules. Here the items do not add up to the stated subtotal and the case stops for review.
Approve the exact payload
After correction, the proposed action shows the precise rows it will write. Approval is bound to that payload, so nothing executes if it changes.
Read the audit trail
Every classification, validation, correction, approval and execution is an append only event with who and when.
End the day with a summary
A daily view counts cases, human reviews and errors prevented. The figures shown are the synthetic demo’s.
Decisions that mattered
n8n for integration, never for business logic
Workflows own triggers, credentials and retries. Prompts, validation and approval decisions live in the API, so the canvas never becomes the place where the business rules hide.
Deterministic rules beside the model
Invoice arithmetic, duplicate checks, vendor authorisation and payload validation are ordinary code. The model classifies, extracts and drafts, and does not get the last word.
Approvals bound to a payload hash
An approval references the hash of the exact action. Edit the action after approval and the execution step refuses it.
Cite evidence or escalate
A drafted answer must cite retrieved policy. Below the evidence threshold the system escalates with the reason rather than producing a plausible reply.
Audit before autonomy
The audit log and the human approval path were built before any auto run rules, so autonomy can be widened case type by case type with a record behind it.
Where it landed
People only touch the cases that need judgment, and every one of those decisions has an audit event behind it. The same lifecycle handles support questions and supplier invoices with different handlers and one case model.
- Invoice arithmetic checked by code, not the model
- Approvals bound to the exact payload hash
- Unsupported answers escalate instead of guessing
- The public demo is not a production deployment and this page does not claim one.
- The first cut shipped two handlers. Sales leads, Gmail intake, calendar and CRM connectors were designed for the next version.
- Acceptance thresholds in the spec are targets, not measured results.
Notes from the build
Written in my own words, after the fact. Opinions, not claims.
I wrote the design for this as a spec first, about eight hundred lines, before touching code. The useful part was the boundary table. Which component owns what, and more importantly what each one must not own. Most of the bugs I have seen in automation projects are boundary violations, like business rules that quietly migrated into a workflow canvas.
The payload hash idea came from imagining the worst case, an approved action edited after the fact. It is a small amount of code and it removes a whole category of argument about who approved what.
Working under an NDA pushed me to build the synthetic company properly. Fake data that is too clean makes a demo look like a toy, so the invoices have real arithmetic mistakes and the policy library has gaps on purpose.
Nawap Bastola · 2026