Overwatch
Overwatch is a control room for AI agents that can touch money and customer records. An agent proposes an action, a policy decides who must approve it, and a person sees the evidence and the cost before anything happens. I designed it and built it with AI-assisted development, and I am still improving it.
Role
Product designer and builder
Type
0-1 product, self-started
Users
Finance, operations, platform and audit teams
Platform
Web application
Status
Active product initiative. I am continuing to test, document and develop Overwatch as I explore how the control model could work with real enterprise systems.
Data
Made-up billing scenarios. The audit history is stored for real
Outcome
A high-risk AI action can no longer be approved by the wrong person, run twice, or go ahead on missing evidence. Tested through role-based scenarios, fixed, then tested again. Not yet tested with outside users
Summary
Overwatch is a control room for AI agents that can touch money and customer records. An agent proposes an action, a policy decides who must approve it, and a person sees the evidence and the cost before anything happens. I designed it and built it with AI-assisted development, and I am still improving it.
The problem
Companies are starting to let AI agents act, not just answer. An agent can issue a refund, cancel a contract or change a customer record across several systems at once. Most agent tools are built around chat and background automation. That is fine while the stakes are low. It breaks when one wrong action costs real money.
The teams who own those actions need answers before they click approve:
- What is the agent proposing, and why?
- What proof supports it, and what proof is missing?
- Which rule applies, and who is allowed to decide?
- Which systems will change, and what happens if one update fails?
- Could the same action run twice?
The question I set out to answer: how can the right people understand and control what an AI agent is about to do, without having to watch everything it does?
I chose to design the layer after the agent proposes an action. Tools that watch prompts and model traces already exist. The gap I saw is the business side: authority, evidence, money and recovery.
My role
I did this work on my own, from the first idea to the live product. I started on 1 September 2026 and spent the first week on research. There was no client, so every decision below is mine.
- Product thinking. I framed the problem around human control of risky AI actions, and chose the four roles and what each one may do.
- Design. I designed the journeys for review, policy, execution, recovery and audit.
- Build. I built the working prototype with AI-assisted development. I wrote the product rules and checked every result myself, in the live product.
- Testing. I set up the role-based test scenarios and chose the testers, turned each failure into a product change, and had the same scenarios run again.
- Honesty. I wrote down what is real, what is simulated, and how the product would connect to a real client.
How it works
Every action follows the same path, and the AI is only the first step.
Overwatch control flow and roles
The agent proposes. A fixed policy rule decides who must approve. A person with the right role reviews the evidence and cost. Approved work runs once and is recorded. If a step fails, only the AI Platform Admin can recover it.
Four decisions that shaped the product
The AI advises. It never holds the authority.
The agent gives a proposal, its reasoning and a confidence level. A fixed policy rule decides who must approve, and a server-side check decides whether that person is allowed to. The model cannot give itself permission.
Why: an AI that sounds sure while the evidence is weak is the main risk. Rules that a person can read and name are easier to trust, to audit and to explain to a finance director than model logic hidden in a prompt.
Restricted actions look restricted before anyone clicks.
In my first version, an auditor could press Approve and only then be told no. Now the Approve, Reject, Pause and Recover controls are switched off for roles that may not use them, and each one says which role is needed.
Why: a permission error after a click is a late warning. The interface should stop the mistake before it starts, and it should teach people who holds the authority.
Missing evidence stays missing until a source answers.
Originally, pressing Request evidence raised the confidence score straight away, as if the proof had arrived. I split it into two states: evidence requested, and evidence received. The action stays blocked at 74% confidence. When the source responds, a new evidence record appears and confidence rises to 86%.
Why: the screen must never suggest that proof exists when it does not. Reviewers decide on what they see.
Show the cost first, and make a final decision final.
A high-value approval used to run after a single click. Now the €8,400 approval opens a dialog that names the amount and the three systems it will change: the payment processor, the customer record and the internal ledger. After approval the buttons disappear, and the execution monitor shows one record with one idempotency key (a unique ID for that run), so the same action cannot run twice.
Why: "Are you sure?" tells people nothing. Naming the money and the systems lets them decide with open eyes, and a duplicate payment is a real loss, not a design flaw.
Testing it, breaking it, fixing it
Friends and colleagues tested the live product through five roles. Each person acted as one persona with a clear job and a permission limit, and I chose people who work in those domains: Finance Approver, Operations Reviewer, AI Platform Admin, Compliance Auditor and a skeptical Finance Director. Every place the product let them down became a fix, and the same journeys were then run again on the fixed version.
This was role-play by a small, friendly group with the right backgrounds, not research with real customers. It found real design failures, but it does not prove the product works for outside users. I say that plainly in the case study because a reader who knows the difference will trust the rest more.
| Role | What went wrong | What I changed | Result on the second run |
|---|---|---|---|
| Finance Approver | Expired approvals looked like normal pending work | Expired work goes first, is labelled, and is blocked until reassigned | Approval was blocked. Reassigning opened a new decision window |
| Finance Approver | Requesting evidence instantly marked it as verified | Request and receipt became two separate states | Confidence stayed at 74% until the source responded, then rose to 86% |
| Operations Reviewer | Anyone could retry or roll back a failed execution | Recovery limited to the AI Platform Admin, with the reason shown | Both buttons were switched off and explained |
| AI Platform Admin | Pausing an agent was instant and left no record | Added an impact warning and an audit entry | The audit log showed who paused it, their role and the time |
| Compliance Auditor | Decision buttons looked usable and failed after a click | Buttons switched off in read-only mode | The auditor could inspect and export, and nothing else |
| Finance Director | The overview showed counts but no money | Added value awaiting review and value protected | Overview showed €15,650 awaiting review, labelled as made-up data |
| Finance Director | The same €8,400 action could run twice | Final-state controls and one idempotency key per execution | Exactly one execution record after approval |
One more bug found on the second run. At a laptop-sized window, the review panel ran past the edge and cut off the right side. I changed the layout so the sidebar folds earlier and the panel can shrink.
Cleaning the evidence. My early tests left duplicate audit entries and an old test name in the live history. I removed them with a controlled database change, so the audit history now shows only the real test journey.
The final product
Five views carry the story. Each one is shown with the claim it proves.
- Executive overview. Leaders see money at risk, not just counts: €15,650 awaiting review, actions held back by controls, and work that needs recovery. Everything is labelled as made-up data.
- Guarded action review. One view holds the value, the proposing agent, the policy, the affected systems, the evidence and the approval rules. When an approval has expired, the view says so and offers reassignment instead of a quiet approve button.
- Execution and recovery. A finished three-system update looks different from one that failed on its last system. The failed system is named, and only the AI Platform Admin can retry or roll back.
- Policy governance. Every rule has a name, a version, an owner and a recent match count. In this version policies are read-only, so the product does not pretend to let you edit what it cannot.
- Audit history. Each decision keeps its event, action, actor, role, time and context, and can be filtered and exported as a CSV file.
1 / 5
What is real, what is simulated
The live product is a working simulation. I made that choice on purpose, so I could test the control logic without client data and without claiming connections I have not built.
Real today
- Role switching that changes which controls a person can use
- Approval guards, evidence states, confirmation dialogs and final-state behaviour
- Execution monitoring and recovery limits by role
- An audit history saved in a deployed database, with filters and CSV export
- A responsive layout that I tested again after fixing it
Simulated
- Customers, amounts, agents, policies and evidence
- The systems an approved action would change
- Confidence scores and agent health numbers
Not built yet
- Sign-in and server-side role checks
- Connections to a real CRM or billing system
- Document upload
- A real AI model call
- Separation of one client's data from another's
How it would work with a real client
In short: the client's systems send Overwatch the actions their AI agents propose, Overwatch routes each one to the right person, and after approval it updates the client's system once and records everything.
A client's data would reach Overwatch in one of four ways: a connection to their system's API, a signed event sent when something happens, a scheduled check for new records, or a secure file upload. Each record would be checked, matched to the right client, and turned into the same action format, so the review view works the same for every client.
After a person approves, a server-side connector would update the client's system once, using the unique ID that stops duplicates. Every step would report back. If one system fails after others succeed, an administrator could retry only the failed step or undo the finished ones.
The AI would help with reading, not deciding. It would summarise evidence, point out conflicts and suggest a risk level in a fixed format, with links back to the source. If the model fails, the action stays visible with its source data and policy result. It never gets approved by default.
Ongoing product development
Overwatch is an evolving product initiative, not a finished concept made only for this case study. I keep testing the workflows, reviewing how different roles use the system, writing down weaknesses and improving the product as new questions come up.
The current release sets up the control model: policy-based routing, human approval, evidence review, permission boundaries, execution monitoring and audit history. The next rounds will explore real-system connections, secure document upload, server-side access control and structured AI analysis with source citations.
I treat each phase as product work: define the problem, build the smallest useful version, test it through specific roles, write down what failed, make the changes, and repeat the same journeys to check the result.
What I learned and what is next
What I learned
- The hard part of AI product design is not the chat or the dashboard. It is the moments when something is unclear, late, blocked or broken, and a person must still act safely.
- Showing a limit before someone hits it is better design than explaining it after.
- A project is more believable when it states what it cannot prove. Labelling the data as made-up cost me nothing and made the rest easier to trust.
What is next
- Test with real people. I wrote a test script for five people close to these roles: a finance approver, an operations lead, a platform administrator, an auditor and a product colleague. The goal is that four of five can say why an action stopped within 30 seconds, and that four of five can recover a failed update without help. I will report what happens, whether it flatters the product or not.
- Make the data real. Move actions, policies and executions into the database, add sign-in, and check roles on the server instead of in the interface.
- Connect one system. Add one read-only connection using sandbox data, then one write connection with duplicate protection.
- Add evidence from documents. Upload a policy or a statement, and show the AI's claims with links to the exact passage.
- Run a small pilot. Pick one workflow, such as high-value refunds, and measure review time, mistakes blocked and recovery time. I will not claim any business result until a pilot produces one.
