An agent is not a chatbot with a few extra permissions. It is a product system that observes context, makes a judgement and decides whether to act.
Start with the job, not the prompt
Before deciding what the agent should say, write down what the person is trying to achieve. ‘Answer questions’ is too vague. ‘Protect an arrival goal when the commute changes’ gives the system something it can reason about.
A useful goal gives you a test for every later decision: does this action help the person, or is the agent just being busy?
Give it context — and uncertainty
An agent needs the small set of signals that change the job: state, timing, constraints, history and permissions. Make that context explicit before designing the interface.
A confident answer built on missing context is worse than a short explanation of what the system does not know.
Design the decision boundary
Most behaviour falls into three useful states.
- Stay quiet when nothing changed enough to interrupt.
- Prepare by gathering context or drafting a reversible next step.
- Ask when a consequential action needs attention, consent or choice.
Test the awkward cases first
Happy paths make agents look smarter than they are. Start with stale data, conflicting goals, missing permissions, a person changing their mind and a recommendation arriving too late.
A small coded model often reveals another state or human hand-off before the interface needs more polish.
What you can reuse.
Not just a conclusion: these are the working artefacts behind the argument. Open them, question them and adapt what is useful.
Decision model
The visible product surface for observing, interpreting and choosing whether to act.
Inspect the agent UIServer boundary
The route that keeps model access and product context outside the browser.
Inspect the API routeTry the behaviour
Use the agent in the portfolio and question the decisions behind the work.
Open the agent