AgentDesk

• 

• 

• 

• 

• 

Inspiration

As browser agents become capable of taking real actions, the important question is not only what an agent can do, but what it should be allowed to commit.

We built AgentDesk around one principle:

Agents get real tools inside the workspace. Humans keep the decisions that matter.

Instead of building another chatbot that only recommends actions, we wanted to explore a practical human-agent boundary using WebMCP.

What it does

AgentDesk is a shared human-agent workspace where an agent can operate on structured workspace state through real WebMCP tools.

The agent can:

• Read workspace state with get_workspace
• Analyze requirements with analyze_plan
• Compare options with compare_options
• Create or update tasks with create_or_update_task
• Prepare consequential decisions with prepare_decision

The final decision boundary is human-only.

resolve_decision rejects attempts from an agent or system with human_approval_required. The rejection does not mutate workspace state.

A human can then approve or reject the pending decision through the AgentDesk UI. Once approved, the workspace state changes and the Decision Ledger records the resulting chain.

How we built it

AgentDesk uses React, TypeScript, Vite, Zustand, Zod, and WebMCP through the native document.modelContext API.

The shared workspace state is the source of truth for both the UI and WebMCP tools.

Six WebMCP tools expose different capability levels: reading, changing, proposing, and human-only resolution.

The domain layer contains the actual workspace operations, budget calculations, option comparison, task mutations, and decision lifecycle.

The human-approval invariant is enforced at the domain layer as well as at the WebMCP boundary. This prevents the authority rule from being merely a UI restriction.

The Decision Ledger is derived from the workspace decisions, options, budget state, and activity history to provide an auditable view of proposal, approval, and commit.

Challenges we ran into

The hardest challenge was making the human-agent boundary real rather than cosmetic.

It would have been easy to add an "Approve" button and call the project human-in-the-loop. Instead, we separated proposing from committing.

prepare_decision can create a pending proposal with rationale, cost impact, and projected budget effects without changing consequential state.

When an agent attempts to resolve that decision, the system explicitly returns human_approval_required and states that no workspace state was changed.

We also had to ensure that the UI, WebMCP tools, domain layer, budget calculations, and Decision Ledger all remained consistent around the same source of truth.

Accomplishments that we're proud of

We are most proud that the core security boundary is enforced by the application rather than simply demonstrated visually.

The agent can genuinely interact with the workspace through WebMCP, but it cannot cross the human-only decision boundary.

We also built the Decision Ledger to make the complete chain visible:

Agent proposed → decision held at the gate → agent could not commit → human approved → workspace updated.

The project includes automated tests covering the tool layer, domain behavior, decision authorization, persistence behavior, capability boundaries, and presentation.

What we learned

We learned that giving an agent tools is only half of the problem.

A useful agent interface also needs explicit capability boundaries and enforceable authority boundaries.

We also learned that proposals and commits should be separate operations. An agent can prepare a meaningful recommendation without receiving authority to execute the consequential decision.

WebMCP made this model particularly interesting because the agent interacts with real application capabilities rather than simply exchanging text with a chatbot.

What's next for AgentDesk

The current project demonstrates the core human-agent execution model using a concrete event-planning scenario.

Next, we would generalize the workspace beyond event planning and support more domains where agents can perform useful work while humans retain authority over consequential actions.

We would also expand the capability and audit model, add richer workspace integrations, and explore more granular policies for different types of decisions.

The long-term goal is a reusable human-agent control plane for applications where agents can do the work without silently becoming the decision-maker.

Built With

• document.modelcontext
• javascript
• react
• typescript
• vercel
• vite
• webmcp
• zod
• zustand