Enterprise Tool Governance — Case Study

At a glance

The case in seven answers

Client: Northstar (anonymized)
What was the problem?: Ten admins assigned expensive Figma seats by hand, one chat message at a time, with no shared rules, no cost tracking and no way to reclaim idle seats.
Why did it matter?: Seat spend was only rebuilt from spreadsheets at renewal, paid seats sat idle while requests queued, and ten admins spent hours a month on decisions that follow the same logic.
What research was done?: Participant observation as one of the ten admins, an analysis of a quarter of the admin group chat, an audit of open requests (285 across all admins), a review of the vendor’s admin console and docs, and assumption-based personas that are not yet validated.
What constraints existed?: Any admin could approve any request in the vendor console, which shows no cost and no seats left. Each business unit has its own allocation and budget, and every decision had to be reversible and auditable.
What decisions did I make?: I chose agentic AI: the agent reads live signals and decides whether to suggest, ask or act, within autonomy limits admins set for each kind of job. Every agent action can be undone for 24 hours, a circuit breaker drops it back to Suggest, and anyone can bypass it.
How did engineering shape it?: Prepared for hand-off to IT. The limits sit in a policy layer the model cannot edit, the agent works through tools that read Figma activity and department budgets, and the prototype uses a rules-based stand-in for the language model so the decisions can be tested before a build.
What changed after launch?: It has not launched. It is a proof of concept for IT. The plan is to run the agent in shadow mode on real tickets, and let admin agreement and the undo rate decide how much autonomy it earns. Modeled saving: 80 to 15 admin hours a month.

01 Problem

Ten admins, one expensive resource, and no system

Figma had spread across a large enterprise made up of several business units. The expensive part is the seat, and each seat type carries a different price and a different set of capabilities. Ten admins were assigning them by hand in the vendor's admin console, which lets any admin approve any request with a click.

The console does not show what a seat costs, how many are left in a business unit, or whether the person will use it. Requests arrived by chat message and email, and each admin applied their own judgment. The result was that seat decisions were effectively random:

Who gets a seat, which type, for how long, and who pays for it were all decided one message at a time.

A portal would fix the process. But with ten admins reading every ticket, it would still be a lot of manual work. So the second half of this case study asks what an AI agent could do.

The problem, stated plainly

Ten admins assign seats manually, with no shared rules for who qualifies or for how long.
Nothing controls who assigns a seat. Any admin can approve any request, even when their business unit has none left.
Each seat is expensive, and cost is not tracked. Spend is reconstructed by spreadsheet when the renewal comes round.
No one removes inactive seats, so paid seats sit idle while new requests queue up.
Nobody knows which seat type a person needs. People ask for Full by default because nothing says otherwise.

02 Impact

Outcomes, business impact and learnings

This is a proof of concept prepared for hand-off to IT, so the business impact is modeled from assumptions, not measured. I have marked which is which.

Outcomes

What I delivered

A white-label portal and admin console: eight screens covering request, tracking, triage, AI credits, reclaiming seats and Insights.
An AI agent, designed end to end: six more screens built on Suggest, Ask, Act, plus a prototype with nine scenarios you can test.
A governance model: one inactivity rule, autonomy limits set by admins, and escape routes for everyone.

Business impact

Modeled, not measured

About 65 fewer admin hours a month in the illustrative model: 80 h down to 15 h for 400 requests.
Lower license spend. Right-sizing and reclaiming idle seats come to roughly $1,000 a month in the sample data.
Decisions in minutes, not days for the requests the agent handles.
Consistent, auditable governance, and Insights that replace the renewal spreadsheet.

Learnings

What I took from it

Match autonomy to reversibility. A seat is cheap to undo, so the agent can act. In the claims study a human approves every payout.
Design the exit before the entry. Undo, appeal, take over, pause and a circuit breaker are what make an agent safe to trust.
Memory turns repeat requests from a loophole into a signal.
Next: run the agent in shadow mode on real tickets. Admin agreement and the undo rate decide whether it earns more autonomy.

Admin hours per month, illustrative 80 h → 15 h

400 requests a month at 12 minutes each, versus 54% resolved by the agent and about 5 minutes for each exception the agent hands over already summarized.

Assumption	Value
Requests per month	400
Admin time per request today	12 minutes
Admin cost	$60 per hour
Agent cost per request	$0.10
Resolved without an admin	54%, from a dry run of the guardrails
Net admin time saving	about $3,800 per month

Assumptions, not measurements. Volumes and times are placeholders to be replaced with real ticket data in a pilot.

Designed outcomes, not measured results

This has not been built or tested with admins. The agent in the prototype is a rules-based stand-in for a language model, and the seat counts, prices, names and savings are synthetic. The next steps are to validate the flows and guardrails with the admin group, run the agent in shadow mode on real tickets, then have IT size the build.

03 Product

One request, five steps, fourteen screens

Anyone in the company can raise a request and follow it. An AI agent picks it up first and resolves what it safely can, and a business unit admin decides the rest. Select a screen to jump to it.

Request
Anyone asks for a seat or AI credits, with the price on screen.
01 Home 02 Seat 03 Credits
Agent
The agent gathers what is missing, right-sizes the request and decides, asks or hands it on.
05 Chat 06 Decision
Track
The requester follows the ticket with its number.
04 Status
Decide
Admins get a prepared queue: approve, reclaim an idle seat, or assign the credit tier that fits.
07 Queue 08 Review 09 Credits
Reclaim & learn
Idle seats return to the pool, and the agent's work is audited and tuned.
10 Inactive 11 Insights 12–14 Agent

The portal

Eight screens that replace the message thread

The foundation is a requester portal and an admin console. Select any screen to view it full size. All names, departments and figures are synthetic.

Portal home page with three actions: request a new seat, request AI credits, and check status, plus the inactive seat policy — **01Home**The single front door. The inactive-seat policy and review turnaround sit on the page, so the rules are known before anyone asks.

Seat request form with four seat tiers, each showing its price and AI credits, and an order summary totaling the cost for the project dates — **02Seat request**Four seat tiers with price, what each includes and its AI credits. The order summary totals the cost for the project dates.

AI credits request form with three credit tiers and a required use case — **03AI credits request**Credits are requested by tier with a required use case, reviewed against departmental budgets.

Status check showing a ticket with its seat, manager, project, dates and the agent decision — **04Check status**Enter a ticket number to see status, seat, project, dates and the agent’s decision. No more chasing admins.

Ticket queue with counts for open, ready, needs context and blocked tickets, and a Handled by agent column — **07Ticket queue**The admin’s queue, sorted by what blocks a decision. Only complete tickets within allocation can be approved in bulk.

Admin AI credits screen with the monthly pool, usage by person, and agent-triaged requests: one on hold, one topped up, two right-sized — **09AI credits**One shared pool. Each request arrives triaged by the agent, with usage forecast from real consumption.

Inactive seats list with Downgrade due statuses, potential saving, and an agent banner in Suggest mode — **10Inactive seats**One rule for everyone: two months inactive means a View seat, with notice and a 7 day grace period.

Insights dashboard with seats over time, spend against allocation, time to decision, seat activity and AI credit use — **11Insights**Seats, spend, time to decision, activity and AI credit use, with filters, tooltips and a table view.

Agentic AI

Less admin work, more AI work

The portal fixed the process, but ten admins would still open every ticket. Most of those decisions follow the same logic: is there a seat, does this person’s work need this tier, will they use it, does the business unit have room? That is a job for an agent.

When someone submits a ticket, the agent picks it up straight away. It reads the person’s Figma activity, their earlier requests, the department’s seats and spend, and the project. It asks only for what it cannot infer, forecasts AI credit use, and then does one of three things: decides, asks, or hands a prepared decision to an admin.

Admins stop being the workflow and become the policy.

The mental model: Suggest, Ask, Act

One idea runs through every screen. The agent never jumps straight to acting. It earns each step, and admins choose how far it may go for each kind of job.

Suggest

The agent reads the request, checks the facts and writes a recommendation with its reasoning and a confidence score. A person decides.

Use for: reclaiming a seat, low confidence, anything that touches someone’s access.

Ask

The agent prepares everything, then asks. It asks the requester one or two short questions, or asks an admin to confirm with one tap.

Use for: missing information, or a decision worth a second pair of eyes.

Act

Inside limits the admins set, the agent decides, tells the requester, writes down why, and can be undone for 24 hours.

Use for: reversible, capped, high-confidence work such as a Dev seat, a right-sized Collab seat or a bounded credit top-up.

Autonomy follows risk, not enthusiasm

In my Claims Adjuster Copilot case study, a person approves every payout, because payouts are costly and hard to undo. A seat is cheap to reverse, so here the agent can act. The design question is the same in both: how much autonomy does the cost of a mistake allow?

What the agent weighs

Four signals decide whether to assign a seat, and which one.

User activityEdits, Dev Mode opens and comments over the last 30 days. Someone who only comments does not need an editor seat.
Credit useCredits used against the limit, the run rate, and a forecast to the month’s end.
Department spendSeats left by type and spend against allocation, so a full department is never over-approved.
Project typeDesign, build, review or view-only work decides the cheapest seat that does the job.

In the prototype the agent is a rules-based stand-in for a language model with tools. The decisions, guardrails and interface are the design; the model itself is not connected.

The agent at work

One ticket, start to finish

The same ticket, seen by the requester and then by the admin. Each screen shows its work, so nobody has to trust a black box.

05

Agent chat

A new request opens a short conversation instead of a form that bounces back. A stage bar shows where the agent is: Suggest, Ask or Act. It runs its checks, then asks only what it cannot infer, here what the person will mostly do in Figma, using answer chips or free text. “Stop and ask a human” is always in the corner. What people type is treated as data, never as instructions.

Ask only what’s missing

06

Agent decision

The agent decides and shows its work: the path it chose, signals read, guardrail checks, confidence, and what happens next. Here the requester asked for Full, but their work is reviewing and commenting, so the agent approves Collab for a quarter of the price and says why. Appeal to an admin and Talk to a human are one click away.

Explain every decision

08

Ticket review

When the agent cannot act alone, the admin gets the decision prepared. This department has no Full seats left, so the agent recommends reclaiming an idle seat and approving, with the checks that failed and passed. The admin accepts in one click, or takes over and the agent stops.

Prepared, not automatic

Acting smart

What happens when the same person comes back

A good admin remembers who asked for what last week. So does the agent: before it decides, it checks the last 7 days of that person’s requests and what they did with the last grant. Repeat requests are handled with judgment, not a fresh start.

Same person, within 7 days	Agent behavior	Why
Asks for more AI credits and used 80% or more of the last grant	Approves a bounded +1,000 top-up until the pool resets, and lists it in the admin digest	Real demand, small and capped, cheap to reverse
Asks for more and used under 50%	Asks what changed, puts the request on hold, and re-checks in 3 days	Usage does not support the ask yet; the hold is visible to the requester
Asks for more and used 50–80%	Holds the request and re-checks as usage grows	Not clearly needed, not clearly wasteful
Third request in 7 days	Sends to a person with the full history attached	A pattern needs judgment, not another automatic yes
Asks for Full again after being right-sized to Collab	Sends to an admin with both requests side by side	The agent does not silently argue with itself, and the person may have a real need it missed

Every hold tells the requester what is happening and when it will be re-checked. Nothing is silently ignored. You can try both credit cases in the prototype below.

Guardrails and ways out

Designed to be overridden

If I were governing this app, the first question would be what happens when the agent is wrong, or when a person simply wants to finish the task without it. So the way out is designed before the way in. Limits live in a policy layer the model cannot edit, approvals can be undone for 24 hours, and three undone approvals drop the agent back to Suggest.

The alternative route: bypassing the AI

Anyone can step around the agent at any point, and every bypass is logged and shown to the admin.

Who	Escape route	What happens
Requester	Skip the agent	Ticked on the form. The ticket goes straight to an admin with a prepared summary
Requester	Stop and ask a human	Available at any point in the conversation
Requester	Appeal an outcome	Available after any decision. Access stays in place while an admin decides
Requester	Mark it urgent	Top of the admin queue, with a 4 hour target
Admin	Take over a ticket	The agent stops acting on it
Admin	Undo an approval	Reverses it within 24 hours and counts toward the circuit breaker
Admin	Pause the agent	Kill switch. Everything goes to admins until it is switched back on
System	Circuit breaker	Three undone approvals drop the agent to Suggest by itself

13

Autonomy and guardrails

The admin control room. Suggest, Ask or Act for each job, the limits, the rules that always go to a human, the 7 day memory, a dry run of this week’s tickets, and every escape route in one place. Nothing here needs a developer.

Autonomy set by admins

12

Agent activity

The audit trail. Every action shows what happened, on which ticket, with what confidence, and by whom. Admins can undo an approval or give it a thumbs up or down, and agreement with the agent becomes the metric that decides whether it earns more autonomy.

Show the work, invite correction

14

Impact

The operating model in the product. Sliders for volume, time, cost and the share the agent resolves, with the saving updating as they move. The resolved share comes from the dry run of the current guardrails, so loosening a limit shows its effect on admin time before it is made.

Make the value visible

04 Experience

Test the agent

Pick a scenario to send a new request through the agent, or use the tabs and the bottom bar to explore as a requester, an admin and the person who governs the agent. Change the mode in Guardrails and watch the outcomes change. “Reset demo” starts over.

Enterprise Tool Governance prototype Open full screen ↗

The prototype is a desktop-sized app, so it opens best in its own tab.

Open the prototype ↗

How I got here

The design process, in one document

This page shows the problem, the impact, the product and the experience. The thinking behind them is in a 21-slide presentation: discovery, research materials, personas, journey maps, ideas, user flows and a validation plan.

Discover
Research materials
Personas
Journey maps
Ideas
User flows
Screens, annotated
Validation plan

View the design process 21 slides view only

Want to talk through the work?

I'm happy to walk through the thinking behind this, or my enterprise projects, in more detail.

Get in touch All case studies