REENTRY

REENTRY gives WebMCP continuity beyond a browser session—a consent-driven cloud bridge that brings agents back when real events occur, grounded in live page state and bounded by human control.

Comment

Inspiration

I was helping Eyad brainstorm ideas for JustApplyForMe.com his startup, the job-search app he was building. While researching a problem in the app, I found a YouTube video about WebMCP and brought it up with him. We started exploring it together, and that led us to the WebMCP Challenge.

As we discussed what to build, we kept coming back to what happens when an agent has to wait.

You can explain what you want, discuss a strategy and let the agent get started. But many workflows depend on someone else reviewing an application, replying to a request or updating a system. The agent gets as far as it can, then its turn ends.

When the next update arrives, it usually comes to you. You have to find the conversation and tell the agent to carry on, even though you may have already agreed on what should happen next. The website knows something has changed, and the agent has the plan, but you're still the person passing the message between them.

That was the part we wanted to change. Could a website bring the existing agent conversation back when there was a reason to continue, with permission the person had already given?

We wanted people to spend their attention on the strategy and the decisions that actually needed them. Re-Entry Core grew out of that question.

What it does

REENTRY connects a website's later business events to the user's existing agent task. Our design lets a person approve which events can bring that task back, keep the original strategy conversation and revoke the permission when they no longer want it.

We chose Sleepless Kingdom as the first Host application and demo. A persistent game makes the waiting period easy to understand: you can leave, but the world keeps moving.

The demo is designed around a gathering mission. You and your agent discuss a plan, inspect the kingdom and prepare a mission. You authorize the relevant notifications, then step away.

Later, a monster kills the gatherer and destroys its unbanked cargo. In this game, the same soldier respawns at the shelter. If a safe route is available, the mission can receive one automatic retry, so the soldier may already be heading out again by the time the update is read.

The cargo-loss event gives Re-Entry a reason to notify the original agent task. On return, the agent uses WebMCP to read the mission history and current state. It can see both the failed attempt and what the soldier is doing now, then judge whether the new trip still fits your plan.

If recall is appropriate and currently allowed, it can tell that soldier to return. The recall applies to the active retried mission; it doesn't recover the lost cargo or undo the death. The agent can also leave things as they are or ask you for a decision.

That's the experience we're trying to build: you set the direction without having to watch for every update yourself. Major commitments, such as migration and siege, remain yours.

Sleepless Kingdom is where we demonstrate the idea. The Core is separate from the game so other websites can use it too.

How we built it

We started both Re-Entry and Sleepless Kingdom from scratch during the hackathon.

We built a Host SDK so the website can describe a future re-entry request and later report the event that makes it relevant. On the page, a WebMCP tool called request_codex_reentry starts the same consent request as the normal human interface. The backend uses the SDK to create and sign our webmcp.reentry_manifest, which describes the proposed relationship and its scope.

We kept the approval separate from that request. The Cloud Receiver checks the Manifest and takes the user through consent. Only the user's approval creates a Grant. An agent finding or calling the tool doesn't give itself permission to return.

When an eligible business event happens later, the website's backend signs it and sends it to the Receiver. The Receiver checks the source, authorization and event identity before recording a delivery. Signing credentials stay on the Host's server.

The Local Connector handles the device side. It pairs with the Receiver and checks for approved deliveries through an outbound connection, so the website doesn't need a direct connection into the user's computer. We put platform-specific continuation behind an Agent Adapter. In the design, the association with the original task stays private on the device.

We kept the Core independent of game rules and agent-specific code. It's written in Node.js ES modules, with a SQLite reference store and no runtime dependencies. The cloud application uses Express, Prisma and PostgreSQL.

For Sleepless Kingdom, we used Next.js, React and TypeScript, with Canvas 2D rendering and WebSocket updates from the World Server. The server owns the game state; the browser displays it and exposes the actions available to the player and agent.

The page registers its WebMCP tools through document.modelContext.registerTool(...). Our first gameplay slice provides reads for the shelter, live snapshot, missions and history, plus force_recall_soldier when the current state and continuation signal permit it.

WebMCP is involved before and after the wait. It helps the agent start the Manifest-and-consent handshake, then gives it current information and valid actions when it returns. Re-Entry supplies the event-delivery path between those visits.

Challenges we ran into

Our first sketch looked much simpler than the system we ended up building. We thought we could add a small layer that let a website send a signal to Codex.

The difficult part was reaching the task where the person had already explained their plan. Starting a new agent process didn't answer that question. We spent a lot of time investigating what Codex could support locally and couldn't simply plug into a direct, supported third-party endpoint for the continuation we needed. That shaped the split between the Cloud Receiver, Local Connector and Agent Adapter.

We also had to decide where our service's responsibility should end. An agent might receive an update, look at the game and decide not to act. We didn't want the Receiver to treat that as a delivery failure and keep sending notifications until a game action happened. In our selected design, delivering the notification and completing the agent's work are separate.

Repeated events, dropped connections and revoked permission added more work. We needed to test what happened around those cases, including when a process restarted partway through delivery.

We discovered the challenge on its fourth day. With a game and a service to build, we kept the first demo focused on one event and a limited set of actions. That gave us a specific sequence to work through without pretending it was the full game we wanted to make.

Accomplishments that we're proud of

In an early controlled MVP, we continued an existing Codex task, returned to the website and made fresh WebMCP calls. That mattered to us because the earlier conversation could still be part of the work. We had a concrete example of the continuity we'd been talking about.

We built the Core, SDK, Receiver and Connector as separate components, with tests for authorization, repeated events, revocation and recovery. Separate-process tests let us check the connections between them as well as the individual pieces.

The game gave us another result we could inspect: a real server-side cargo loss, the soldier's new mission and a recall checked against that current mission. That local sequence is covered by its own tests. It makes the reason for rereading the page tangible.

We're proud of having built both the reusable mechanism and an application that gives it a purpose. The point of Re-Entry is for a person to be able to agree on a plan with an agent and have that plan remain useful when the next update arrives.

What we learned

Building the game changed how we thought about WebMCP tools. By the time a notification is delivered, the mission described in the original conversation may already have ended. The agent needs the page to tell it what has happened since and which actions are still valid. We had to design for that change, rather than assume the tool list or state would stay the same.

The project also made us more precise about working with Codex during development. We got better at defining the task and the check that would show it was done. For example, a successful process launch doesn't prove the original conversation resumed, and a successful notification doesn't prove a game action happened.

We brought those distinctions into our runbooks and kept decisions written down so different parts of the project wouldn't quietly rely on different assumptions. That was a practical improvement in how we work with AI, and one we'll keep using beyond this hackathon.

What's next for Re-Entry

Our immediate work is to bring the tested components together in the normal installed same-task flow. That includes binding the original conversation during enrollment, verifying that an event can wake an idle task, and checking repeated events under the same authorization. The controlled MVP and local game tests are useful evidence, but that complete packaged path is still being integrated and verified.

We also want another developer to be able to add Re-Entry without having to understand every detail of our implementation. We'll keep improving the SDK and setup experience, and explore adapters for other supported agent environments.

Beyond games, we'd like to try it in workflows such as applications and approvals, where progress depends on another person or system. We want to find out where it genuinely reduces the need for someone to monitor updates and restart the work.

And we'll keep developing Sleepless Kingdom. We think the game is worth continuing in its own right, especially the possibility of people and agents playing together over time. A player could discuss how they want to manage resources or respond to threats, then work with their agent as the situation changes.

The current tools are only the first slice. We want the full range of eligible gameplay features to be available through WebMCP, including mission management and defense planning, while keeping major commitments under the player's control. Expanding the game will give us more interesting situations to play through and more demanding tests of what Re-Entry can do.

Built With

Share this project:

Updates

Submission history