UX CASE STUDY · AI SYSTEMS · 2026, ongoing

An AI agent that runs itself, without running off.

AXOS plans work, writes code, drafts my outreach, and reports back on its own. Every risky move runs through a governor I designed: a budget breaker, a safety guard, and a review queue where I stay in the loop. The brief was simple to say and hard to build: make an agent I can hand real work to and still trust with my repos and my money.

SPEC · AAO001
Role
Design, Build & Ship (Solo)
Timeline
2026, ongoing
Stack
React · FastAPI · Python · SQLite · Ollama · Claude Code
Constraint
TRUSTED WITH REPOS AND MONEY
AFTER vs BEFORE →
MY ROLE002

I designed it, built it, and shipped it: the React dashboard, the FastAPI backend, the three-tier routing, and the governor itself. The design goes all the way down, and I wrote the code that backs it.

Team
Solo (1 person)
Stakeholders
Me, as its daily operator
FIG. 012026, ongoing
PROBLEM → SOLUTION003

The Problem vs. The Solution

Most AI agents land in one of two piles. Either it's a chat box that forgets everything the moment you close it, or it's a script running with permissions skipped that you quietly pray won't delete your home folder. I wanted the thing in the middle: something that could actually do the work but that I could leave alone with a codebase and a weekly budget. That turned out to be a design problem more than an engineering one.

BEFORE003.A

The trust problem

Trust in an autonomous system comes down to three things: what it shows you, what it asks before it acts, and what it physically cannot do. Those are interface decisions. I wrote the constraints down before I built anything, and they shaped every screen.

P-01
It can't quietly burn moneyLLM calls cost real dollars, so spend has to be visible and capped. An agent that can spend invisibly is a liability, not a tool.
P-02
It can't wreck files it doesn't ownAn agent with write access must be physically unable to destroy work it didn't create. Warnings aren't enough.
P-03
It can't guess at forksWhen it hits a real decision point, it has to ask instead of picking a lane and hoping. And I need to see what it's doing at a glance, and kill it mid-run.
AFTER003.B

The governor

The home screen is a dashboard, not a chat window. The governor is on the wall: budget as a percentage of the weekly cap, breaker status, live system vitals, and the one toggle that actually matters, SUPERVISED versus AUTO.

S-01
Budget on the wallThe weekly budget reads as a percentage, mapping directly to the number the breaker trips on. 15% used reads faster than $41.20.
S-02
Every run in a ledgerSONAR logs and costs every run: runs by tier, budget by model, a 14-day trend. A probabilistic system earns trust by being auditable.
S-03
Suggests, never sendsThe weekday brief is built from my real context and project registry. Nothing auto-sends; anything it wants to act on goes through an editable draft queue.
THE IMPACT004

The Impact

It's shipped, governed, and running my week. These numbers are the shape of the system rather than a launch metric: the discipline is the deliverable.

One visual system
0 views
Masthead-as-nav, shared footer, one type system
Cost routing
0 tiers
Free local check, small gate model, Claude for the real work
Reversible in AUTO
0%
Autonomous runs only touch git repositories
KEY DECISIONS005

Key Design Decisions

Trust is built screen by screen. These five calls shaped the product, each one made against a constraint I'd written down before building.

DEC-01
Two names, two jobs

AXOS is the platform; OrcA is the agent you talk to. The giant wordmark is the system nameplate, the persona is in the masthead, and every reply is signed by it.

Why

Splitting the two kept the interface honest. You're addressing an agent that lives inside a system, the way Siri lives inside iOS. The orca-pod metaphor (projects are pods, the task board is the hunt, analytics is sonar) gives a dry ops tool personality without turning decorative.

DEC-02
Put the governor on the wall

Front and center on the home screen: the weekly budget as a percentage, breaker status, live system vitals, and the SUPERVISED/AUTO toggle. Flip AUTO on and the header switches to HANDS OFF.

Why

The scariest part of an autonomous agent is not knowing what it's spending or whether it's about to go sideways. Moving budget from dollars to a percentage was deliberate: it maps directly to the number the breaker actually trips on, and there's no ambiguity about what mode you left it in.

DEC-03
Show the work, always

Every run lands in a costed ledger, and SONAR turns that into plain analytics. AXOS routes each task to the cheapest tier that can handle it, and the breakdown makes that visible.

Why

The charts aren't the point. The point is that a probabilistic system earns trust by being auditable. Most tasks never reach the expensive tier, and when OrcA spends, I know where it went.

DEC-04
Keep a human in the loop

AXOS suggests; I decide. Every weekday it drops a grounded to-do list built from my real context. Nothing auto-sends, drafts are editable, and a genuine fork parks the task and asks.

Why

Starting a conversation opens a real chat window instead of firing the task off silently, so I can watch the answer land and steer from there. Asking beats guessing.

DEC-05
Safety as a design material

The agent can read across my drives but physically cannot delete anything it didn't create without my go-ahead. Autonomous file-writing runs only touch git repositories and only run with AUTO on.

Why

Every change is reversible with one command, and the rule rides along in every single run. I built the guardrails as defaults instead of warnings: the safest path is the one it's already standing on.

OLD vs NEW WORKFLOW006

Handing work to an agent, both ways

The operator's side of the loop. The old flow is every agent setup I tried before building this; the new one is my actual morning.

OLD WORKFLOW · UNGOVERNED006.A
  1. 01Re-explain the whole context in a fresh chat box
  2. 02Copy anything useful out by hand before the tab dies
  3. 03Babysit any script that has write access
  4. 04Reconstruct after the fact what it did and what it cost
  5. 05Start over from zero tomorrow
NEW WORKFLOW · GOVERNED006.B
  1. 01Read the weekday brief, grounded in my real projects
  2. 02Edit what's worth doing, approve it into the queue
  3. 03Watch the run land, costed, in the ledger
5 STEPS → 3 STEPS · −40% · UNGOVERNED → GOVERNED
DESIGN PROCESS008

Design Process

Constraints first, screens second. I wrote down what the agent must never do before designing what it would show, then built front to back and fixed the problems only shipping reveals.

01
CONSTRAIN
  • Wrote the hard constraints before any screen
  • Named the trust problem: visibility, consent, hard limits
  • Split the platform (AXOS) from the persona (OrcA)
02
DESIGN
  • Dashboard-first home screen, not a chat window
  • Orca-pod metaphor across all six views
  • One visual system: big Archivo type, one hot magenta, mono labels
03
BUILD
  • React, FastAPI, and SQLite, front to back
  • Three-tier routing: free local check, small gate model, Claude for the real work
  • Guardrails built as defaults instead of warnings
04
LIVE-FIX
  • Shipped it, then lived in it daily
  • Fixed the silent launcher, the flashing consoles, the truncated replies
  • Lifted chat into a stable window after feeling the board jump
REFLECTION009
The part that isn't in a Figma file

I built the whole thing front to back, and the hard problems were the ones you only find by shipping. The desktop launcher looked finished but opened nothing: it ran the server headless, which tripped a logging call before the port could bind. Console windows flashed every few seconds until I traced them to the dashboard's own background checks. Chat replies were dying mid-sentence because an old preview truncation had quietly become the only copy being saved. And the chat card jumped between board columns as its status changed, so I lifted the conversation into a stable window that stays put while the card moves behind it. None of that shows up in a static file; all of it decides whether a person keeps using the tool the next day. What's next: a real small-screen pass, keyboard navigation and screen-reader labels verified to WCAG AA rather than assumed, and deeper repo access for plain chat. The brief was vague and slightly nervous, a trustworthy autonomous agent. It's now legible, governed, reversible, and running, and I wrote the code that backs it. If you want to see it move, I can walk you through a live run.

Available for Work

Let's build something impactful.

I'm currently open to new opportunities in UX/UI Design, Product Design, and GovTech transformation roles.