-
-
LASSO — Draw What Your Agent Can Touch | WebMCP Challenge 2026
Inspiration
AI agents are becoming capable of acting inside increasingly complex web applications. But there is still an awkward question:
How does a human communicate exactly what the agent is allowed to understand and change?
In visual applications such as dispatch maps, dashboards, CAD tools, scheduling boards, and other canvases, the relevant context is often obvious to a human. We can simply point at it.
Explaining the same boundary to an agent usually means naming objects manually, writing long instructions, building application-specific permission systems, or trusting the agent to infer intent from the interface.
LASSO explores a different interaction model:
The human interface generates the agent interface.
A dispatcher draws a boundary around the resources the agent may work with. WebMCP turns that transient visual selection into a live, typed capability contract for the visiting agent.
The map is the prompt. The boundary is the permission.
What it does
LASSO is an AI-assisted dispatch console built around a seeded disruption scenario with six late deliveries.
The dispatcher draws a freehand lasso around the deliveries and drivers the AI agent may reason about.
That gesture does much more than highlight the map.
LASSO compiles the selected UI state into revision-specific WebMCP tools whose JSON Schemas contain only the resources inside the human-defined boundary.
The external agent then:
- Inspects the scoped operational state.
- Authors its own recovery plan.
- Submits the plan to LASSO for deterministic validation.
- Receives structured violations if the plan breaks capacity, vehicle, timing, overtime, or scope constraints.
- May request additional resources outside its current authority.
- Cannot grant that additional authority to itself.
- Repairs its plan after the human approves a scope expansion.
- Can modify live routes only after the human authorizes one exact verified plan.
In the demo scenario, the agent discovers that delivery D15 requires refrigerated capacity that is unavailable inside its original scope.
It asks for Mika, a suitable driver outside the boundary.
The human chooses whether to include Mika.
That single UI action invalidates the previous WebMCP contract and compiles a new revision in which Mika becomes available to the agent.
The repaired plan reduces six late deliveries to one with three route changes and zero overtime.
Only then can the dispatcher authorize execution.
The resulting write capability is bound to the exact plan, current scope, workspace generation, and a single expiring use. Stale or replayed authority is rejected.
Why WebMCP
LASSO is not an optimizer with a tool wrapper.
The agent authors the plan. LASSO provides the scoped world model, deterministic validation, authority negotiation, and execution boundary.
The central WebMCP idea is that the tool surface itself changes as the human manipulates the live application.
A visual gesture becomes structured machine-readable context.
When the human changes the lasso, the agent's available resource IDs and capability contract change with it.
Traditional browser automation can see a highlighted region, but it still has to infer what that highlight means and whether it represents authority.
A conventional remote API or MCP server would require additional synchronization to know what the human just selected in the browser.
With WebMCP, the page itself can expose that ephemeral application state directly to the visiting agent.
How we built it
LASSO is a lightweight, dependency-free web application built with vanilla JavaScript, HTML, CSS, SVG, JSON Schema, and the imperative WebMCP API.
The architecture separates four responsibilities:
- Human UI — visual scope, operational constraints, authority decisions
- Scope compiler — converts UI state into revision-specific WebMCP contracts
- External agent — creates and repairs recovery plans
- Policy engine — validates and safely applies scoped state changes
The application also includes deterministic browser, security, adversarial, package, and performance validation.
The final local release campaign includes more than 150 correctness and security invariants plus a 5,000-case adversarial fuzz campaign.
Challenges
The hardest problem was not drawing a lasso. It was making the boundary meaningful.
We had to ensure that:
- changing scope invalidates stale capabilities;
- an agent cannot expand its own authority;
- outside-scope assignments remain untouched;
- a delivery can never silently acquire multiple owners;
- application handlers validate authority independently of JSON Schema;
- partially registered WebMCP contracts fail closed;
- in-flight tool calls are not broken by contract recompilation;
- an authorized plan cannot be changed and replayed later.
Several of these issues only appeared during adversarial testing and required changes to the underlying state-transition model rather than cosmetic fixes.
What we learned
WebMCP becomes especially interesting when tools are not static API endpoints.
A web application's live human state can itself determine what capabilities an agent discovers.
That creates a new interaction loop:
human gesture → typed capability → agent reasoning → authority request → human decision → new capability
The conversation between human and agent does not have to happen entirely in a chat box. The web interface itself can participate.
What's next
Dispatch is the demonstration, not the limit.
The same interaction pattern could apply anywhere humans naturally identify context spatially:
- operations dashboards
- analytics
- CAD and design tools
- scheduling systems
- infrastructure maps
- logistics
- spreadsheets and visual workspaces
The long-term idea is simple:
Point at the context. Let the web turn that gesture into an agent contract.
Log in or sign up for Devpost to join the conversation.