Human-Agent Control Surfaces and Operator Experience
Design interfaces that let people understand, direct, interrupt, and judge autonomous work without reading raw logs.
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
The chapter in one pass.
- Purpose: Design interfaces that let people understand, direct, interrupt, and judge autonomous work without reading raw logs.
- Best for: Product, design, platform, governance, and engineering leaders.
- Prerequisites: Human-Agent Operating Model and Compounding Engineering and Human Attention.
- Reading time: 15 minutes.
- You will learn: The required states and interactions for intent, plan preview, progress, intervention, approval, evidence review, and recovery.
- Keep three ideas: interfaces display authority rather than create it; progress must be decision-oriented; and every autonomous action needs a safe interruption path.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Design one screen for a high-risk WorkOrder awaiting release. Include intent, plan deviation, current artifact, failed evidence, pending approval, rollback, safe actions, and raw trace drill-down. Explain the information hierarchy.
3. Enduring Principle
Design around decisions and state
The primary surfaces are:
- Intent composer: outcome, reason, constraints, criteria, owner, risk, non-goals.
- Plan preview: steps, assumptions, affected systems, capabilities, tests, rollout, rollback, cost, uncertainty.
- Execution view: current state, completed and pending work, active Attempt, budgets, changes, blockers, safe controls.
- Intervention: pause, cancel, answer, redirect within scope, request revision, or escalate. Material replanning creates a new plan or authority version.
- Review inbox: ordered decisions with deadline, risk, recommendation, evidence, alternatives, and consequence of inaction.
- Evidence review: criteria mapped to fresh proof, counterevidence, waivers, lineage, limitations, and raw drill-down.
- Recovery view: failure class, retained state, retry eligibility, changed hypothesis, cleanup, and owner.
Make status precise
Use authoritative states such as awaiting plan approval, queued for capacity, executing, awaiting input, independently verifying, blocked by stale evidence, eligible for release, observing outcome, or quarantined. “Thinking” is not operational status.
Stream useful progress
Progress events summarize completed decisions, material discoveries, scope changes, evidence, budget, and next expected transition. Token or tool-call streams remain optional diagnostics. Notifications should be deduplicated, severity-aware, accessible, and routed to the accountable person.
Preserve safe human control
Pause and cancellation have defined semantics. Reject and request-revision are distinct. The UI previews side effects before approval and confirms accepted actions. Keyboard, screen-reader, contrast, reduced-motion, timezone, and localization needs apply to operational interfaces.
Measure attention
Track time to decision, unnecessary interrupts, approval rework, false urgency, evidence-review time, escalation quality, abandonment, and operator confidence. Faster clicks do not prove better judgment.
8. Notes and lessons learned
Trustworthy autonomy should feel calm. The interface does not need to dramatize reasoning; it needs to make state, uncertainty, authority, evidence, and recovery legible.
9. Interview and discussion questions
- What belongs in a progress event?
- Why are pause and cancel different?
- How should the UI display counterevidence?
- When should a chat interaction create a new Plan revision?
- Which metrics reveal operator overload?
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence