Inspiration
A surprising number of everyday operational problems are really placement problems in disguise. You have a set of people, tasks, items, vehicles, or events, a limited number of places or resources, and a collection of rules that determine what can go where. We see this everywhere. Guests need to be assigned to tables. Patients need beds. Employees need shifts. Classes need rooms. Aircraft need gates. Jobs need machines. Inventory needs storage locations. In every case, the basic question is the same: how do you put the right thing in the right place while respecting all the constraints around it? Creating the first plan is only part of the challenge. The harder part often comes later, when reality changes after the plan has already been accepted. A guest suddenly needs an accessible table. Two people can no longer sit together. A VIP needs a specific position. A resource becomes unavailable. A manager makes a last-minute decision that should not be undone. At that point, the goal is not to throw everything away and optimize from scratch. It is to repair the existing plan while preserving as much of what already works as possible. Traditional optimization systems are good at solving structured problems, but people do not usually describe operational changes as formal constraints. They say things like "keep these two apart", "do not move this person", or "this group needs to stay together". An AI agent can help translate that kind of natural-language intent into structured constraints, but there is another problem: the agent may be working from an older version of the plan while a person is still editing the live page. That creates a very real failure mode. A person can make an important manual change, and the agent can later overwrite it simply because it is still acting on stale state. We wanted to explore a collaboration model where that cannot happen silently. We chose seating because it makes the larger idea easy to see. A guest represents an entity that needs to be assigned. A table represents a limited-capacity resource. "Together" and "apart" rules behave like clustering constraints. Accessibility and fixed-table rules represent eligibility and placement requirements. A locked guest represents a human decision that the agent is not allowed to override. Seating Repair is our way of exploring how WebMCP can bring these pieces together: natural-language agency, deterministic constraint solving, live application state, and direct human control, all operating on the same shared planning surface.
What it does
Seating Repair is a WebMCP application for solving and repairing constrained placement problems while a person and an agent are both working on the same live plan. The demo uses 12 fictional guests and three tables because that makes the idea easy to understand at a glance. But underneath the seating interface, the application is dealing with a more general planning problem: limited-capacity resources, people who must stay together or apart, fixed placements, eligibility requirements such as accessibility, decisions that a human has explicitly locked, and the need to keep as much of the existing plan unchanged as possible. Through WebMCP, a browser agent can read the exact current state of the board, understand the active constraints, add new hard constraints from a person's request, repair the plan, and then validate the result. The goal is not simply to press an "optimize" button and generate a completely new seating arrangement. In a real planning workflow, many existing decisions are already correct and should stay that way. A useful repair needs to preserve what still works, respect every hard constraint, treat human-locked placements as authoritative, change only what is necessary, and verify that the final result is actually valid. This becomes especially important when a person and an agent are working at the same time. If the agent reads the board and a person then moves or locks a guest, the agent is no longer allowed to write using the old version of the plan. That stale write is rejected with STATE_CHANGED. The agent has to read the page again and continue from the decision the person actually made instead of silently overwriting it. In the demo, this is easy to see: a person can move Grandma Rose to a different table and lock her there. The agent can then add another constraint, repair the remaining conflicts, and validate the board while leaving Grandma Rose exactly where the person placed her. Seating is the domain we chose to demonstrate the idea, but it is not the limit of the underlying pattern. The same kind of constrained allocation and repair appears in restaurant and event operations, protocol seating, workforce scheduling, room and resource allocation, patient-to-bed assignment, airport gate reassignment, and many other situations where a working plan has to adapt as constraints and human decisions change. The current build is intentionally focused on demonstrating that shared coordination model clearly. It is not meant to pretend that one seating demo is already a complete product for every one of those industries. Instead, it shows the core interaction pattern: an AI agent can help repair a constrained plan, while the live application remains the source of truth and human decisions remain in control.
How we built it
We built Seating Repair as a lightweight TypeScript app with Vite. Everything runs in the browser, with no backend and no separate database for the agent. The seating board that the person sees is the same state the WebMCP tools work with. We kept the WebMCP side intentionally simple and exposed only four tools. One reads the current seating state, one adds hard constraints, one repairs the plan, and one validates the result. That was enough to cover the full interaction we wanted to demonstrate without turning the project into a large collection of overlapping tools. We also did not want the language model itself to be responsible for deciding whether a seating plan is correct. The agent can understand a request such as "keep these two apart" or "do not move this guest", but the actual planning is handled by deterministic application code. The repair logic runs in the browser and searches for an arrangement that satisfies all of the current constraints. It checks table capacity, together and apart rules, fixed-table requirements, accessibility, and human locks. When there is more than one valid solution, it prefers one that changes as little of the current plan as possible. Human edits are treated as first-class state changes. A person can move a guest manually and lock that placement. Once a guest is locked, the agent cannot move them during a repair. There is no hidden tool option that lets the agent ignore the lock; the person has to unlock that guest first. One of the main things we wanted to get right was what happens when the human changes the board while the agent is working. Every change to the seating plan increments a revision number. When the agent tries to change the plan, it has to provide the revision it previously read. If the board has changed since then, the write is rejected with STATE_CHANGED. That means the agent cannot quietly apply an old plan over a newer human decision. It has to read the current board again and continue from there. Repairs are also atomic. The solver works on a snapshot first and only updates the live board after it has found a complete valid solution. If the constraints cannot be satisfied, the current plan stays as it was instead of being left in a partially changed state. The manual UI and the WebMCP tools share the same store, validation logic, and constraint model. We wanted there to be one source of truth rather than one version of the plan for the person and another version for the agent. For the demo, state is stored in browser localStorage, which keeps the project self-contained. We also added tests for the behaviors we considered most important: constraint validation, deterministic repairs, minimum-change solutions, human locks, unsatisfiable plans, stale revisions, invalid tool input, and WebMCP tool execution. The overall design is fairly simple on purpose: the agent handles natural-language intent, WebMCP gives it structured access to the live application, and normal deterministic code is still responsible for enforcing the rules and deciding whether the final plan is valid.
Challenges we ran into
The hardest part was not the seating solver itself. It was deciding how a person and an agent should safely work on the same plan without one silently undoing the other. At first, it is tempting to treat the agent like a normal automation flow: read the state, calculate a better arrangement, and write the result back. That works until the person changes something in the meantime. Once we started testing that interaction, it became obvious that stale state was one of the most important problems in the whole project. We ended up making every mutation depend on the exact revision the agent had read, so an old write is rejected instead of being applied over a newer human decision. Human overrides were another tricky part. We wanted a person to be able to move someone and say, effectively, "this decision is final for now". That sounds simple, but it only works if the lock is enforced below the UI level. If the agent can pass an option that ignores it, the lock is not really a human guarantee. We therefore made locked placements part of the planning rules themselves rather than just a visual state on the page. The solver also needed to behave differently from a normal "find any valid solution" solver. In a real repair workflow, completely rearranging the board every time a new constraint appears would be frustrating even if the result is technically valid. We had to make the solver prefer the existing arrangement and move only the guests that actually need to move, while still satisfying capacity, together/apart, accessibility, fixed-placement, and lock constraints. Another challenge was deciding how much responsibility to give the AI agent. It would have been easy to ask the language model to reason through the seating plan directly, but then correctness would depend on the model getting every constraint right. Instead, we kept the roles separate: the agent interprets the person's request and chooses the appropriate WebMCP actions, while deterministic application code is responsible for solving and validating the plan. We also spent time keeping the WebMCP interface small. There are many possible actions we could have exposed, but more tools would not necessarily make the interaction better. We reduced the workflow to four tools that map closely to what the agent actually needs to do: read, add constraints, repair, and validate. That made the demo easier to understand and gave each tool a clearer contract.
Finally, we had to balance technical depth with a demo that could be understood quickly. Constrained allocation can become a much larger problem, but a hackathon demo only has a few minutes to make the idea clear. We deliberately used a small seating scenario because conflicts, locks, human edits, and repairs can all be seen immediately. The challenge was making the example simple without making the underlying problem look trivial.
Accomplishments that we're proud of
One of the things we are most proud of is that the demo looks simple, but the behavior underneath it is not. Seating Repair does more than generate a new arrangement from scratch. It works with a plan that already exists, keeps the decisions that are still valid, respects the choices a person has explicitly locked, and tries to repair only the parts that actually need to change. We also wanted human decisions to have real authority, not just visual priority in the interface. Every agent write is tied to the exact revision of the board it was based on. If a person changes the plan after the agent reads it, the old write is rejected instead of being applied over the newer state. A locked guest cannot be moved by the repair tool unless the person unlocks them first. Another part we are happy with is how failures are handled. If the current constraints cannot all be satisfied, the solver does not leave the board halfway changed. The existing plan stays intact. When a repair does succeed, the result is checked again against table capacity, together and apart rules, fixed placements, accessibility requirements, locks, and the current state before it becomes the new plan. We also kept the human interface and the agent workflow on the same underlying model. The WebMCP tools, the manual board, the solver, and the validator all work with the same source of truth. There is no separate version of the plan hidden away for the agent that can slowly drift away from what the person is actually looking at. For us, that shared-state behavior is the most important part of the project. The seating example is intentionally easy to understand, but the guarantee behind it is broader: a person can step in, change a decision, lock it, and continue working with an agent without having to worry that the agent will silently undo what they just did.
What we learned
The biggest thing we learned is that giving an agent access to an application is only part of the problem. The harder part is deciding what should happen when the person and the agent are both changing the same thing. Before building this, it was easy to think of the workflow as a simple sequence: the agent reads the plan, makes a decision, and updates the page. In practice, that breaks down as soon as the person makes a change in the middle. The live state matters more than the agent’s previous understanding of it, and the system needs a clear rule for who wins when those two versions are different. We also learned that human control has to be enforced in the application logic, not just suggested in the prompt. Telling an agent to "respect locked guests" is not the same as making it impossible for the repair operation to move them. Once we treated locks as actual constraints rather than instructions, the collaboration model became much clearer. Another lesson was that AI and deterministic code are good at different parts of the problem. The agent is useful for understanding what a person means and turning requests into structured actions. But checking capacities, satisfying hard constraints, finding a valid arrangement, and proving that the final state is correct are better handled by normal application logic. Combining the two felt much more reliable than asking the model to reason through everything itself. We also came away with a different view of optimization. In many real workflows, the best answer is not the globally cleanest plan if getting there means changing everything people have already agreed on. Once a plan is in use, stability matters. A repair that changes two assignments can be more useful than a theoretically better solution that changes ten. Finally, working with WebMCP made us think less about "tools for an agent" and more about the application as a shared workspace. The interesting part is not that an agent can call a function. It is that the agent can understand and act on the same live state the person is looking at, while the application still enforces its own rules. That is the idea we would carry forward from this project: AI is most useful in operational software when it can help people adapt a plan, without becoming more authoritative than the people who are responsible for it.
What's next for Seating Repair
The next step is to move beyond the fixed demo scenario and make the planning model configurable. We would like people to be able to create their own guests, tables, capacities, seating rules, and priorities instead of starting from the same fixture every time. We also want to add softer preferences, not just hard constraints, so the system can balance things like "prefer these people together" or "keep this group close to the front" without treating every request as an absolute rule. Another important addition would be a repair preview. Instead of applying a valid solution immediately, the agent could first show exactly what it wants to change, why those changes are needed, and which constraints they solve. The person could approve the whole repair, keep some placements, or reject it and try another option. Undo and clearer change receipts would make that collaboration even safer. For seating itself, there are several natural directions we could take this. A restaurant or private-dining version could include reservations, party sizes, booking times, table combinations, accessibility needs, and live table availability. An event version could handle weddings, conferences, and corporate seating. A protocol-focused version could add seat-level positions, organizational roles, host proximity, VIP requirements, and other rules that matter when placement is sensitive. We are also interested in separating the general planning logic from the seating interface. The core problem is broader than chairs and tables: assigning things to limited resources while dealing with capacity, compatibility, relationships, existing commitments, and changes that happen after a plan is already in use. That same pattern appears in scheduling employees, assigning rooms, allocating hospital beds, placing aircraft at gates, and many other operational workflows. We do not see the current demo as a finished product for all of those areas. What it gives us is a small, understandable way to test the interaction model first. The part we would keep unchanged is the basic contract between the person and the agent: the live application remains the source of truth, human decisions can be protected, and when something changes, the agent repairs around those decisions instead of starting over or silently replacing them.
Built With
- browser
- css3
- html5
- javascript
- json
- localstorage
- schema
- typescript
- vite
- webmcp
Log in or sign up for Devpost to join the conversation.