• 

  Agent requests a seat

• 

  Human and agent share live state

• 

  The boundary is real

• 

  Work stays provisional

• 

  You decide what becomes real

• 

  Every session leaves a receipt

Give agents a seat. Not the keys.

Browser agents can now understand and act inside live software. But there is a problem: once an agent enters a shared workspace, what is it actually allowed to touch?

Presence is a trust layer for live human agent collaboration.

Instead of giving an agent the same authority as the human, Presence gives it an explicit seat with bounded capabilities. Humans and agents can work in the same live state without silently sharing control.

The idea

Presence reduces agent collaboration to four primitives:

Seat Where an agent may be present.

Scope What the agent may do.

Revision The state the agent observed before acting.

Receipt What actually happened during the session.

Together they create a simple rule:

Presence does not trust an agent to respect a boundary. The application enforces the boundary.

The demo

The demo uses one responsive project with three live surfaces:

Desktop is the reference.

Tablet is the agent's seat.

Mobile belongs to the human.

A browser agent discovers Presence through WebMCP and asks to join as a responsive collaborator. The human can inspect the requested capabilities before admitting it.

Once admitted, the agent can inspect the project and propose work for Tablet while the human continues editing Mobile.

Then comes the important part.

The agent attempts to modify Mobile.

Presence rejects the operation because Mobile is outside its granted scope.

The same agent can successfully propose a Tablet change because Tablet belongs to its seat. Its work remains provisional: even the agent itself cannot publish it. Only a human acceptance can make the proposal canonical.

Presence also tracks the revision an agent observed. If the human changes the project while the agent is acting on older state, the stale operation is rejected before it can mutate canonical state. The human's newer work remains untouched.

Every significant action is recorded in a structured audit trail. Accepted proposals produce a verification receipt containing the agent identity, granted scope, revisions, operations, protected surfaces, and before/after state fingerprints.

Finally, the human can revoke the seat. The agent loses its authority while accepted work remains part of the project.

Why WebMCP

WebMCP makes the website itself an agent interface.

Presence exposes semantic operations for discovering the workspace, inspecting available roles and constraints, requesting admission, inspecting project state, proposing scoped changes, reviewing state, and releasing a role.

The agent does not need DOM coordinates or a scripted sequence of clicks. It can reason about the application's actual concepts while Presence remains responsible for authorization and state integrity.

How I built it

Presence is built with React, TypeScript, Vite, Zustand, and WebMCP.

The UI and WebMCP tools operate on the same domain model. Mutations pass through the Presence domain layer, where admission, scope, ownership, and revision rules are enforced before canonical state can change.

Agent proposals are provisional by default. Agents cannot publish their own work. Humans retain final authority.

Presence also records structured audit events, computes deterministic state fingerprints, and generates verification receipts after accepted proposals so the collaboration can be inspected and verified after the fact.

Challenges

The hardest part was not exposing tools to an agent. It was deciding what should happen after an agent discovers those tools.

A useful agent needs enough authority to accomplish real work, but giving it unrestricted access destroys the distinction between assistance and control.

That led to the central design principle behind Presence:

Authority should be explicit, scoped, temporary, and visible.

Another challenge was concurrency. If an agent begins working from one revision while a human continues editing, the system cannot simply trust that the agent's eventual change is still safe. Presence revalidates the expected revision at mutation time and blocks stale operations before they reach canonical state.

Presence explores what software could look like when agents are not merely chatbots beside an application, but participants inside it with boundaries the application can actually enforce.

What's next

The responsive workspace is one demonstration of the model, not the limit of it.

Presence already applies the same collaboration model to a second application, demonstrating that the security model is not tied to responsive design.

The same Seat, Scope, Revision, and Receipt primitives could govern agents working inside operations software, content systems, developer environments, and other collaborative applications.

The larger idea is simple:

As agents enter live software, applications need a way to decide not only what agents can understand, but where they may act.

Built With

• framer
• netlify
• react
• typescript
• vite
• vitest
• webmcp
• zustand