A north star visiontype for agent-orchestrated GRC

The impact

At Workiva, I set out to answer a bigger question than any single feature could: what does GRC look like if it stops being document-centric and becomes agent-orchestration-centric instead? L5 - the maturity level marking that shift for Workiva’s flagship NextGen GRC product - is that answer: a visiontype - a north star prototype, built to be navigated rather than presented - of a fully agentic GRC workspace, built end-to-end in code with Claude Code, meant to align the team around where we’re headed rather than incrementally patch the product we have today. It also became the first real stress test for NextGen GRC’s new AI-native design system, and the first prototype to run through an AI playground I built for pressure-testing the system more broadly.

This is exploratory, unreleased work, so the impact here is directional rather than shipped: shaping where the product needs to go so we can work backwards and build a design system that supports agent-orchestration experiences from the ground up, instead of retrofitting one built for documents. Our head of engineering reacted positively, and core concepts from the prototype are now being carried into Amplify, Workiva’s annual company-wide convention.

Reimagining GRC as agent orchestration, not documents

The shift starts with the shape of the product itself. Today’s GRC is organized around documents; L5 is organized around agent orchestration, with navigation built around Chat, Review, Containers, Objects, Files, Agents, and Graphs instead of the document-centric structure GRC has always had. Getting this right mattered more than any individual screen: it’s a different mental model for what the product even is, not a new coat of paint on the old one.

Designing for an agent people can actually trust

Working through L5 meant designing for two things directly: previewing what an agent intends to do before it acts, and making every agent action auditable and reversible. A typical flow: a user opens Review and works through a queue of exceptions an agent has flagged, then travels into the specific Object or Container behind one to approve or attest to it directly - trust isn’t a separate concept bolted on, it’s built into how review and approval actually work. None of this is exotic - it’s the same accountability GRC has always required - but it doesn’t yet exist as a pattern in our design system, which is exactly why this prototype needed to exist.

Building in code, not comps, to pressure-test the system in real time

Prototyping L5 in code rather than in Figma was the point, not a shortcut. It let me build against the actual design system components as they existed that week, catch where they broke under a use case they weren’t designed for yet, and bring working proof back to the team building the system - not a mockup of what I hoped would work. That loop, prototype in code → find where the system bends → fix the system, is now part of how I work day to day, not a one-off exercise. The prototype at the top of this page is that build, running - not a recording of it.

Reflection

This is intentionally unfinished, exploratory work - a vision, not a roadmap commitment - and I expect the specifics to keep changing as the design system matures. What I’m most confident stayed true: agentic surfaces need to be designed and stress-tested with real interaction logic, not approximated, and doing that in code is what let this prototype actually earn its keep.