The agent can search CRM and inspect email without turning every step into a permission modal.
OpsPilot
Let AI do the work.
Keep control of what actually happens.
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
Giving a model a tool is not the same as
giving it authority.
OpsPilot explores that distinction directly. The model can form intent and request tools, but a separate application layer decides what is visible, allowed, connected, approval-gated, executable, and verifiable.
DEMO / WHAT YOU CAN SEE
CRM → GMAIL → HUMAN APPROVAL → VERIFIED WRITE
The interesting moment is where the run stops itself.
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.
SYSTEM / ARCHITECTURE
GOAL → MODEL → POLICY → APPROVAL → EXECUTION → VERIFICATION
The control plane is the product.
The model is one participant.
01Human goalplain-language task
02Modeltool proposal
03Policyauthorization gates
04Approvalhuman when needed
05Executionprovider adapter
06Auditfresh read + evidence
ENGINEERING / DECISIONS
Permissions are several different questions.
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.
ENGINEERED BY MALEK EL BADAWI EL NAJJAR