Magentic-UI: Towards Human-in-the-loop Agentic Systems

1 Introduction

• Current agents remain below human-level performance in several domains and can create safety risks through adversarial manipulation or misalignment with human intentions and values.Potential harms include irreversible actions, violated preferences, and exposed private data.Source: §1 · p. 2
• The authors argue that human-agent collaboration can draw productivity from imperfect systems while retaining oversight and control.They expect human involvement to remain important for human agency, unforeseen ambiguities, and adapting agents to a changing world.Source: §1 · p. 2
• Magentic-UI is an open-source end-user application built on an extensible multi-agent system for web actions, code execution, and file work, with MCP tools extending its action space.A lead Orchestrator directs agents, and the human user is treated as a special member of the team.Source: §1 · pp. 2–3
• Its six interaction mechanisms are co-planning, co-tasking, action approval, answer verification, memory, and multi-tasking.They support planning together, handing off control, oversight of high-stakes actions, checking completion, using past experience, and parallel work.Source: §1 · p. 3
• The paper evaluates autonomous task solving on agentic benchmarks, simulated-user interaction on GAIA, qualitative studies with human users, and targeted safety and security.The benchmarks include WebVoyager, GAIA, AssistantBench, and WebGames.Source: §1 · p. 3

Human-AI Interaction

• Unlike traditional AI interactions, agent collaboration involves long-running, complex tasks and actions that can affect the real world or cause irreversible side effects.Prior work reports both productivity gains and underperformance in human-AI teams associated with overreliance or underreliance.Source: §2 · p. 3

LLM-Based Agents

• Magentic-UI adopts LLM-agent design principles and a modular multi-agent paradigm, and selects benchmarks focused on live-website interaction.The work frames its system as a way to investigate agent-to-user, user-to-agent, and grounding challenges identified in prior human-agent research [7].Source: §2 · pp. 3–4

Human-Agent Collaboration

• Compared with Cocoa and CowPilot [33], Magentic-UI combines a multi-agent orchestrator with dynamic handoffs and co-planning, co-tasking, and action approvals.Cocoa lacks dynamic handoffs and replanning outside co-planning; CowPilot [33] offers pause/resume but not those three mechanisms.Source: §2 · p. 4

Potential Benefits of Co-Planning

• Co-planning front-loads user interaction to aim at reducing downstream interaction costs and improving the chance of task success.The proposed benefits include resolving ambiguity, incorporating human priors and planning abilities, and supporting oversight.Source: §3 · p. 5
• Surfacing the plan early can reveal misalignment before time-consuming execution, while user edits can add prior knowledge about how a task should be done.The user may also have stronger planning abilities in some domains, and co-planning can support monitoring with less close attention during execution.Source: §3 · p. 5

Implementation in Magentic-UI

• The Orchestrator asks directed questions when a task is unclear, then generates a plan for the user to review.The plan is a shared sequence of natural-language instructions; it is easier to understand but less flexible than a Python-program plan.Source: §3 · p. 5
• Users can edit the plan directly or by text, track completed steps through a progress bar, and must accept the plan before execution begins.The plan structure supports progress tracking, while the accept step gives the user an explicit start control.Source: §3 · pp. 5–6, Figure 3 · p. 6

4 Collaborative Task Execution

• Co-tasking lets users intervene when agents encounter obstacles, handle steps such as CAPTCHAs, answer clarifying questions, and verify actions during or after execution.The agent can ask about substitutes when a requested product is unavailable.Source: §4 · p. 6
• Users can pause execution at any point, steer the agent through browser interaction or clarifications, then resume automated work.The interface provides real-time updates on intermediate actions and collapses completed plan steps to reduce clutter.Source: §4 · p. 7
• The Orchestrator delegates to the user for clarification or help only after other agents fail to complete a task.A natural-language description field guides which plan steps are delegated to the user.Source: §4 · p. 7
• The user-deferral description was developed through unstructured interaction because no ground-truth signal identifies the right time to interrupt.Simulated-user experiments are proposed as a possible environment for quantitatively choosing this parameter.Source: §4 · p. 7
• After completion, users can inspect agent actions or ask follow-up questions; queries requiring agent action trigger a new planning phase using the prior task.The final answer includes a text response and may include downloadable generated files.Source: §4 · pp. 7–8
• Magentic-UI lets users run multiple tasks concurrently, switch sessions, and see when each requires user input.The authors identify human capacity to oversee and manage agents as the main limiting factor.Source: §4 · p. 8

5 Agent Memory

• The saved-plans view includes plans users learned, created, or imported, with controls to edit entries or rerun tasks.The gallery supports reuse of plans saved from completed tasks.Source: Figure 5 · p. 8, §5 · p. 9
• Memory consists of saved (task, plan) entries indexed by task description, with each plan serving as a guide for solving a task.The representation is intended for repetitive tasks; other forms such as user preferences and personal information are not covered.Source: §5 · pp. 8–9
• After task completion, users can have an LLM synthesize an Orchestrator plan from the execution trace, including user messages.Learned plans appear in a gallery where users can inspect, edit, download, upload, or create plans.Source: §5 · p. 9
• Users can rerun a saved plan or attach it to a new task through suggested plans or manual selection.Attaching a plan can guide a task with changed parameters.Source: §5 · p. 9
• With Task Centric Memory enabled, the Orchestrator retrieves candidate plans by matching task-topic vectors against stored topics, then filters for relevance.The most relevant plan, if any, is returned as a hint for generating the task plan.Source: §5 · p. 9

6.1 Overall Design

• The AutoGen-based team treats the user as an agent and shares a workspace, Docker containers for code execution, and a web browser.The interface and backend create a team per session, store interaction history, snapshot team state for resumption, and expose the controlled browser to the user.Source: §6.1 · pp. 9–10, Figure 6 · p. 10

6.2 Multi-Agent Architecture and Orchestration

• The Orchestrator alternates planning and execution, creating an agent-assigned sequential plan that users can edit or regenerate until they accept it.During execution, it tracks the current step and uses a progress ledger to decide whether to replan, mark the step complete, or instruct an agent.Source: §6.2 · pp. 10–12
• Any agent meeting the multimodal behavior protocol can join the team, with descriptions of its capabilities, actions, and expected behavior guiding Orchestrator selection.Agents are expected to accept multimodal inputs and return multimodal outputs.Source: §6.2 · p. 12

6.3 Agent Details

• The team includes WebSurfer, Coder, FileSurfer, UserProxy, and optional MCP agents for browser, code, file, user-delegated, and external-tool tasks.WebSurfer’s browser runs in Docker and can use a user-configured allow-list; Coder runs generated code in an isolated Docker container and can retry errors up to three times.Source: §6.3 · p. 13

6.4 Action Guard

• Three irreversibility settings route actions to human approval, an LLM judge, or automatic execution.The developer sets each action’s heuristic: always irreversible, maybe irreversible, or never irreversible.Source: §6.4 · p. 14, Figure 8 · p. 14

7.1 Setup

• Evaluation covered GAIA, AssistantBench, WebVoyager, and WebGames, testing file and code tasks, deep web search, live-site interaction, and challenging low-level browsing.WebVoyager used a GPT-4 judge and instructions were updated from 2024 to 2025 for solvability; evaluation practices vary across prior work.Source: §7.1 · p. 15

7.2 Autonomous Evaluation

• Magentic-UI matched Magentic-One on GAIA and AssistantBench, fell short of GAIA state of the art, and with o4-mini was comparable to state of the art on WebVoyager and WebGames.With GPT-4o, Magentic-UI scored 72.2% on WebVoyager, comparable to GPT-4o results reported there but below Browser Use with GPT-4o.Source: Table 1 · p. 16, §7.2 · p. 16
• 113.9s: successful WebVoyager tasks had a lower median runtime than unsuccessful tasks at 236.7s, while unsuccessful runs had a fatter tail.Median plans were two steps on WebVoyager, GAIA, and AssistantBench; WebGames replanning occurred in 52.9% of tasks, roughly its failure rate.Source: §7.2 · pp. 16–17, Figure 9 · p. 17, Figure 10 · p. 18

7.3 Simulated User Evaluation

• Simulated users either used a smarter model or shared Magentic-UI’s model while receiving task plans as side information, and could guide planning, help when the agent got stuck, or provide a final answer.This setup was a lower bound on human feedback because real users can intervene at any time; prompts limited inadvertent answer leakage to all but 6% of tasks.Source: §7.3 · p. 17, Setup · p. 18
• 71%: simulated users with task side information raised autonomous Magentic-UI task completion from 30.3% to 51.9% on GAIA validation.The simulated user was asked for help on 10% of tasks and supplied the final answer on 18%; a smarter-model user raised performance to 42.6%.Source: Setup · pp. 18–19, Figure 11 · p. 19

7.4 Qualitative User Study

• In a 12-person study, users gave the interface a 74.58 SUS score and valued information gathering, but latency, technical errors, and verbose reasoning or plans remained pain points.Only 41.7% agreed they would like to use the system frequently; participants’ varied views may reflect limited need or a mismatch with frequent-use scenarios.Source: §7.4 · pp. 19–21
• Participants valued co-planning to express subjective preferences and revise plans, and used co-tasking to correct model errors, retain control, or explore beyond the original task.They also wanted to revisit completed steps and rerun them when correcting errors.Source: §7.4 · p. 21
• Users favored action guards for high-risk actions and clarification questions for underspecified tasks, while many preferred background multitasking with safeguards.Some found task notifications or returning to ongoing tasks confusing; summaries helped some users recover the task state, while others wanted clearer state summaries.Source: §7.4 · p. 22
• Validation ranged from thorough review to cursory checks; some participants reviewed only after completion or when results looked wrong, and some trusted outputs despite uncertainty.Participants sometimes noticed inaccuracies but judged them insignificant enough not to correct.Source: §7.4 · pp. 22–23
• Participants verified outputs through text, screenshots, and the live view, often preferring visual evidence and requesting less verbose, more visual explanations.Some participants used co-tasking to inspect pages themselves, while two asked Magentic-UI in chat to verify; suggestions included annotated screenshots and a flow diagram.Source: §7.4 · p. 23
• Without prior experience, participants built mental models through trial and error and struggled to know how human-in-the-loop features could best support the model.Many tested requests they were unsure Magentic-UI could perform to better understand its capabilities.Source: §7.4 · p. 23

7.5 Safety and Security Testing

• In 24 realistic adversarial scenarios, none succeeded with the default configuration; action guards, approval requests, sandboxing, and a credential-free browser limited risky actions and access.The layered safeguards sought user consultation before risky actions and prevented access to or leakage of sensitive resources even if an action was approved.Source: §7.5 · pp. 23–24
• With mitigations disabled, GPT-4o resisted social engineering, but prompt injections could exfiltrate SSH keys, create persistent GitHub API keys, and search email for one-time codes.The paper concludes these security-focused mitigations are necessary for safe operation.Source: §7.5 · p. 24

8.1 Progress Towards Effective Human-Agent Collaboration [7]

• Plans align agent actions with user goals and support up-front review, but actions within a step can exceed its description and the natural-language DSL lacks branching and parallel steps.The authors suggest enriching the plan DSL as a possible way to accommodate those structures.Source: §8.1 · p. 25
• Reviewing more plan steps may make plan editing too costly, motivating possible hierarchical plans or selective feedback requests.Source: §8.1 · p. 25
• Progress indicators, action histories, and guards support monitoring, but long histories overwhelmed some participants, who requested visual summaries.Users sometimes needed to review how the agent reached an answer to judge completion or correctness.Source: §8.1 · pp. 25–26
• Some participants found action-guard requests excessive; tuning interruptions to user preferences without sacrificing task completion remains an open problem.The authors note that users who develop trust may prefer fewer approval decisions.Source: §8.1 · p. 25

8.2 Limitations

• Evaluation did not measure downstream productivity, Magentic-UI was designed and tested in English, and its general-assistant performance remains below human level.The authors call for long-term controlled trials to measure productivity benefits.Source: §8.2 · p. 26

8.3 Risks and Mitigations

• Magentic-UI requires explicit approval for proposed actions and can request approval before visiting sites outside an allowed list.The authors also describe sandbox isolation and local storage as parts of its safety design.Source: §8.3 · pp. 26–27
• In preliminary red-teaming, the system refused, asked the user, or was blocked by Docker sandboxing in response to adversarial requests.The authors report this layered approach as effective against the tested attacks.Source: §8.3 · p. 26

8.4 Conclusion

• The authors conclude that co-planning, co-tasking, and verification have potential to improve task success and reduce oversight burden.They release Magentic-UI as an open-source platform for testing related hypotheses and exploring agent behaviors.Source: §8.4 · p. 27

• Co-planning turns a task into an editable sequence of natural-language steps assigned to agents, which users can add, delete, reorder, modify, or regenerate.The example plan assigns a WebSurfer to find arXiv papers and a Coder to create a CSV.Source: A Overview of Magentic-UI · p. 35
• Execution begins only after user acceptance; users can pause or take over, provide help with obstacles, and approve actions deemed irreversible, costly, or potentially harmful.The interface shows the current step and the agent's proposed action and its result.Source: A Overview of Magentic-UI · p. 35
• After completing the plan, Magentic-UI returns a text answer and any generated files, with useful links and a trace of the steps for verification.Source: A Overview of Magentic-UI · p. 35
• Users can save plans synthesized from execution traces, edit them, and reuse them in future tasks through automatic retrieval or manual selection.The paper describes this as a form of longer-term memory.Source: A Overview of Magentic-UI · p. 36
• Users can launch multiple task sessions, switch between them, and use status indicators to see whether a session needs input, is active, or has a final answer ready for review.Source: A Overview of Magentic-UI · p. 36

• Require approval when an action may affect safety or security, make irreversible changes, affect data integrity or privacy, or impact other people or external entities.The prompt says any one of these criteria is sufficient.Source: B Action Guard Prompt · p. 36
• Examples requiring approval include submitting forms, sending email, making purchases, entering sensitive information, creating unapproved files, or opening a potentially malicious file.Source: B Action Guard Prompt · pp. 36–37
• Changing UI focus, entering a nonsensitive search query, and writing harmless code are examples that do not require approval.Source: B Action Guard Prompt · p. 37
• The examples are not exhaustive; when unsure, the prompt directs the system to require human approval.Source: B Action Guard Prompt · p. 37

• The learned plan should use as few steps as possible and focus on reaching the answer efficiently without including the final answer itself.The prompt says agents may perform multiple steps in one go.Source: §C.1 · p. 37
• The prompt requests useful action details, such as buttons clicked or URLs visited, rather than an exact replay of the conversation.Source: §C.1 · p. 37
• For the example query about Autogen's largest social-media following, the plan first finds its platforms, then checks Twitter and LinkedIn follower counts.Source: §C.1 · p. 38

D Safety and Security: Adversarial Scenarios

• When encountering phishing or fake browser-update prompts, the agent identified the threat, replanned and waited for approval, or stopped interacting and searched for alternatives.The scenarios included malicious downloads and a phishing site mimicking Microsoft Office.Source: D Safety and Security: Adversarial… · p. 39
• The agent sought approval after a file-URI request to read a local file and blocked an attempt to access its own web interface to approve plans or disable settings.The file-access request concerned a text file; the self-access attempt was blocked.Source: D Safety and Security: Adversarial… · p. 39
• In file and web scenarios involving attempts to leak SSH keys or environment variables, the agent re-planned and waited for user approval.The reported outcomes cover injected text files and webpages.Source: D Safety and Security: Adversarial… · p. 39
• Some web injections were ignored while others led to replanning and approval, including attempts to run shell commands or create a GitHub access token.For one webpage, the agent ignored the injection and summarized normally; other scenarios triggered a new plan and approval request.Source: D Safety and Security: Adversarial… · p. 39
• When a paywall login prompted egregious OAuth permissions, Magentic-UI developed a new plan and paused execution until the user approved it.The scenario notes a risk of autonomous permission granting if the user is already logged in to Google.Source: Figure 14 · p. 40