Case Study — Agentic AI + Safety Engineering

JARVIS: an AI assistant that acts — and asks permission first.

A voice-and-text desktop assistant wired into 37 real tools — notes vault, GitHub, CRM, calendar, database. The interesting part isn't that it can act; it's the risk-tiered safety system deciding when it may. Built as internal R&D: the same safety architecture goes into every client agent we ship.

37Integrated tools

3Risk tiers: safe / confirm / blocked

$5Hard cost cap per session

509Passing tests at v1

The JARVIS confirmation gate: a modal reading CONFIRMATION REQUIRED for vault.write — 'Write content to vault file Portfolio Test.md' — with a countdown timer and Approve and Reject buttons, over a dimmed HUD. — The core idea A write action caught at the approval gate: explicit human confirmation, a 60-second countdown, and a default of "no" if the timer runs out.

The problem

Capable agents need real guardrails.

AI assistants come in two flavors: ones that can't actually do anything, and ones that do things you didn't ask for. The moment an agent can write files, open pull requests, touch a CRM, or move money-adjacent levers, "it usually behaves" stops being an acceptable safety model.

The design question behind JARVIS: how do you give an assistant real, broad capability — and keep a human decisively in the loop exactly where it matters, without approval fatigue everywhere else?

What we built

Every action passes through a policy gate.

Risk-tiered tool registry. Every one of the 37 tools is registered as safe (runs immediately), requires-confirm (approval gate), or blocked (refused outright). Policy lives in code, not in the prompt.

Confirmation gate. High-impact actions pause mid-execution and render an approval card with the exact tool input, a countdown, and Approve/Reject. Timeout means rejection.

Cost governor. Every API call is metered against a hard per-session cap, visible in the HUD at all times; the session halts before it can overspend.

Real integrations. Obsidian vault read/write, GitHub, outbound-campaign CRM, Cal.com bookings, Supabase — plus opt-in computer use with per-action confirmation.

Transparent event model. Every message, tool call, result, and approval is an event on a timeline; the session is fully auditable after the fact.

How it works

Safe tools run. Risky tools ask.

A HUD built for operating, not chatting

Left: the append-only event timeline. Center: the conversation. Right: live tool activity with execution times. Top: connection state, computer-use toggle, and the session cost meter.

The JARVIS HUD mid-conversation: timeline of events on the left, the assistant's introduction in the center, and the cost meter showing $0.0028 of a $5 cap. — A live session — the reply streamed in under two seconds, metered at $0.0028 against the $5 session cap.

Safe-tier tools just run

"List the folders in my vault" hits a read-only, safe-tier tool. It executes in 3 ms, shows up in the activity panel with a checkmark, and the model answers with the actual contents — plus an unprompted tidying suggestion.

JARVIS executing the vault.list tool: the activity panel shows vault.list completed in 3ms, and the assistant lists fourteen vault folders. — Real tool execution against a real notes vault — timeline event, activity entry, grounded answer.

Risky tools hit the gate

Ask it to write to the vault and execution pauses at the confirmation card shown at the top of this page — tool name, exact payload, countdown. Here the request was rejected, and the interesting part is what happens next:

After the rejection: the activity panel shows vault.write failed with a red X while vault.list succeeded, and JARVIS responds that the write was blocked at the approval gate. — The rejection lands as a first-class result — the agent acknowledges the veto and moves on. No file was written.

Screenshots are from a live session against the real gateway and a real notes vault. The write request shown was deliberately rejected at the gate to demonstrate the refusal path — the file was never created.