What you'll learn

Transparency requirements by lifecycle stage:

Discovery & Evaluation (Assist mode):

• Show progress ("Searching 3 sources...")
• Attribute information ("According to...")
• Allow refinement ("Not what you wanted? Try...")

Commit Phase (Act mode):

• Show consequences BEFORE action ("This will charge £99 to your card")
• Require explicit approval ("Confirm purchase")
• Provide cancel option ("Cancel" button always visible)
• Explain what happened AFTER ("Charged £99, order #12345")

Fulfilment (Automated):

• Notify of progress ("Shipped", "Delivered")
• Surface only on failures ("Delivery delayed")

Support (Human-in-loop):

• Clear escalation paths ("Speak to human")
• Undo options ("Cancel order", "Request refund")

Now anchored to commit-phase anxiety and user trust.

Visibility & Transparency Rules

What the user must see, what must stay hidden, and how to design trust in multi-agent systems

Visibility and transparency are not about showing everything your system does.

They are about:

• showing the right things

• at the right time

• in the right level of detail

• for the right user action

In multi-agent systems, transparency is a design discipline, not a data dump.

1. Transparency ≠ Full Disclosure

A common mistake:

“If the system is complex, just show everything it’s doing.”

This destroys trust.

Users do not want to see:

• tool calls

• agent names

• debug logs

• JSON errors

• confidence graphs

• chain-of-thought reasoning

They want:

• understanding

• predictability

• control

Not complexity.

UX rule:

Reveal purpose, hide mechanics.

2. The Three Layers of Visibility

Multi-agent systems require three distinct transparency layers:

Layer 1 — Intent Transparency

What the system is trying to do

Users must always understand:

• why the system is acting

• what goal it is pursuing

• whether it aligns with their intent

Example:

“Comparing your flight options…”
“Drafting three variations…”

This prevents fear and uncertainty.

Layer 2 — Process Transparency

Where the system is in the workflow

Users must know:

• whether to wait

• whether to continue

• whether the system is stuck

• what step comes next

Good signals:

“Checking availability…”
“Coordinating with payment…”
“Reviewing your preferences…”
Progress indicators
Clear phases

Avoid:

✘ “Calling booking agent…”
✘ “Retry count: 3”
✘ “Worker 4 failed”

Layer 3 — Control Transparency

What the user can do now

Users must always know:

• can they stop?

• can they undo?

• can they modify?

• can they override?

• can they continue?

This is where AI safety meets UX.

Required controls:

Cancel
Undo
Edit
Approve
Reject
“Start over”

UX rule:

Transparency without control is anxiety.
Control without transparency is confusion.

Both must co-exist.

3. When to Surface Transparency

Always show transparency when:

• an action takes more than 1–2 seconds

• context changes

• irreversible operations are about to occur

• human input is required

• the system deviates from the expected flow

Do NOT surface transparency when:

• the system is retrying internally

• agents are coordinating backstage

• low-level errors occur

• partial computations have no user implication

4. Irreversible Action Transparency

Before any action that cannot be undone:

Users must see:

• what is happening

• why it’s happening

• what the consequences are

• who is responsible (the system vs the user)

Example:

“Are you sure you want to confirm this purchase for €329?”
“This will overwrite your previous file. Continue?”

This is non-negotiable.

5. Transparency for Multi-Agent Systems

Multi-agent orchestration introduces unique transparency needs:

Required transparency points:

• when agents hand off context

• when a task shifts phases

• when a decision requires human validation

• when an optional interpretation was chosen (“I assumed you meant…”)

• when memory influenced behavior

Avoid:

Mentioning specific agents
Mentioning backstage architecture
Mentioning retries, parallel operations

Users shouldn't know:

“Three agents just interacted.”

They should know:

“Your plan is ready. Here are three options.”

6. Transparency for Errors and Recovery

If something breaks:

• be brief

• explain the effect, not the cause

• provide actionable steps

• offer alternative paths

Bad:

✘ “ToolError: 502 Bad Gateway from API.”

Good:

“I wasn’t able to complete that. Would you like to try again or choose another option?”

Visibility must be:

• human-centered

• non-technical

• action-oriented

7. Transparency for Memory-Influenced Behavior

If the system uses memory:

• users must know

• users must control it

Required transparency:

“I used your previous preference (window seat). Want to change it?”
“I remembered your writing style. Should I keep using it?”

This prevents “creepy” surprises.

8. Transparency in Voice, Screen, and Multimodal Agents

Voice

Must use explicit spoken cues:

• “Let me check…”

• “One moment…”

• “I’m coordinating this for you…”

Screen

Use:

• progress bars

• cards

• status messages

• optional detail reveals

Multimodal

Transitions must be clear:

• “I’ve placed the results on your screen.”

• “Tap to continue.”

9. The Transparency Triangle (Use This in Slides)

Users need three things at all times:

1. What is happening?

(intent + phase)

2. Why is it happening?

(meaning + context)

3. What can I do now?

(control options)

If any corner is missing:

• users feel lost

• trust collapses

• perceived intelligence drops