Most AI projects fail at the handover, not the model.
TL;DR. Where does the agent act? What does the human see? When does it escalate? What gets logged? We design the interfaces between agent, human and system — UI, approval flows, escalation logic, telemetry — and hand you an operating manual your team can run.
What this is about
The model is rarely the problem. The failure happens at the seam: nobody decided where the agent acts autonomously, where a human approves, when it escalates, and what gets recorded. So either the agent does too much and nobody trusts it, or it does too little and nobody uses it. We design that seam deliberately.
How we run it
We start with a one-day discovery: the process, the actors, the risk points. Then we design — agent/human/system process diagrams, UI mockups for the approval and escalation screens, policy definitions in code (not Word), a telemetry specification (what is logged, where it lives, who can read it), and an operating manual that tells your team what to do when. The output is buildable: your developers or ours can implement directly from it.
When it fits
Organisations that have a model working in a notebook but can't put it in front of users safely. Teams introducing agents into a regulated process where "who approved this" must be answerable. Anyone whose last AI pilot stalled because nobody trusted the output.
What we don't do
We don't deliver Figma files with no logic behind them. We don't hand-wave the escalation path. Policies come as code, the telemetry spec is concrete, and the operating manual is specific enough to run a shift from.
What you can hand off
-
Process diagrams
Agent / human / system — who does what, where the approval gates sit, where it escalates.
-
UI mockups
The approval and escalation screens, designed for the people who actually staff them.
-
Policy definitions in code
Escalation and permission rules as code, not prose. Diffable, auditable.
-
Telemetry specification
What is logged, where it lives, who can read it. The basis for audit and trust.
-
Operating manual
What the human does, when. Specific enough to run a shift from and hand to a new hire.
Engagement facts
| Discovery | 1-day workshop · process, actors, risk points |
|---|---|
| Design project | Typically 4–8 weeks |
| Output | Diagrams, mockups, policy-as-code, telemetry spec, operating manual |
| Buildable by | Your developers or ours — implementation-ready |
| Deployment-agnostic | Works for cloud, on-prem and air-gapped operation |
Asked before the briefing
-
Is this just UX design?
No. UX is one output. The core is the decision architecture: where the agent acts, where the human approves, when it escalates, what is logged. Policies come as code. -
Do you build it too?
We can, or your team can — the deliverables are implementation-ready. Many clients design with us and build in-house. -
How does this connect to the rest of Nova9?
The escalation and permission policies plug into the LLM Gateway; the telemetry spec maps to Observability. Designed here, enforced there. -
What if our process changes later?
Because the rules are code, you change the policy, not the whole design. That's the point of policy-as-code.
Design the seam, then trust the system.
We turn a model that works in a notebook into a process people will actually run — with approval gates, escalation logic and an audit trail by design.