VOWGRID

Context

I wanted one project that treated AI-triggered actions like a real systems problem instead of a demo flow. VOWGRID became that project: a trust layer between AI agents and real-world actions, with policy checks, approvals, execution tracking, receipts, and rollback visibility. The repository now stays private while the product surface matures, but the system design remains strong enough to document publicly.

Problem

Most agent projects focus on what the model can decide. I wanted to focus on what happens after that. Once an action could touch a real connector, the project needed simulation, policy evaluation, auditability, queue-backed execution, and a readable control plane.

Constraints

The product had to explain a full action lifecycle, not just an API endpoint.
The backend needed clear module boundaries inside a modular monolith.
Local setup had to be reproducible with Docker, Prisma migrations, and seeded development data.
The web app needed to work against a live API but still expose provisional data flows when the backend was unavailable.

Core proofSimulation + policy + approval + execution

Repository signalMonorepo with docs, contracts, and runbook

Operational concernReceipts, audit trail, rollback visibility

Architecture

monorepo
  -> apps/api (Fastify + Prisma + BullMQ)
  -> apps/web (Next.js control plane)
  -> packages/contracts (shared schemas)
  -> packages/ui (shared primitives)
  -> docs + infra

01Propose the action

The system stores intent as a draft instead of jumping directly to execution, which keeps the control plane readable.

02Simulate before touching connectors

Simulation shows predicted side effects and payload shape before any connector call can mutate the outside world.

03Evaluate policy and approval

Rules, roles, and approval state become explicit gates instead of buried implementation detail.

04Execute through a queue

BullMQ owns retries, visibility, and execution state transitions so operations remain inspectable after the happy path.

05Issue receipts and rollback visibility

Execution ends with evidence: receipts, audit trail, and visibility into how rollback would be handled if the action had to be unwound.

Decisions and trade-offs

I kept the backend as a modular monolith because operational simplicity mattered more than service sprawl.
The trust model is layered explicitly: simulation first, then policy, then approval, then execution.
I used BullMQ because queued execution and retry visibility are part of the product story, not an implementation detail.
The repo includes both docs and working flows because a trust-oriented product should be understandable before it is impressive.

What worked

The project has a clear systems identity that is stronger than a generic "AI agents" repo.
The runbook, seed flow, and local Docker setup make the system easy to evaluate technically.
The monorepo structure keeps contracts, UI, API, and operational docs aligned around one intent lifecycle.

What is still incomplete

Rollback processing is visible but not yet completed by a dedicated worker.
JWT-based dashboard auth is still missing.
User-facing API key management and stronger E2E coverage still need to be added.

Evidence

Verified workspace flowPrivate VOWGRID workspace

Intent lifecycle:
- create draft
- propose
- simulate
- evaluate policy
- approve
- execute
- generate receipt
- inspect rollback visibility