Locus

Locus is a private life desk that turns scattered social saves into things you can actually use. you and your browser agent can organize them, build plans, and make informed choices together.

Comment

Inspiration

Life is scattered across apps.

An article waits in YouTube Watch Later. A restaurant is buried in Instagram Saved. A useful thread disappears into X Bookmarks. A recipe, a place to visit, and an idea for a future trip may all belong to the same plan, but the platforms where we found them keep them in separate feeds.

We save because something feels useful. Most of those saves never become useful.

Locus began as an attempt to change that: one private desk for the things you have already chosen to remember. It captures saves from the places where they live and brings them into a personal Library. The same Item can become something to read, a dish to cook, a Place, or part of a Trip Document without losing its source.

WebMCP made the next step possible. Instead of copying personal context into a chatbot and hoping it understands the application, a browser agent can work through tools defined by the page currently open. The person and agent share the same visible artifact.

What it does

Locus turns your saved social content into practical, reviewable outcomes:

  • Desk as the central hub that collects Items from X, Instagram, YouTube, Reddit, or a URL added manually.
  • Reading preserves available writing and helps the user choose what to read.
  • Kitchen turns saved food posts into recipes if needed and presents them in a unique way, helps decide tonight's menu if you want.
  • Atlas organises saved material that is there for travel.
  • Trips can use your saved places to plan the trip you want, with ability to share them.

Each relevant surface registers its own WebMCP tools. On Reading, an agent can inspect the current reading context, search saved writing, open stored text, and present recommendations. In Kitchen, it can search the Recipe Box or compose Tonight. In Trips, it can read the exact itinerary, search bounded Library sources, create Draft stops, apply an exact requested change, validate the schedule, or present three alternatives for a decision.

The distinction between an instruction and a preference is central to the product. If the user says, “Add these three saved places to Saturday,” the agent can make that exact revision-checked change. If the user asks, “Where should I have dinner?”, the agent presents alternatives inside Locus and waits for the person to choose. Agent-created trip stops and recipes begin as Drafts. Publishing, deletion, review, capture setup, and other consequential actions stay with the person.

How we built it

We started with a simple belief: people should not have to change how they save things before those saves can become useful. Locus therefore meets people where they already are. A Chrome extension visits the saved pages they are already signed into on X, Instagram, YouTube, and Reddit, reads the posts they chose to keep, and brings them into one private Library.

From there, we built the product around the ways those saves might become useful. React and TypeScript power one shared interface for Desk, Reading, Kitchen, Atlas, and Trips. Locus can run locally with Node.js and SQLite, and we also built a hosted edition on Cloudflare Workers and D1 so anyone judging the project can open it without installing a server.

WebMCP became the bridge between that private Library and the browser agent. Instead of giving the agent one large, all-powerful connection, each Locus page offers only the tools that make sense there. On Reading, the agent can search saved articles and suggest what to read. In Kitchen, it can help compose Tonight's dinner/food recipes. In Trips, it can read the itinerary, find saved places, add Draft stops, or present three options for a decision.

The most important part was making the agent's work visible. When it changes a trip, the stop appears in the trip the person is already looking at. When the question is subjective, such as choosing dinner, the agent places alternatives inside Locus and waits. The person can inspect the reasons, follow the original saves, choose an option, change the result, or dismiss everything. We built the tools around that relationship: the agent helps move the work forward, while the person remains responsible for the final artifact.

We tested the experience in real browsers, not only as isolated code. Google Chrome and Puppeteer helped us verify capture, navigation, and visible updates. The ChatGPT desktop app's in-app browser acted as a real WebMCP agent: it discovered the tools on the current page, called them, and lost access to them when we navigated elsewhere. OpenAI Codex helped us throughout development with implementation, debugging, testing, and documentation, while image generation helped us explore the final Locus Point identity.

Locus existed before the challenge as a local personal-saves desk. During the submission period, we added the WebMCP experiences across Reading, Kitchen, Library Intake, and Trips, and built the authenticated Cloudflare edition used for this submission. Our dated commit history clearly separates that challenge work from the earlier project.

Challenges we ran into

The hardest design challenge was deciding what an agent should be allowed to do. Generic CRUD tools would have been easy to expose, but they would not create a good collaboration model. We had to separate exact user instructions from open-ended taste decisions, temporary recommendations from durable state, and agent-authored Drafts from human-reviewed artifacts.

Browser lifecycle behavior was another challenge. Our first live interoperability test found that the target browser used the current document.modelContext registration model with AbortSignal cleanup, while an early implementation expected an older interface. Fixing that taught us to treat tool discovery, navigation, re-registration, and visible UI updates as one end-to-end protocol rather than isolated functions.

Capture exposed a different class of browser problem. X uses a virtualised list, and Chrome extension service workers can stop while a long capture is running. Early runs saved several batches and then appeared frozen or ended too soon. We changed the scan behavior, progress reporting, retry model, and job handling so partial work remains useful and later capture continues instead of starting over.

Hosting the complete application also required moving from one trusted local SQLite database to tenant-scoped D1 storage. Authentication alone was not enough: every item, tag, reading document, recipe, place, trip, capture job, and intake operation needed a Library boundary, including cross-user tests that return 404 for guessed identifiers.

Accomplishments that we're proud of

We are proud that Locus became a complete hosted product rather than remaining a local prototype. The deployed application includes Google authentication, one private Library per user, capture and manual intake, and working Desk, Reading, Kitchen, Atlas, Trips, and sharing experiences. Tenant isolation is enforced throughout the data model and covered by cross-user tests.

We are especially proud that WebMCP is part of the product model rather than a thin demo layer. Reading, Kitchen, Library Intake, and Trips each expose tools shaped around their own domain. Those tools update the visible application, respect route lifecycle, and share the same validation and persistence modules as human actions.

The Trips workflow brings those decisions together. An agent can turn named saved sources into revision-checked Draft stops, identify deterministic itinerary problems, or present three reasoned choices inside Locus. The user can inspect the original source, choose an option, adjust the plan, and keep control of the durable result.

We also completed live browser interoperability testing and deployed the whole application to Cloudflare Workers and D1 within the challenge period. The Chrome extension can capture from the user's existing social sessions without requiring the hosted service to hold social account credentials.

What we learned

We learned that WebMCP is most compelling when the browser page is more than a place to launch a tool. It should be the shared workspace where context, action, and review meet. A strong tool result changes something the person can see, inspect, undo, or reject.

We also learned that narrower tools create better behaviour. A tool that searches saved trip sources is safer and more useful than a general Library export. A recommendation tool that can only present three bounded options makes the human decision visible. Registering tools only for the current page gives the agent less irrelevant capability and makes the interface easier to understand.

Most of all, we learned that organising a digital life is not just a classification problem. The real goal is movement: from something saved to something read, cooked, visited, or planned. Locus is our attempt to make social media memory useful while keeping the person, their sources, and their decisions in the loop.

What's next for Locus

The next step is to make the first experience as strong as the underlying product. We want to add an optional example Library so a new user can understand the Reading, Kitchen, Atlas, and Trips workflows immediately, while keeping every real Library private and empty by default.

We also plan to enable hosted enrichment for features such as recipe drafting, place analysis, and prose summaries once the model configuration and operating boundaries are ready. These capabilities will follow the same rule as the current WebMCP tools: generated work must be grounded in visible sources, clearly labelled, and reviewable by the person using it.

Beyond that, we want to improve capture across more source layouts, package the extension for easier installation, add stronger export and restore workflows, and keep refining how one saved Item can move naturally between reading, cooking, places, and travel. The long-term goal is simple: make Locus a dependable private layer between the things people save and the life they want to build from them.

Share this project:

Updates

Submission history