Spacio

Inspiration

Managing a warehouse is a stream of decisions with real consequences: where a new product line goes, which items move closer to dispatch before the season peak, whether the cold area can absorb next month's intake, where twenty incoming pallets will live. Each decision draws on reports from several areas, in several formats, each telling part of the story. Logistics keeps the article master, commercial sends the sales export, purchasing announces intake, quality flags holds. Units vary, SKU codes follow different conventions and the operational constraints live in a notes field. The manager reconciles all of it with experience, applies rules learned on the floor and takes responsibility for the outcome. I have done that job in several sectors, among them automotive parts and food distribution, and Spacio is the tool I wanted on those days: a model that knows the rules, an assistant that does the reconciliation and the arithmetic, and a clear line around the decisions that stay with the person in charge.

Who we are

Spacio is a two-person project. I bring the warehouse side: years managing operations in automotive, food and other sectors, the reports that arrive every month, the rules learned on the floor and the decisions that come with them. My husband, a software developer, brings the engineering: the 3D model, the WebMCP tool catalog, the validation rules and the traceability log. Every tool in Spacio started as a situation from my work and became code through his.

What it does

Spacio is a browser app where that work happens. The manager keeps a 3D model of the facility (perimeter, racks, aisles, docks), the inventory that lives in it and the slotting plans under consideration. An AI agent works on that same model through 32 WebMCP tools:

• The manager hands over the reports as they arrive. The agent normalises units, spellings and codes, maps notes such as "keep upright" to constraints, validates every container against rack geometry and storage type, loads what fits and explains each rejection with a reason code such as STORAGE_TYPE or CONTAINER_TOO_LARGE.
• The manager states the operating rules in plain language: heavy items on the two lower levels, cold chain in cold storage, keep the batteries where they are. The agent pins heavy items low, locks bins and works around them.
• The manager hands over a month of order lines. The agent aggregates them into picks per SKU, assigns each product its ABC class, reloads the inventory with it, generates deterministic slotting strategies and compares them by route metres, time, number of moves, free reserve and weight rules, then explains every relocation.
• The manager questions a proposal. The agent traces the pick route of the top seller to packing and dispatch, focuses the camera on a rack and reads back the move list.
• When the data calls for it, the agent adjusts the building: more pallet racks, a dispatch dock at the front, a wider aisle, with the layout validated for clearance and reachability.
• The manager approves the facility revision and approves the plan. Those are page buttons, the tools report approvedByHuman truthfully, and the approved plan freezes its move list. Every call, human or agent, lands in a traceability log with parameters, results and durations.

Why WebMCP is a strong fit for this use case

Three kinds of reasoning meet in every slotting decision. The reports are unstructured and full of context that a language model reads well. The building is a geometric model that the page reasons about precisely: rack dimensions, aisle clearances, weight per level, distances to dispatch. The decision belongs to a person who carries the responsibility. WebMCP lets those three work on the same model: the page exposes its domain functions as typed tools, the agent calls them with what it read from the reports, and the manager sees every result in the same 3D scene they use to decide.

The value is in the combination. The agent's reading of a workbook becomes useful the moment it can be validated against real geometry, and the page's validation becomes useful the moment someone can feed it 200 rows in one call. Each tool returns exact numbers, so the agent reasons on the same figures the manager sees, and the manager can check every claim the agent makes.

How it creates a better user experience

The manager works the way they already talk about the warehouse. They hand over the reports and describe the rules in their own words. The agent turns that into typed tool calls and the model updates in front of them: racks take their category, products appear in their bins, the route of the top seller draws itself to the dock. Every proposal comes back with figures and reasons, so the manager questions it, adjusts a constraint and asks again, in minutes. The buttons that carry liability stay in the interface, and the whole exchange can be reviewed afterwards in the log.

What people and agents can now do together

• Go from two departmental exports to a validated inventory in the 3D model in one conversation, with every rejected container explained. Until now this meant days of spreadsheet reconciliation followed by manual entry.
• Turn a month of order lines into an ABC classification and a set of slotting strategies compared on route metres, moves, free reserve and weight rules, then choose one with the numbers in view. Until now reslotting was a project that waited for a quiet week.
• Apply the operating rules across hundreds of SKUs on every load and every plan, so a rule the manager states once is enforced every time.
• Adjust the building from the data: when 20 pallet SKUs are short of locations, the agent proposes more pallet racks, the manager accepts, and the layout is validated before anything is built.
• Keep a decision trail: the approved plan freezes its move list with the reasoning attached, and the log answers "who decided this and why" for auditors, insurers and the next shift.

Impact on the operation

Time. Reconciling the departmental reports and loading a validated inventory takes one conversation. The same work done by hand, cleaning the article master, matching it against the sales export and typing the result into a planning sheet, takes days, which is why reslotting is usually postponed. With the reconciliation and the arithmetic handled by the agent, reslotting can follow the season and a new intake can be planned the day the purchasing report arrives.

Accuracy. Every container is checked against real rack geometry and storage type, and every rule the manager states is applied to the whole catalog, on every load and on every plan. A 25 kg container on an upper level, a refrigerated item in an ambient rack or a pallet in shelving is caught before the move, with a reason code, rather than found on the floor. The manager still decides, but with the exceptions listed instead of hunted.

Picking productivity. Slotting strategies are compared on route metres and picking time before a single box moves, so the manager chooses the plan knowing what it saves. In the sample scenario the compact strategy shortens the picking route by roughly a quarter while keeping every heavy item on an allowed level.

Safety and losses. Weight-per-level rules and storage segregation are enforced by the tools, which means fewer injuries from heavy boxes stored high and fewer write-offs from mixed storage. Free reserve is reported on every plan, so peaks are absorbed in the building already paid for.

Accountability. The approved plan freezes its move list with the reasoning attached, and the log records every call, human or agent, with parameters, results and durations. The answer to "who decided this and why" is available to auditors, insurers and the next shift without reconstructing it from spreadsheet versions.

How we built it

Vanilla JavaScript and Three.js, with state in localStorage and plain files served over HTTP. 32 tools registered imperatively with navigator.modelContext.registerTool() (with a document.modelContext fallback), each with a JSON Schema inputSchema, annotations.readOnlyHint and an async execute returning plain JSON. A shared validator checks every input against its schema and rejects unknown parameters. The Design mode runs in an iframe, so the main page registers proxy tools for it, because agents only see tools on the top-level document. A logging wrapper traces every call into the Log panel. Mutating tools record undo snapshots. Layout and plan approval are page buttons only.

Challenges

Keeping approval honest across reloads (the facility signature depends on geometry only), making validation identical for humans and agents, and describing 32 tools so an LLM picks the right one and fills a 300-row product payload in a single call.

What's next

Import real floor plans, connect a WMS export for velocity data, and let the agent negotiate constraints (locked bins, reserve targets) with the manager inside the log.

Built With

• css3
• html5
• javascript
• webmcp