takt_shift

Users inspect a synthetic factory, optimize an isolated scenario, compare it to the committed baseline, and request human approval.

Comment

Inspiration

Production scheduling is a prime example of an area where agents can be helpful, but also need clear boundaries. A useful agent should be able to inspect a factory, explore alternatives, and prepare improvements without pixel-scraping or silently altering the production plan. We built takt_shift to facilitate this type of collaboration: The agent can perform the analytical work while a human remains in control of the final schedule.

What it does

Takt_Shift is a WebMCP-native production scheduling sandbox for a synthetic automotive paint line.

A signed-in user can create an isolated scenario from the current committed revision. In that scenario, a person or agent can:

  • inspect machines, orders, calendars, and constraints;
  • move orders with stable IDs;
  • Run a deterministic schedule optimizer.
  • compare the draft with the committed baseline across makespan, overtime, paint changes, and late/on-time orders.
  • request a human review. Inspect retained committed revisions.

The safety boundary is part of the product, not a prompt. Protected orders never move. Overtime above 360 minutes is invalid. An agent can request a review but cannot commit. Only a human click in the approval dialog can create a new committed revision.

Why WebMCP is the right fit

Without WebMCP, an agent would need to infer intent based on labels, the Document Object Model (DOM) structure, and click coordinates. This method is unreliable for any application, especially for an operational workflow with stateful constraints.

With WebMCP, however, the page exposes ten purpose-built tools with typed JSON schemas and stable identifiers:

list_factory, get_scenario, compare_to_baseline, list_scenarios, list_revisions, create_scenario, select_scenario, move_order, optimize_scenario, and request_review.

The available tools follow the authenticated application state. Draft-only actions appear only when a draft exists, and review and commit remain separate processes. Tool results return structured state and explicit rejection reasons so that an agent can recover from stale selections or invalid moves instead of guessing.

This creates a better experience for both parties. The agent can reason over a reliable contract and quickly handle multi-step schedule exploration; the human sees the same scenario, diffs, KPIs, and review request in a purpose-built visual interface. Together, they can evaluate more alternatives without weakening accountability.

How we built it

The application uses TanStack Start, React, and TypeScript. WebMCP tools are registered in React with @mcp-b/react-webmcp and are backed by @mcp-b/global in the browser. Each tool has a JSON input schema, clear operational description, and execution function.

Manual controls and WebMCP handlers dispatch the same typed commands. These commands flow through one deterministic reducer and a pure TypeScript scheduling domain. This ensures that there is no privileged agent-only mutation path. The optimizer reproducibly searches for better schedules while enforcing catalog compatibility, protected-order immutability, and the overtime cap.

Better Auth protects the workspace. Drizzle ORM and SQLite persist one sandbox per authenticated user, including scenarios, the committed baseline, and revision history. The production deployment runs as a long-lived Node process in Docker. The UI uses Tailwind CSS, and the landing experience includes a Three.js/WebGPU factory scene with an accessible fallback.

Challenges we ran into

The hardest challenge wasn't exposing the tools; it was designing a trustworthy state machine around them. We had to ensure that tool registration remained synchronized with authentication and scenario status; that stale agent calls failed clearly; and that browser agents and humans could never diverge through separate code paths.

Another challenge was preserving determinism while producing meaningful improvements. The scheduling engine avoids time-, locale-, and randomness-dependent behavior, making every optimization replayable and testable.

Finally, the approval boundary required careful separation. "Request review" is a reversible handoff, while "commit" changes the shared baseline and revision number. Shaping the reducer, UI, persistence model, and WebMCP surface to be human-only kept the latter human-only.

Accomplishments that we're proud of

  • A complete, deployed product experience, rather than a tool registration demo. Ten working, state-aware WebMCP tools are available for discovery, analysis, scenario editing, optimization, and review handoff.
  • One shared mutation path for UI and agent actions.
  • Deterministic optimization with enforceable safety invariants.
  • Persistent, per-user scenarios and a committed revision history.
  • A human approval gate that cannot be bypassed through WebMCP.
  • A verification suite that covers domain behavior, persistence, WebMCP contracts, pages, accessibility-sensitive copy, and visual behavior.

What we learned

Agent-native UX is primarily contract design. While good tool names and schemas are important, lifecycle, state freshness, structured errors, and authority boundaries are more important. WebMCP works especially well when the UI is the domain of judgment, and the tools provide precise, composable operations.

We also learned that "human-in-the-loop" does not mean adding a confirmation box at the end. The entire application must model draft state, review state, and committed state, as well as who is permitted to cross each boundary.

What's next for takt_shift

Next, we plan to implement richer scheduling constraints, explainable optimization traces, scenario import/export, and more detailed audit views. Additionally, we want to explore multi-objective optimization controls that allow humans to prioritize lateness, changeovers, or makespan while preserving deterministic execution and the human-only commit gate.

Built With

Share this project:

Updates

Submission history