The team explored a new capability while learning its behaviour in practice.
Engineering streamed the agent’s activity; I shaped what became visible in the UI.
How much of an autonomous process should a user see and control?
We were learning what an agent was while designing for one.
As agents first entered Fergus, our team moved quickly to understand what they could contribute to consultants’ work. This was not a settled interaction pattern with a ready-made interface. We were investigating the technology, its behaviour and its limits while the product was taking shape.
My role was to learn alongside engineers and other teammates, then turn that learning into an interaction users could follow. The process was highly iterative: as the agent’s behaviour became clearer, we revised what the interface should reveal and how it should explain the work.
The event stream was technical. The UI needed to speak for the user.
An engineer gave me the streaming events emitted while the agent worked. They described what the system was doing, but they were not yet an experience a consultant could make sense of. I mapped those events into categories and subcategories, then defined which actions deserved a visible step, which belonged inside an expandable detail and which should not interrupt the user at all.
For each visible action, I considered the icon, status and wording. The label needed to answer a user question, such as what the agent was trying to find or why it needed input, rather than repeat a technical event name. The same logic had to work during the live stream and after the task was complete.
Streaming events
A changing sequence of system actions, progress states and results.
Classify and decide
Group related actions; choose category, subcategory, language, icon and visibility rule.
WHAT DOES THIS MEAN TO THE USER?Readable progress
A concise account of what is happening, with detail available when it helps.
Categories
Turn individual events into a smaller set of meaningful actions and subactions.
User wording
Describe the purpose of an action in terms a consultant can understand.
Icons and states
Use a consistent visual cue for the kind of work and its current state.
Visibility
Decide what appears now, what expands and what remains after completion.
What helps during the work may differ from what matters afterward.
Live progress can reassure users that the agent is moving forward. A finished task needs a different hierarchy: the answer should be easy to use, while consequential actions, open questions and supporting evidence remain findable. I worked through which steps could collapse, which details should be available on demand and which moments should stay visible.
Show enough to orient
- What the agent is working on
- Progress and changes of state
- A clear request when the user needs to act
Keep what supports judgment
- The outcome and relevant evidence
- Decisions or actions worth reviewing
- Unresolved issues and ways to correct course
The prototype also revealed a practical UI issue: interleaving animated steps with answer text made selection and copying unreliable. I separated the process display from the final answer in the interface structure so the explanation remained readable and the answer remained usable.
The interface made us ask who is in control.
The visual design exposed deeper product questions. Should users choose the agents involved, or should an orchestrator assemble the right workflow? When should the system ask before acting? How much should it show about its process without creating noise or implying certainty it does not have?
Choice
Where does user selection add control, and where does it add setup work?
Transparency
Which steps help users understand the result, and which are only system activity?
Accountability
What must remain visible so users can review or correct an agent’s action?
These were ongoing design questions, not a claim that a single interface settled the ethics of automation. They shaped how we discussed agent behaviour as a team and how I translated it into UI rules.
Designing for new technology means learning with the system.
I developed an interaction model, prototypes and behavioural guidance from the real event stream, refining them with teammates as we learned what the technology could do. The work required UI craft at the level of wording, icons, hierarchy and component behaviour, alongside product judgment about visibility and control.
An agent’s activity only becomes useful to the user when the interface explains what matters, at the moment it matters.