Loopwork — AI Agent Operating System
A control plane for every AI agent in the company — provisioning, permissions, live monitoring, and human oversight in one operating system.
Most companies running AI agents today have a different one bolted onto every team — a support bot here, a finance bot there — each with its own ad-hoc logging and no shared way to see, govern, or trust any of them. Loopwork is a self-directed concept project exploring what an actual operating system for that fleet should look like.
Discover
I looked at how teams currently run multiple agents in production and found the same pattern everywhere: every agent gets its own one-off dashboard, permission model, and log format, built by whichever engineer shipped it first. There's no shared registry, no consistent guardrail system, and no single place to see the whole fleet at once.
Define
I scoped Loopwork around five things an operating system for agents has to do regardless of department: register and provision agents in one place, set per-agent permissions and guardrails, monitor fleet health and cost live, route only the genuinely risky actions to a human, and keep a full audit trail. Everything else — including most of what a typical logging UI shows — got cut.
Design
I designed the core OS console in Figma as a fleet dashboard — the full sidebar holds workspace navigation (Mission Control, Paperclip, AI Agent Mastermind), the live agent roster (Claude, Hermes, Gemini, Codex, and others with status avatars), project channels, and workspace utilities. The main view groups all agents by run state — Running, Needs Review, Idle, Paused — with status, risk, confidence, and assigned owner inline for each. Below the dashboard, two module sketches show the activity feed and approval queue. From there I scaled the concept out to a full 48-screen information architecture and a v2 component system (both below), so every screen in the OS is built from the same tokens and every governance warning traces back to a visible source.
Validate
There's no live user base yet, so validation so far has meant walking the design through worst-case scenarios by hand across a few different team types — a wrong refund, a missed escalation, a confidently wrong agent — and checking whether the interface would have caught it. The honest next step is putting this in front of real platform and ops teams.
No shipped outcome yet — this is an active concept piece, included to show how I'm thinking about agentic AI platform design, not a completed client engagement.
Two of the OS's modules sketched up close — the activity feed agents report into, and the approval queue that routes only the genuinely risky actions to a human.
Activity Feed module — concept sketch
Approval Queue module — concept sketch
The Loopwork console — fleet view
A concept screen for the OS's main view: the full agent fleet grouped by run state, with each agent's status, risk level, confidence, and assigned owner inline — the way a project tool lists tasks, but for autonomous agents.
The whole OS on one canvas — 48 screens, one closed loop
The fleet console above is a single screen. This map is the rest of the product: every screen in the OS, laid out as it's actually navigated — an eight-step onboarding flow, the eight-tab Mission Control console, a dedicated view per agent, ten project channels, nine workspace surfaces, and the settings layer reached through the workspace switcher. The organizing thesis is the numbered purple badges: they trace one governance event end to end. A spend policy gets set in Chat ①, is stored in Policies ②, trips a warning in the Inbox ③, is logged in the Audit Log ④, and its effect surfaces in Cost ⑤. No warning, pause, or block appears anywhere in the UI without a visible origin on another screen — that's the "closed loop" the product is named for.
Click to zoom · Governance badges ①–⑤ mark where the policy loop crosses screens
Seven screens, one path through the OS
One screen from each lane of the flow map above, in the order a new team actually meets them — through the front door, into Mission Control, down into a single agent, and out across the workspace surfaces where the governance loop begins. Every screen here is built from the component system below; nothing on any of them is a one-off.
The front door states the thesis
"Every agent in the company. One console." The sign-in form is deliberately unremarkable — the left panel isn't. It previews live fleet data (five agents running, fleet health 94%), so the product's pitch is the product itself. And the mono strip at the bottom — audit-ready · human-in-the-loop · per-agent permissions — makes the governance promise before you've even typed a password.
Agents, managed like work
The Board tab re-projects the fleet as a kanban: Running, Needs review, Idle, Paused — drag to reassign. Every card carries the same fleet, risk, confidence, and owner columns as the Fleet table, just spatially. Note where the two High-risk agents sit: in "Needs review," which is exactly where the OS routes human attention by default.
Every agent gets a dossier
Runs, confidence, uptime, and month-to-date spend up top; live assignments and a timestamped activity feed below; identity and permissions pinned right. Permissions read as three explicit tiers — can, can-with-warning, cannot — and the feed logs human intervention inline ("Incident-Responder paused by Jon after retries"). Policy v12 · updated 2h ago in the toolbar keeps the rules governing this agent one click away.
Agents and humans, same table
Quarterly goals with mixed ownership — gradient avatars for agents, flat-white JL for the human. That's principle 01 doing real work: accountability is legible per row. And the at-risk cost-per-task goal doesn't dead-end; its mono footnote names the cause (Antigravity runs at 2.4× the average) and points at the Cost tab. Planning is wired into governance, not sealed off from it.
Where the closed loop begins
This is badge ① from the flow map. "Why did spend jump this month?" gets an answer from live workspace data, chart and sources included. Then policy is set in plain language — cap Antigravity at $200/day, route over-cap for approval — and the confirmation carries its own receipt: policy change · logged to Audit Log. Everything downstream — the Inbox warning, the audit entry, the Cost effect — traces back to this exchange.
Every channel is a small console
Each of the ten project channels shares Mission Control's anatomy — stat cards, a governed table, a mono status line — scoped to one team's work. "Human handoffs" sits beside success rate as a first-class metric, and the paused win-back series shows the system self-reporting: a deliverability dip, flagged by the channel itself, with the pause visible in the table.
The evidence layer
Paperclip is where the fleet's output accumulates as citable clips — charts, run summaries, approval receipts, rollback plans. The mono footer is the governance hook: clips are citable — when an agent references a clip, the link lands in the Audit Log. Institutional memory that feeds the loop, instead of a screenshot graveyard.
One component system behind all 48 screens
Forty-eight screens stay coherent because none of them invents anything. Every surface, tag, avatar, button, form, card, and empty state is drawn from this single sheet, and every value on it binds to loopwork-tokens.json — a Tokens Studio file that maps color, spacing, radius, type, and sizing straight into Figma variables. Three rules govern the whole system. Humans are visually distinct: the eight agents each get a signature gradient avatar, while human teammates render flat white — you can never mistake who's accountable in a row. Consequences are traceable: status, risk, and approval tags share one semantic color scale, so a "Blocking" red in the fleet table means the same thing it does in a policy screen. Metadata is mono: anything the system measured — costs, percentages, timestamps, IDs — is set in Roboto Mono, so machine facts read differently from human language everywhere in the product.
Click to zoom · Pairs with loopwork-tokens.json and the flow map above
Humans are visually distinct
Agent avatars are gradients; humans are flat white at 10%. Ownership and accountability are legible at a glance in any table, feed, or approval row.
Consequences are traceable
Risk, status, and approval tags share one semantic scale across all 48 screens, so a warning always points back to the policy that produced it.
Metadata is mono
Everything the system measured — spend, confidence, timestamps — is set in Roboto Mono. Machine facts and human language never blur together.
Where an agent OS like this would plug in
Loopwork is a concept project — these are illustrative scenarios it's designed to support, not completed deployments.
Customer support fleet
A 40-agent fleet handling refund verification, ticket triage, and customer outreach across support queues.
- Per-agent confidence thresholds tuned by ticket type
- Auto-escalation when a refund exceeds policy limits
- Full conversation replay available for QA review
Finance & revenue ops fleet
Agents reconciling vendor invoices and flagging mismatches before they ever reach the ledger.
- Dollar-amount guardrails route high-value entries to a human
- Audit trail built to satisfy SOX-style review requirements
- Cost-per-agent tracked against the savings each one generates
Platform & DevOps fleet
Agents proposing deploys, running rollbacks, and triaging incidents overnight without a human on call yet.
- Read-only agents get broader autonomy than ones that can deploy
- On-call humans are paged only above a defined risk threshold
- Every automated rollback is replayable step by step
Open to senior product design roles
Remote, US hours — full-time or contract. Happy to walk through the decisions behind any case study here.