Inspiration

A cutting plan is not just an answer—it is a decision about real material.

For small workshops and makerspaces, planning starts with measured boards, usable offcuts, required parts, and the material lost to the saw blade. Copying that information into a chatbot creates a second version of the workshop: someone must reconcile the advice with the actual stock and translate it back into a usable cut sheet.

Offcut explores a different workflow: let the person and the browser agent work from the same committed measurements, while keeping proposal and approval separate.

Cutting-stock optimization is established work. Our contribution is the shared human–agent workflow around it: structured comparison, an exact review handoff, and approval that becomes invalid when its underlying measurements change.

What it does

Offcut is a shared cutting-stock workbench for straight crosscuts from stock of the same material and cross-section.

People can:

  • Enter stock lengths and required part quantities.
  • Set blade kerf and the minimum length considered reusable.
  • Protect stock needed for another job.
  • Compare proportional cutting layouts.
  • Review and approve an exact plan.
  • Export its CSV cut list or print its cut sheet.

Through native WebMCP tools, a browser agent can read the committed workshop, request checked alternatives, inspect their constraints, compare results, and stage one complete proposal for review.

Three objectives make the trade-offs explicit:

  • Use less stock
  • Handle fewer boards
  • Keep useful offcuts

Sawdust, short scrap, reusable remnants, and unopened stock remain separate. A plan that produces less short scrap can still open more stock and require handling more boards; Offcut shows that trade-off instead of hiding it behind a single “waste” score.

How we built it

Offcut is a static React and TypeScript application built with Vite and published on GitHub Pages, with public MIT-licensed source.

The interface and agent tools use the same workshop store and deterministic branch-and-bound planner. The language model chooses what to explore; the application checks part quantities, stock constraints, and material balance.

Six JSON-schema-defined tools are registered through the browser’s native WebMCP API:

  • get_workshop
  • plan_cuts
  • inspect_plan
  • compare_plans
  • stage_plan_for_review
  • export_cut_list

There is no WebMCP polyfill, embedded chatbot, application backend, or website API key. Manual planning also works without WebMCP. Connecting an agent depends on the browser host’s own model, permissions, and availability.

The planner works in integer millimetres and has a bounded search. It reports optimality only when proved—not simply because it found a complete plan.

Challenges we faced

Keeping approval attached to the right decision

Selecting another draft must not transfer approval. Reusing a checked solution must not transfer approval either.

Approval belongs to one exact plan ID at one committed workshop revision. Acknowledgement and approval are separate interface actions; neither is a registered agent tool. Export checks the exact approved, fresh, complete plan.

This is a tool-capability boundary, not authentication against an agent separately granted browser UI control.

Distinguishing unfinished typing from changed measurements

An unfinished measurement field is not a new workshop revision.

Offcut distinguishes pending edits from saved measurements. Pending edits pause review and approval. Committing an actual change invalidates the previous approval and makes the old plan stale, so the agent must replan and return for a new review.

Making native integration verifiable

We tested real native tool registration, discovery, calls, disposal, and reinitialization across Chrome 149 and 152, including their differing API behavior.

The demo uses a real model through an external recording harness. Its evidence rail summarizes retained native calls and UI events; it is not an embedded website chatbot or a ChatGPT screen recording. UI actions are automated for the recording, and waiting time is trimmed.

Preserving correctness while improving performance

We improved search pruning, reused checked solutions for identical committed requests, and reduced repeated UI work. Reuse still creates a new unapproved plan record and preserves the original computation’s proof status.

What we learned

Shared state matters more than conversational fluency. An agent becomes more useful when it can work with the same revision, identities, and constraints that the person sees.

Approval is a state transition, not a reassuring message. Its meaning depends on the exact proposal, the measurements behind it, and what happens when those measurements change.

Optimization needs explainable trade-offs. Less scrap, fewer boards, and less opened stock are different goals. The application should expose those differences rather than pretend one score answers every workshop’s priorities.

Native tools should expose checked domain operations. The model can explore and explain alternatives without inventing measurements or bypassing the workbench’s release rules.

What we accomplished

Offcut 1.1.0 passed 884 source-contract tests and 72 browser cases: 18 contracts across local and hosted deployments in Chrome 149 and 152.

We also verified the maximum 40-cut CSV export and visually checked all 12 rendered pages across two six-page print outputs.

The 2:45 demo follows a complete workflow: compare alternatives, stage a proposal, acknowledge and approve it, export its cut list, then change kerf from 3 to 4 mm. The previous approval becomes invalid. The agent replans all 14 parts and ends at revision 2: staged, not approved.

These are illustrative planning results—not measured workshop savings, machine instructions, or a safe-cutting guarantee.

Try Offcut

Built With

Share this project:

Updates

Submission history