Connect
The proposed interface would list connected tools and the permission granted to each. Here, the input is a fictional event list.
sample input: 3 fictional events [ AUTONOMOUS-AGENT INTERFACE STUDY · SIMULATED ]
The nervous system
for your software.
AXON explores how an automation product could present sensing, planning, guarded action, and a full reasoning trace. This is a design showcase, not a live agent service.
- STATUS
- CONCEPT
- TRACE
- SIMULATED
- BACKEND
- NOT CONNECTED
INTERFACE/ ANIMATION/ INTERACTION/ FIELD NOTES/ SIMULATED TRACE/ DESIGN TARGETS/
[ SIG.01 · SPEC ]
Read the design, line by line.
These are proposed capabilities and interface requirements. Each row identifies what the study depicts; the page does not execute agent tasks.
PARAMETER SPECIFICATION STATUS
Reasoning core A proposed planner would break a goal into steps and show why a path was selected. This page uses an authored example. CONCEPT
Connectors The interface models a connector catalog; no production connector library is delivered by this showcase. CONCEPT
Orchestration A visual model for routing, retries, and hand-offs. The latency language is a design target, not a measured service result. TARGET
Guardrails The design requires scoped permissions, human approval and an audit record. The sample shows a refusal; no live policy engine is connected. PROPOSED
Memory A proposed run history would preserve approved context and outcomes. This showcase stores no agent memory. CONCEPT
Observability An example event log makes inputs, proposed actions, policy checks and outcomes visible. It is scripted, not a model's internal reasoning. SAMPLE
[ SIG.02 · PROC ]
A proposed workflow, from input to review.
DRAG / SCROLL →Reason
The sample turns a payment-review goal into a visible proposal. Its steps are authored for this study, not generated by an agent.
sample goal: review failed payments Check authority
The example stops at a human approval gate. A proposed payment retry remains blocked, making the missing permission visible.
sample state: approval required Observe
The sample log records the proposal and its refusal. No payment is retried, no account is connected, and no money is recovered.
sample outcome: no action executed [ SIG.03 · CORE ]
Three design questions at the core.
Can an operator inspect the plan?
The concept separates the goal, proposed steps and expected outcome. An operator should be able to inspect that proposal before authorizing a consequential action. The planner visualization is illustrative.
Where does the time budget go?
The sub-40ms hand-off is a hypothetical budget for one orchestration step, not a measured result or an end-to-end agent response time. The latency note separates local routing, network waits and external execution.
Can someone explain the outcome?
A useful audit record would identify the actor, proposed action, policy decision and observed result. This study shows the shape of that record; tamper resistance, storage and enforcement would need a real backend.
1 [ INTERACTIVE CONCEPT ]
4 [ LOOP STAGES ]
3 [ DESIGN NOTES ]
0 [ CONNECTED SERVICES ]
[ SIG.05 · TRACE ]
Follow a scripted refusal.
This authored sample shows a payment retry stopping at an approval gate. The animation replays text stored in this page. No model, payment system or policy service is called.
Read the complete sample
- sample: 3 fictional payment events; no connected account.
- sense: read the example event list.
- plan: classify failures; propose a retry for review.
- policy: payment writes require explicit human approval.
- blocked: approval missing; proposed retry does not execute.
- observe: record the proposal and refusal in the sample log.
- end: demonstration complete; no tools called or money moved.
[ SIG.06 · DISCLOSURE ]
A convincing interface is not evidence of a deployed service. AXON is published as a transparent design study so the interaction model can be evaluated without pretending the underlying product exists.
[ SIG.07 · THE WRITE-UP ]
Everything behind this study is written down.
AXON is a design exploration, so the reasoning matters more than the artefact. These are the notes that came out of building it — how the interface was argued into shape, why the guardrail is the centrepiece, and what the latency budget did to the design. All public, no account, no paywall.
The design problem
[ 00 ]Why a chat box is the wrong shape for an agent that holds real authority, and what an operator needs to see instead.
- Sense, plan, act, audit as a visible spine
- Labelling illustrative elements honestly
- What got cut and why
Guardrails and audit
[ 01 ]The moment an agent declines is more informative than the moment it succeeds. Designing for refusal, and for the trace you hand to somebody else.
- Guardrails as a feature, not compliance
- Why automation needs an audit trail
- Making refusal legible
The latency budget
[ 02 ]Build a hypothetical 40ms allocation, distinguish orchestration from external work, and plan the measurements a real implementation would need.
- Measuring before optimising
- Where the budget gets spent
- Design consequences of the number
[ SIG.08 · CONTEXT ]
Study the interface.
Read how it was made.
AXON is a product-design exploration, not a service waiting list. Nothing here is for sale; the engineering notes are public and free to read.