The agent can search CRM and inspect email without turning every step into a permission modal.
OpsPilot
Review proposed actions
before they change your data.
OpsPilot sits between AI and business systems. The model may propose actions, but authorization, policy, human approval, provider execution, verification, and audit are owned by the control plane.
ROLERuntime · integrations · policy · product UI
STACKNext.js · TypeScript · PostgreSQL · OpenAI
SYSTEMSCRM · Gmail · Google Calendar
01 / MODELAI Proposesdetermines next action
02 / POLICYOpsPilot Validatesvisibility · permission · risk
03 / HUMANHuman Approvesexact rendered action
04 / SYSTEMSystem Executesprovider adapter
05 / VERIFYResult Verifiedfresh provider read
06 / AUDITAudit Recordedactor · decision · result
CONTROL PLANEMODEL INTENT ≠ SYSTEM AUTHORITY
WHY I BUILT IT
Reviewing actions
before they run.
OpsPilot checks the user’s permissions, connected integrations, and workspace policy before running a proposed action. Actions that need approval pause until the user reviews the specific email draft or calendar event.
DEMO / WHAT YOU CAN SEE
CRM → GMAIL → HUMAN APPROVAL → VERIFIED WRITE
Review an email draft
and a meeting request.
When the model wants to create a Gmail draft, the control plane renders the exact action first.
Approve or reject the specific action. Nothing consequential executes while approval is pending.
After approval, OpsPilot executes through the provider adapter, reads the provider again, then appends the audit event.
VIDEO / WALKTHROUGH
END-TO-END PRODUCT DEMO · 5:10
Watch the
approval workflow.
I explain how OpsPilot checks actions, then walk through a customer follow-up: reading records, reviewing a proposed draft, approving it, and checking the result. The public demo uses simulated data and actions.
SYSTEM / ARCHITECTURE
GOAL → MODEL → POLICY → APPROVAL → EXECUTION → VERIFICATION
How a proposed action
gets checked and executed.
01Human goalplain-language task
02Modeltool proposal
03Policyauthorization gates
04Approvalhuman when needed
05Executionprovider adapter
06Auditfresh read + evidence
ENGINEERING / DECISIONS
Actions pass separate permission checks.
Human authorization, agent tool visibility, integration state, workspace policy, and approval are independent checks.
The human approves the exact rendered action.
An approval is attached to the specific proposed input rather than a vague blanket permission.
A provider success response is not enough.
External writes are checked with a fresh provider read before the system records them as verified.
Runtime failure has explicit state.
Bounded retries, compare-and-swap transitions, and stale-run detection keep execution from silently getting stuck.
PRODUCT / BOUNDARY
PROPOSAL ≠ EXECUTIONThe UI keeps those concepts visibly separate.
Operators can see what the model wanted to do and what the system actually executed as different events.
PUBLIC DEMOThe demo stays outside the internal console.
The public walkthrough is isolated from the dev-identity workspace and its mutation surface.
MALEK EL BADAWI EL NAJJAR