VIDI · Agent governance

Agents you can audit

DVLP runs AI agents against real drug programs, and an agent that drafts regulatory documents needs receipts, not vibes. VIDI is the registry, the policy gate, and the audit trail around every one of them. Each agent is registered and tiered, every invocation passes a Cerbos policy check before it runs, every execution comes back with a KMS-signed receipt, and all of it lands in a trail you can hand to an auditor. I designed and built the front of both faces: the admin side that governs, and the Guild side where agents are authored and tested.

Role: Design engineer
Years: 2025–26
Stack: Next.js · Go · Cerbos
Scope: Admin + Guild, 2 themes

VIDI governance overview on a lab-paper canvas: stat cards for active agents, quarantined agents, policy denials, invocations, and spend; an agent registry health bar split by KYA tier; a recent invocations table; and a live policy decision feed showing entries like Allow, ingest agent facts, signature verified — Fig. 01The overview. Fleet health by KYA tier on the left, recent invocations in the middle, and the policy decision feed on the right, every entry an allow or deny with its reason.

Know your agents

Banks have know-your-customer. VIDI has know-your-agent. Nothing runs against a drug program until it has been registered, tiered, and signed, and the tier is not decoration: it caps what the agent may touch and how autonomously it may act. An agent's detail page reads like a passport, its declared tools, its trust posture, its domain, and the exact pipeline it walked to get here.

That pipeline is the spine of the Guild side. An agent moves from draft through QA review to sign and register to live, and each published version is minted immutably, so “which version produced this output” always has one answer. The trust posture meters put autonomy and scope on the same card, because those two numbers are what a reviewer actually weighs.

Guild agent detail page: a lifecycle pipeline running draft, QA review, sign and register, live; a note on immutable version minting; trust posture meters showing L4 autonomy and G1 scope; and domain tags for the agent — Fig. 02An agent's passport in Guild. The lifecycle pipeline across the top, immutable version minting, and trust posture meters for autonomy and scope.

Admin agent registry table listing agents with their KYA tiers, governance levels, domains, and statuses — Fig. 03The admin registry. Every agent in one table with its KYA tier and governance level, filterable when the fleet passes fifty.

Every run leaves a receipt

The gate itself is Cerbos. Every invocation is checked against policy before it executes, with CEL conditions deciding on the agent's tier, the resource it wants, and the environment it is running in. Writing policy UI is mostly a translation job: the rules stay readable as rules, and the decision feed shows each allow and deny in the same plain grammar, action, resource, reason.

When a run completes, the backend signs the execution record with AWS KMS, so a receipt is not just a log line but a claim someone can verify years later. The invocation log carries those signatures inline, and the audit trail behind it is anchored to a Hyperledger Fabric chain. The design job was keeping all of this legible: an auditor should read the trail like a bank statement, not a stack trace.

Invocation log: a table of agent executions with timestamps, invoked actions, policy outcomes, and signature status per run — Fig. 04The invocation log. Each run with its policy outcome and its signature status side by side.

Policies view: Cerbos policies listed with their CEL conditions, target resources, and the tiers they apply to — Fig. 05Policies. Cerbos rules with their CEL conditions kept readable as rules, not buried in YAML.

Audit trail view: a chronological ledger of governance events including registrations, policy changes, and invocations, each entry anchored to the audit chain — Fig. 06The audit trail. Registrations, policy changes, and runs in one ledger, anchored to a Fabric chain underneath.

The playground

Governance without a place to run things would just be paperwork, so Guild ships a playground. Point a formula at an asset and a supervisor agent delegates to clinical, regulatory, and supply-chain experts while a live React Flow graph draws the run as it happens: which agent is thinking, which tool it is calling, what it handed back. The plan checklist ticks off beside the graph, and the full recommendations report lands underneath when the run completes.

Direct invocation is the quieter mode. Pick one agent and the graph shows only its declared tools, the same declaration the policy gate enforces, so what you watch in the playground is exactly what production will permit.

Playground formula run: a live React Flow orchestration graph with a supervisor agent delegating to clinical, regulatory, and supply-chain expert agents, a completed plan checklist, and a full recommendations report below — Fig. 07A formula run mid-flight. The supervisor delegates across three experts on the live graph, with the plan checklist and the final report alongside.

Direct agent invocation: a tool graph showing the agent's declared tools, including documents get page, research search literature, and assets get drug context — Fig. 08Direct invocation. One agent, its declared tools on the graph: documents.get_page, research.search_literature, assets.get_drug_context.

Two rooms, one system

The admin side reads like the rest of DVLP, lab paper and one oxidized orange, because governance belongs next to the science it governs. Guild got a dark variant: it is where agents are authored and broken on purpose, and the people living in it asked for a room that feels like a workshop rather than a filing cabinet. Both run from the same tokens, so a kanban card or an environment picker is the same component in either room, just on a different ground.

Dark-theme agents kanban board in Guild with columns for Draft, QA, Published, KYA verified, and Archived, tracking 52 agents — Fig. 09The Guild kanban, dark. Fifty-two agents across draft, QA, published, KYA verified, and archived.

Dark-theme playground run setup: a choice between formula and single-agent mode, an environment selector for QA, Staging, and Production, and an asset picker — Fig. 10Run setup, dark. Formula or single agent, an environment gate, and the asset the run will touch.

System notes

Policy-gated by CerbosCEL conditionsKMS-signed receiptsFabric audit chainLab paper adminGuild dark