Inspiration
Agents are now really good at generating HTML/CSS/JS artifacts to help convey understanding to users by visualizing content. There are already services that enable agents to easily host static pages, but these lack interactivity.
At the same time, agents are mainly used by one user only, and there isn't that much of a multiplayer mode. When collaborating with coworkers or friends, we have to manually send artifacts/plans, gather feedback, and potentially go through multiple sessions and iterations to reach the final desired state. Multiple agents can work toward the same goal, but in complete isolation.
My goal was to try to use a super simple platform to enable a new kind of multiplayer agents × humans collaboration.
What it does
BuildParty allows anyone to create a party. It is completely their own, and agents can automatically connect to it using WebMCP tools. Each party is initially empty, but any connected agent can add and modify “artifacts”, which are self-contained HTML/CSS/JS components. The owner can share the link so that other users can join on any device, connect their agents, and see changes in real time. Users can interactively add comments and suggestions directly on the page for all agents to see.
The page is fully synced, and each change is saved as a revision. The owner can roll back to a previous revision at any time. At the end, the owner can finalize the party, closing any further modifications and compacting all artifacts together into a single HTML page ready to download. Each block supports persistent state so that interactive elements such as text areas, buttons, etc. can work.
The flow is very simple for agents: read a specific block, modify it or add a new one, and read comments.
This can be used for a range of different use cases: collaborative planning before starting a long implementation, ephemeral agent observability dashboards to see specific progress, and more.
How we built it
This was built using webmcp for tools, custom-made evaluation with WebMCP-bench using daytona cloud sandboxes, electric for sync and PostgreSQL for the underlying db.
Challenges we ran into
Evaluating WebMCP capabilities is very hard because, on top of the current agent context, we add a new dimension: the website state. Even if my basic evaluations worked, when manually testing I often ran into cases where the agent could not efficiently figure out which tool to call or in which order.
To fix this, I built a small WebMCP evaluation framework based on a finite state machine: each state encodes a website state fixture and the available tools, while transitions to other states define specific tool calls.
From this FSM specification, I can automatically implement tool discovery and give agents information about the available flow of tool calls. I also defined an evaluation bench with a set of tasks that consist of an initial state, a target end state with a sequence of expected tool calls, and an initial prompt. With this, I was able to fine-tune tool descriptions and improve the agent's understanding of how to use the website context efficiently.
Accomplishments that we're proud of
Everything works, and I'm already using it for some use cases!
What we learned
I learned a lot about what is possible with WebMCP and how to reason about it. I believe that, at some point, we could somehow ditch frontend frameworks as we know them and start with only a state flow/state machine representation of the app, then enable UI components “on demand” that automatically adapt to the user's preferences and needs. This would also be awesome for accessibility, as we could automatically derive not only visual frontends but other frontend formats as well.
What's next for BuildParty
If there's some interest, I would like to rework the whole artifact engine to make it more robust to agent changes and enable different formats such as Markdown editors, code blocks with interpreters (Jupyter Notebook style), and embedded databases. I would also like to improve the human side with a more precise feedback system, chatbox, authentication, etc.
Built With
- codex
- electric
- postgresql
- webmcp
Log in or sign up for Devpost to join the conversation.