Agent and solver
Proposal, with one decision: the solver for the first version · decided 2 October 2026 · nothing is built · library facts checked 2 October 2026
The proposal is to keep the arithmetic away from the language model: a solver — an ordinary, deterministic service — would build and check the schedule, and the agent would only translate between people and that service.
The agent talks, the solver counts, and the API has the last word on the rules.
What the solver is
A program that assigns people to shifts under given rules. The problem is a classic one — the same kind as scheduling nurses in a hospital, which Google’s optimisation library uses as its textbook example — and it is solved with existing optimisation libraries, not with a language model.
- It takes data, not text. The team with roles and availability, the store’s rules, and how many people are needed each hour. These are the fields on Input data.
- It returns a schedule, or says that none exists — and then which hours stay uncovered and which rule is in the way.
- Hard rules are never broken. Minimum rest, maximum hours, shift length, absences.
- Soft rules are optimised. Preferences, a fair spread of weekends and late shifts, less overtime.
A language model is poor at this kind of arithmetic and gives no guarantee that every rule holds. Its part is different: understand what a person asked for, fill in the parameters, call the solver and explain the result in plain words.
What the agent would ask of it
| Tool | What it would do |
|---|---|
| Build a schedule | A draft for the period from the store’s data |
| Check a change | Whether a particular swap or day off breaks a rule |
| Find cover | Who could take a shift without breaking a rule, and what it would cost |
| Explain a refusal | Why no valid schedule exists and what would fix it |
Two rules matter more than how the tools are wired:
- The agent fills in a fixed form; it does not write the rules itself. Otherwise it can simply forget the rest rule, and nothing would notice.
- The API re-checks every change with the same rules, whether it came from the agent, the employee assistant or the manager. This is what the product pages promise: every change is checked against the same rules as the original schedule.
Is the solver an MCP server?
No. The solver is a service. MCP — an open standard for connecting AI applications to external systems — is one possible way to hand that service to an agent, and whether we need it depends on where the agent runs:
| Where the agent runs | MCP? |
|---|---|
| Inside our own API | Not needed. The tools are described directly in the call to the model: fewer moving parts, simpler permissions, simpler separation between stores. |
| On an external agent platform — Agentfy, for example | Yes. It is the standard way to connect our tools to such a platform. |
| In a manager’s own AI assistant | Yes. The assistant connects to our tools the same way. |
In every case MCP would be a thin wrapper around the same service. Where the agent runs is not decided, so neither is this.
Which solver
For the first version (the MVP): YALPS — decided on 2 October 2026. YALPS is a solver written in TypeScript. It runs inside the NestJS API, so the first version needs no second language and no separate service.
Its authors aim it at small problems: by their own guideline, a few thousand variables and constraints at most, and no more than a few hundred yes/no decisions. They maintain it for fixes only. Whether a real store fits inside that is not known. An illustrative count: 20 people, 14 days and 4 possible shifts a day is already 1,120 yes/no decisions. So the first version has to describe the problem coarsely or start with a small store, and showing that it can is the first job of the prototype.
Later, most likely: Google OR-Tools, run as a small separate service in its own pod next to the API in Kubernetes. This is an intention, not a decision; it depends on what the first version shows. OR-Tools officially supports C++, Python, Java and C#, not Node, which is why it would be a separate service. We would run it, not translate it into TypeScript: its licence allows a translation, but it is a large C++ code base, and we expect a translation to be slower and ours to maintain forever.
What keeps the switch cheap is the proposal above: the solver sits behind the same four tools, so neither the agent nor the application needs to know which library answers.
Also looked at, and not chosen for the first version:
| Library | What it is | Why not now |
|---|---|---|
| highs-js | The HiGHS solver compiled to WebAssembly; runs inside Node | The closest alternative if YALPS proves too small before OR-Tools is in place |
| MiniZinc for JavaScript | A constraint language with several solvers | In Node it needs MiniZinc installed on the server |
| OptalCP | A scheduling solver with a TypeScript API | Proprietary; the free preview does not return the schedule itself |
We have used none of these libraries, YALPS and OR-Tools included. Everything above comes from their own pages.
What it would cost us
- A second language, later. YALPS keeps the first version in TypeScript. OR-Tools would bring a second language and one more service to run and deploy.
- An explanation does not come for free. Left alone, a solver reports that no schedule exists, not why. To name the uncovered hours and the rule in the way, the problem has to be modelled for that from the start.
- Traffic has to become a headcount first. How many people each hour needs is a separate step before the solver, and how to do it is open.
Not decided
- Whether YALPS is enough for a real store, and when OR-Tools replaces it.
- Where the agent runs, and therefore whether the tools are wired directly or through MCP.
- How traffic turns into required headcount.
- How long solving takes for a real store. We have not measured it and quote no number.
- Whether the agent-and-solver split works at all for managers. It is a hypothesis until a prototype on one store’s data confirms it.
Where to go next
- Schedule generation: the same idea in the manager’s words.
- Overview: the application and the API around the solver.
- Open questions: what is decided and what is not.