Overview

An agent that works with engineers, not around them

ActionEngine is an agentic system that operates across browser and terminal environments, bringing together multiple agents for planning, contextual understanding, and performance evaluation. It collaborates with engineers by observing and learning from their actions, then creates reusable workflows to automate those tasks.

The core design challenge was not the architecture; it was the collaboration model. How does an agent integrate into an engineer's existing workflow without disrupting it? How does it earn trust incrementally, stay visible, and remain correctable at every step?

Rather than treating the agent as a standalone tool, we approached it as an extension of developer intent: something that acts in alignment with user goals, not one that requires explicit instruction at every turn.

Flow 01

The agent watches and learns

Training starts with the engineer doing, not describing. As they work, the agent observes each action in real time and surfaces it inline within the conversational UI as a discrete, labelled step. There is no separate recording panel or background process. Every step appears as it is captured, giving the engineer a continuous view of what the agent is building and the ability to flag or correct anything before it becomes part of the workflow.

Each action is captured and surfaced inline as the engineer demonstrates the task

Flow 02

The agent asks when it does not know

When the agent hits a point it cannot resolve from observation alone, it does not guess and continue. It stops, surfaces the ambiguity as a direct question, and waits for the engineer to respond. This was one of the most deliberate design decisions in ActionEngine. Silent assumptions compound quietly. An agent that admits uncertainty turns a potential error into a collaborative moment, and keeps the engineer meaningfully in the loop rather than just nominally so.

The agent pauses mid-training and surfaces a specific question before continuing

Flow 03

Review before anything runs

Once training is complete, the agent does not execute immediately. It presents the full workflow as a structured, editable draft and asks for approval. Every step is visible and can be modified, reordered, or removed. Only once the engineer signs off does automation begin. This is where intent is confirmed, not assumed. The workflow is not handed off; it is co-signed.

The agent presents a full structured draft; the engineer edits a step before approving execution

Outcome

Automation that stays transparent and aligned with human intent

With ActionEngine, the goal was to design an agentic system that automates engineering workflows while keeping humans genuinely in control, not as a formality, but as a structural property of how the system works.

The agent works collaboratively: staying visible while learning, surfacing uncertainty rather than guessing, and treating every workflow as a shared artefact before handing it off to execution. The result is automation that engineers can trust, not because it is infallible, but because it is legible, correctable, and designed to ask for help when it needs it.

Design Framework

Grounded in HAX: how the principles showed up in practice

ActionEngine was built in parallel with the HAX framework, and every major design decision maps back to one of its five principles. The three flows above are where that grounding became concrete.

Impact

The numbers

Overview

A low-code tool for supply chain applications

Quantum Studio is GEP's low-code platform used to create supply chain and procurement applications from scratch or using templates. It features data modeling, a UI Designer, and automation capabilities. The platform is used by three personas: developers who build from scratch, admins who customize applications for specific clients, and partners involved in onboarding and implementation.

The three main goals of Quantum Studio are to ship applications faster, empower admins and partners to configure without developer help, and increase developer efficiency.

The Problem

Version 1 didn't move the needle

After launching the first version of the tool, there was no significant reduction in the changes clients needed to make. Admin and partner teams were constantly reaching out to internal product and development teams to make changes or update their applications. This meant developer bandwidth was consumed by redundant tasks, and deployment time remained at 4–5 months. Our goal was to bring it down to 2 weeks.

Objective

Clear goals, measurable targets

Going into this project the objective was clear. We needed to reduce deployment time from 4–5 months to 1 week, and bring down the number of Jira support tickets by 70%+ by the end of the year. To get there, we first needed to understand how all three personas actually created applications.

Users

Two very different users, one shared platform

The platform served two primary personas with fundamentally different needs. Developers are technical users who create applications from scratch, develop reusable plugins, and need advanced development features. Admins are non-technical users who customize applications for specific clients, are involved in onboarding and implementation, and need to preview and deploy in real time. Designing the same features for users with varying levels of technical expertise required careful consideration at every step.

Research

Understanding where the user flow broke down

To reach our goal, we needed to understand how all three personas created applications. We mapped out the user flow for application creation and tested each flow to identify what was not working. We analyzed customer pain points, exits, and needs, then mapped all problem areas against product features using affinity mapping.

User testing: prioritization and affinity mapping

Growing Pains

Config Panels: 36 panels, two big problems

As the platform grew, two major problems surfaced in the configuration panels, which spanned 36 panels across the application. First, lack of personalization: there was no customization based on persona type, meaning the same advanced features seen by developers were also shown to admin users, creating cognitive overload. Second, lack of standardization: information was not grouped into standard categories, making navigation inconsistent and unpredictable.

Problem 1: the config overlay hid the page, so users couldn't see changes in real time

Problem 2: to preview any change, users had to go back and forth with no undo

Design Process

New design principles for Config Panels

The insights from research gave us clear goals for improving the config panel experience. The new design was built around three principles: in-context editing instead of a slider with overlay, decluttering by removing unnecessary fields and customizing panels per persona, and grouping all fields into relevant standard categories.

Final Design: condition builder with natural language constructs + AI-generated logic

Redesigning the Expression Builder

Expression builders can be challenging to use due to their complexity in handling various data structures, logic operations, and user interfaces, often requiring users to possess deep programming knowledge. Our users were struggling with ours. The insight: condition-based expression builders are easier to understand because they allow users to construct logic by setting conditions and actions in a more intuitive manner, resembling natural language constructs. We redesigned to showcase this flow.

Variation 1: Expression Builder redesigned around condition-based logic flow

Learnings

What this project taught us

The GEP technical architecture heavily influenced how the low-code studio was designed. Designing identical features for user personas with varying levels of technical expertise requires careful consideration and planning.

Impact

The numbers

The Problem

Clients got lost every time they onboarded

Every new GEP client onboarding required setting up an organizational structure, uploading master data, defining rules and workflows, and configuring features across 20+ applications. The process was complex, unsequenced, and opaque. Client support and admin teams constantly needed hand-holding from GEP's product and engineering teams.

"What is the process to setup? There are so many options on the screen, where do I start?"

Research

Discovery workshop + validation interviews

Discovery Workshop

A 3-hour remote workshop with 20+ expert users surfaced four recurring patterns: no defined sequence for setup, invisible prerequisites and interdependencies, constant hand-holding required, and no way for new users to know where to start.

Heatmaps and behavioural data: 51% of users spent 43s on key tracked events; 40% struggled to find Setup Manager

Validation Interviews

Online focus groups and individual interviews with 15+ experienced internal team members confirmed the real setup sequence: always starting with organizational configuration, then per-application setup, with different go-live dates per app.

Application Wise Setup: the validated structure, organised the way clients actually go live

Design Process

From cluttered home screen to journey-based entry

Journey-Based Entry

When logging into a new domain for the first time, users choose their path: Guided Setup for new and novice users, or the familiar home screen for experienced users. This decluttered the home screen without removing any functionality.

"What is the process to setup? There are so many options on the screen, where do I start?"

Wireframe Variations

We tested two wireframe variations for the Guided Setup widget. Users preferred the version that gave an overview of progress upfront with a checklist aligning with their expectation of application-by-application go-lives.

Visual Design Concept 1: Guided Setup widget with progress tracking and per-application checklist

Visual Design Iterations

Early visual designs combined the Guided Setup widget with full home screen elements which overwhelmed users. We separated the experiences entirely, giving Guided Setup its own dedicated space.

Guided Setup Features

The final design includes progress tracking with per-application drill-down checklists, "Next recommended steps" surfaced contextually after each completed item, and prerequisites and interdependencies made visible inline alongside help content.

Final prototype: application-by-application progress, help centre integration, and recommended path

What Worked

Validated across new and experienced users

• Progress tracking and drill-down checklists per application were highly valued by all 12 test participants
• "Next recommended steps" after completing each item was appreciated across new and experienced users
• Separation of new vs. returning user journeys significantly reduced home screen clutter
• Users wanted to hide applications once setup was complete flagged for next iteration

Outcome

Setup time cut by 50%

Setup time reduced by up to 50%, with significantly less dependency on GEP support and engineering teams. Designs were validated across a mixed group of 12 new and experienced users before handoff to development.

Overview

Security AI is no longer just about detecting threats it's about making distributed reasoning understandable

Modern security systems are becoming increasingly autonomous and distributed. Multiple specialized agents observe activity, interpret signals, and build on each other's outputs. The challenge is no longer just detection accuracy it's making that distributed reasoning visible, traceable, and trustworthy to the analysts who depend on it.

This work explores how UX design can bring clarity, control, and transparency to complex multi-agent security environments applying the HAX framework through a structured model called the Visibility Funnel.

The Problem

Analysts can see what agents decided. They can't see why.

When multiple agents collaborate on a security finding, each contributes a fragment observing, interpreting, flagging. But their reasoning is often fragmented, insights can conflict or overlap, and there's no coherent picture of how a conclusion was formed.

Incidents view: analysts see fraud scores and confidence values, but no reasoning behind them

When something goes wrong, analysts can't tell which agent introduced the error, whether it propagated, or how to recover without losing context. Trust erodes and with it, the value of the system.

A New Paradigm

From observing actions → to understanding intent

Traditional security tools focus on what agents do their outputs and actions. Agentic Security introduces a different layer: analyzing reasoning instead of just outcomes.

Incident Report: the Detective Agent surfaces its reasoning, verdict, and compliance failures in a structured view

The Framework

The Visibility Funnel: transforming distributed activity into coherent narrative

The Visibility Funnel is a four-layer model that structures how multi-agent activity gets surfaced to analysts. Each layer builds on the one below from raw knowledge to actionable insight.

The Visibility Funnel: four layers from raw knowledge to observable UI, each building on the last

The Ecosystem

No single agent has the full picture value emerges from alignment

The system is built around a multi-agent ecosystem where each agent contributes a specialized perspective. Designing for this meant understanding not just what each agent does, but how their outputs relate to and depend on each other.

Knowledge Base graph: agent relationships, active incidents, and connected entities visualised together

Design Pattern

Proof Trees: letting analysts follow the thread of reasoning

In complex multi-agent systems, a single finding is rarely the product of one agent. It emerges from a chain, with one agent observing, another interpreting, a third validating. Without a way to navigate that chain, analysts are left with a conclusion and no path back to the reasoning that produced it.

Proof Trees are a UX pattern designed to solve exactly this. They expose the full decision chain, from the top-level verdict all the way down through each contributing agent, as a structured, navigable tree. Each node shows what the agent concluded, what evidence it used, and how confident it was. Analysts can expand any node to interrogate that step, drill into the evidence, or view the inter-agent discourse that shaped the decision.

Proof Tree: Detective Agent flags a fraud case. Expanding the tree reveals AgentAuditor's classification rationale and EvoGuard's fingerprint match, each step linked to its evidence.

The key design principle: the tree is not a log. It is a navigation structure. Every path through it answers a question an analyst would actually ask: "Which agent decided this?", "What evidence triggered that conclusion?", "Where did the reasoning diverge?" The Proof Tree makes those questions answerable without requiring analysts to switch context or reconstruct the chain manually.

This pattern applies wherever agents build on each other's outputs. In security it means tracing a fraud verdict back through fingerprint analysis and intent classification. More broadly it is the foundational affordance for any system where explainability must travel with the decision, not live on a separate page.

HAX Principles Applied

Trust by design the same principles, applied to security

Each HAX principle maps directly to a specific design challenge in multi-agent security systems.

HAX in practice: Clarity (Detective Agent's reasoning surfaced), Traceability (source attribution), Control (compliance flags with actionable states)

Portable Transparency

Agent reasoning that travels not just lives on one screen

One of the core design challenges was ensuring that the context, evidence, and reasoning behind a finding doesn't get lost as analysts move between views. Portable Transparency means agents carry consistent UI patterns across surfaces.

Agent Discourse: the conversation between AgentAuditor and Detective Agent, surfaced inline within the analyst view

Key Insights

What this work revealed about designing for multi-agent trust

• Visibility is the product in multi-agent systems, making reasoning visible is not a feature. It is the core value proposition.
• Structure reduces anxiety analysts working with complex agent ecosystems don't just need information. They need it organized in a way that mirrors how they think through a problem.
• Errors compound silently without visible reasoning, a single agent error can propagate through a system before anyone notices. Transparency is the only defense.
• Trust is earned incrementally the system needs to consistently behave as explained, surface what it got wrong, and give analysts a path to correct it without penalty.

Outcome

Transparency as the foundation of trust

The Visibility Funnel framework provides a reusable model for any domain where multi-agent reasoning needs to be surfaced to human decision-makers. Applied to security, it transforms distributed agent activity from a black box into a structured, navigable, and correctable investigation one where analysts remain genuinely in control.

The future of AI-powered security isn't just more accurate detection. It's detection that analysts can understand, verify, and trust.

The Problem

The app was outdated, incomplete, and blocking users from working on the go

The existing GEP mobile app had two compounding problems. First, it wasn't persona-specific it treated all users the same regardless of role, which meant the most frequent and high-value use cases weren't prioritised. Second, it had significant feature and visual gaps compared to the web experience, making it feel like a lesser alternative rather than a capable companion.

The most critical missing capability: users couldn't create a requisition from mobile at all. Anyone who needed to initiate a purchase while away from their desk had to wait until they were back slowing approval chains and creating frustration for clients who had specifically asked for this capability.

The existing app: no creation capability, role-unaware navigation, outdated visual language

Objective

Work on the go, without compromise

User Journeys

Mapping primary personas to understand the real usage landscape

Based on client needs and current usage data, we mapped the primary personas. This helped identify distinct flow needs across user types from approvers who primarily take action on existing documents, to requesters who need to initiate procurement workflows from scratch.

Three primary personas: Field Worker (create on the go), Manager (quick approve/reject), Executive (dashboard metrics)

Research

Competitive analysis revealed four features our app was missing

We analysed direct competitors to understand the landscape and identify gaps. Four patterns stood out as near-universal across other procurement mobile apps none of which were present in the existing GEP app.

Competitive landscape: SAP, Oracle, Coupa and others all offered capabilities missing from GEP mobile

Wireframing

Low-fidelity first establishing information architecture before visual direction

We started with wireframes to nail down the information architecture and test the structure before investing in high-fidelity design. The goal was to validate navigation patterns, action placement, and creation flow with real feedback.

Wireframes: home screen, creation entry, and form structure validated before visual direction

Testing Wireframes

Focus group with the internal solution design team surfaced three clear issues

We ran a focus group with GEP's internal solution design team the team responsible for working directly with clients and understanding their mobile needs. They gave us direct, specific feedback across three areas.

Visual Design

Key screens

With structure validated, we moved into high-fidelity design applying the updated GEP visual language and building out the full key-screen set for development handoff.

Key screens: home with pending tasks and role-aware navigation, catalog, and requisition detail with inline approval

Create Requisition Flow

Three paths to create with AI-assisted entry

We designed three creation options to serve different user contexts and preferences, with AI assistance woven into the flow to reduce manual input and speed up the process.

Three creation paths: standard form, Minerva AI chatbot, and guided flow with progress tracking and mandatory sections

Outcome

Shipped to the App Store and immediately put to work

We launched a fully working version of the app on the iOS App Store. The sales team used it immediately to pitch to new clients the working app became a sales tool in its own right, enabling demonstrations of real procurement workflows on a real device.

The Problem

Every team at Cisco was solving the same problems from scratch

We were building AI-powered features across multiple products. And every team kept asking the same questions: How should an agent explain what it's doing? How much control should the user have? What happens when something goes wrong?

There were no shared answers. Agent behavior was inconsistent across products. Transparency was limited. Tooling was fragmented. And none of it scaled as agent ecosystems grew.

We kept seeing the same pattern: a team ships an agent-driven feature, users don't trust it, and the team bolts on explanations and controls after the fact. It was clear we needed a shared foundation before the problem got worse.

The Shift

A fundamental change in how humans work

We weren't designing for chatbots anymore. Users weren't just interacting with an AI to get answers they were conversing with independent agents that act on complex, multi-step workflows as part of a business process. That shift changed everything about what good design meant.

Emerging Challenges

Four categories of friction kept surfacing

Design Reframe

From screens to states

The most fundamental reframe: we weren't designing pages and flows anymore. We were designing persistent decision states that evolve with the agent and the user.

Traditional UX: discrete screens that reset with each action

Agentic UX: persistent states that carry context, evidence, and explanation forward

Traditional UX designs screens discrete layouts that reset with every user action. Agentic UX requires designing states: continuous, context-carrying moments where the agent is thinking, gathering, proposing, awaiting, executing, or recovering.

"When conversation, context, and UI are all fused… UX becomes the bridge between what's understood and what's visible."

Research

How we built the knowledge base

HAX started as a research effort to understand what makes human-agent collaboration effective, predictable, and trustworthy. We ran experiments across agentic product prototypes, observed human decision patterns, and interviewed teams building with LLMs and automation frameworks across five interdisciplinary research areas.

• Foundational Principles Evidence-based design principles for intuitive human-agent interfaces
• Cognitive Frameworks How humans and AI agents process information and make decisions collaboratively
• Ethical AI Translating the ethical dimensions of agentic systems into practical design considerations
• Societal Impact Broader implications of AI-human collaboration on work and society
• Security & Privacy Safeguarding collaborative systems while preserving user trust

Process

How we narrowed to five principles

The principles didn't come from a whiteboard session. They emerged from failure patterns we kept seeing across the research places where agent experiences broke down in similar ways, regardless of domain or product.

When things went wrong, they went wrong in one of a small number of predictable ways:

• Users couldn't tell what the agent was doing or why it made a choice
• Users didn't feel like they could change the agent's behavior, or didn't know how
• When the agent made a mistake, there was no clear path to fix it
• The agent acted independently with no sense of shared work
• There was no way to look back at what had happened or understand why

Those failure modes mapped directly to what became the five principles. We stress-tested the set against agent scenarios across Cisco products. After multiple rounds of review with engineers, AI researchers, and product teams, the set held.

The Framework

Five research-based design principles

What We Built

A unified framework not just a principles doc

HAX connects principles to the tools, components, and behavioral checks developers use every day. It has four interconnected parts:

The HAX SDK and Component Library: UI + semantics + light governance, out of the box

The SDK

From developer code to shared behavioral components

The HAX SDK is a schema-driven, React-based component library that helps developers build agents with consistent behavior, explainability, and user control. Today, developers hand-build each agent's logic and explanation from scratch. With HAX, approved behaviors are encoded as shared, reusable components with schema, policy, and explainability built in.

SDK Components

Use Case

Principles in practice: the Network Agent

To demonstrate HAX applied end to end, we built the Network Agent, a Cisco AI agent that monitors network health, proposes remediations, and collaborates with engineers in real time. Each screen maps directly to a HAX principle, making the framework tangible rather than theoretical.

Clarity: make reasoning visible

The agent surfaces suggested actions with clear rationale, impact labels, and explicit Accept / Modify / Reject controls. Users always know what the agent found and why it's recommending a specific action.

Control: define limits for agent behavior

The Agent Control Panel gives users explicit, granular control over what the agent is allowed to do automatically and what requires manual approval. Permissions are time-bounded and auditable.

Collaboration: work with people, not around them

When the user asks the agent to block a router, the agent flags the risk and offers alternatives instead of executing blindly. The human picks a direction; the agent executes with the parameters the human specifies.

Recovery: support safe reversal of actions

When the agent's rerouting fails, it presents a structured error report: what happened, a timestamped failure log, and clear recovery actions (Inspect, Monitor, Rollback). Users can recover without losing context.

Traceability: expose the history of agent actions

The agent surfaces a full history of similar actions it has taken, with dates and measured outcomes. Users can review past decisions, assess reliability, and optimize future behavior from a position of evidence.

Outcome

Shipped as an open standard

HAX shipped as an open standard and is being considered for adoption across multiple product teams at Cisco. It gave teams a shared language for designing AI-driven interactions and a practical toolkit for implementing them consistently.

The next phase is about how explainability itself can travel across systems maintaining trust and transparency through portable structures for reasoning, evidence, and confidence. The question isn't just how to build one good agent experience. It's how to make every agent experience trustworthy by default.

Visit outshift.design/hax →