ONEPATH

Inspiration

Large goals often fail at the moment they become emotionally or cognitively overwhelming. Conventional agent experiences tend to offer more advice or take more control. ONEPATH explores a different collaboration model: the agent makes the next step smaller and clearer, while the person remains visibly responsible for accepting the path.

What it does

ONEPATH is a WebMCP-native adaptive interface for moments when a goal feels too large. A person begins with a goal such as “I lost my job and don't know where to start.” ONEPATH exposes the live goal and path through WebMCP. The agent proposes a short initial path, but cannot apply it. The person accepts or keeps the current state in the interface.

If Complete your CV feels too large, the person clicks This feels like too much. That direct UI action becomes a structured friction signal. The agent reads the updated state and proposes a smaller replacement:

Complete your CV → What was your last job?

The person must accept that proposal in the UI. Completing the first micro-step then shows 1 of 5, 20% complete, and a visible Undo last change control.

Why WebMCP is essential

Without WebMCP, an agent would have to infer the goal, path, current step, progress, friction signal, and undo state from pixels, then guess which controls are safe. ONEPATH gives the agent structured access to the live interface state through a small, bounded Site Tools contract.

This is not merely faster automation. WebMCP lets the agent and person share the same structured state while preserving a deliberate authority boundary: the agent may inspect, propose, complete a person-supplied micro-step, or undo when asked, but it cannot silently accept a path proposal.

How it was built

ONEPATH is a React and TypeScript application deployed as a public site. It registers exactly five tools with document.modelContext.registerTool:

1. get_current_state — reads the current goal, path, active step, progress, friction signal, pending proposal, and undo availability.
2. propose_initial_path — stages a short initial path without applying it.
3. propose_step_adaptation — stages smaller replacement steps only after a matching too_much signal for the live current-step ID.
4. mark_step_complete — records a completed visible step and keeps the change reversible.
5. rollback_last_change — restores the previous accepted state when history exists.

There is deliberately no accept_proposal tool. Both Accept change actions in the demo are real person-only UI actions. The agent proposes; the person decides.

State transitions, proposal guardrails, reversible progress, and the exact five-tool contract are covered by automated tests.

Human experience

Proposals remain visibly proposals: each includes its reason, before/after comparison, and Accept change / Keep current controls. The activity panel distinguishes person actions from agent suggestions. Progress and Undo remain visible after completion, so adaptation never feels like an invisible takeover.

Challenges and verification

The central challenge was making adaptation useful without giving the agent authority it should not have. The interface, state model, and WebMCP contract all had to preserve the same boundary: structured agent action up to a proposal, followed by an explicit human decision.

The full natural-language flow was verified on the judge-accessible public site using live ChatGPT Site Tools rather than a preview fallback. The agent discovered all five tools, read production state, staged both proposals, responded to the real too_much friction signal, and produced the hero transformation. After one safe synthetic micro-step, both structured state and the visible UI showed 1 of 5, 20% complete, and Undo last change.

What became possible

A person can communicate friction with one direct interface action instead of writing another prompt. The agent can respond to the exact live step instead of offering generic advice. Together they can reshape the path in place while keeping every important decision explicit, inspectable, and reversible.

Current scope

This challenge MVP deliberately has no backend database, login requirement, voice feature, or automatic proposal acceptance. Demo state is stored locally in the browser. The job-loss path is a scenario; the underlying state model is generic.

Built With

• chatgpt
• next.js
• react
• typescript
• vitest
• webmcp