strategic modelling
The Agentic Window
The agentic window is an experimental AI agent inside the strategic workbench that lets you drive the workbench in plain language. You describe what you want - “show me cost to serve by customer last quarter”, “import this spreadsheet of drops”, “clone last month, add two chilled vehicles and re-optimise” - and the agent translates it into calls on a fixed catalogue of tools. It is deliberately limited: the model only orchestrates a closed toolset, every change it proposes needs a person’s approval before it runs, and a per-customer budget caps its spend. No language model produces a route, sets an optimisation parameter or evaluates a cost; that is the same operations-research optimiser that runs daily planning. It is experimental: it works, but it is still being integrated with the agent service, so treat it as a preview of the workflow rather than a production guarantee.
Last updated: 2026-08-17
Key Capabilities
- Query the data warehouse in plain language: results return as tables you can pivot or plot
- Manipulate datasets by instruction: apply a named parameter recipe or a validated data transform in a copy, then re-optimise
- Import a spreadsheet: the agent profiles the columns, asks for clarification where it needs it, and maps it to the data model with UK postcode geolocation
- Combine and merge data across multiple projects
- Closed toolset: read-only tools dispatch directly; every mutating tool needs a person's approval before it runs
- Per-customer budget caps agent, optimisation and external address-matching spend
- Model-agnostic by design: runs on Anthropic's Claude today; no LLM produces a route, parameter or cost
Inside the strategic workbench is a chat panel: a plain-language way to drive the same operations the workbench exposes by hand. You describe the outcome you want; the agent works out which tools to call to get there, and proposes the result for you to approve.
It is experimental. It works, but the integration with the agent service is still being finished, so it is there to try, not yet to rely on, and everything it does can be done by hand in the workbench today.
What You Can Ask It to Do
- Query the record. Ask a question of the data warehouse in plain language and get a table back, which you can then pivot or plot. “Which rounds ran below 70% utilisation in May?”
- Adjust a dataset and re-run. “Replace two of the 12-tonne vehicles with 18-tonne and re-optimise in a copy.” The agent clones the dataset, applies the change as a named recipe or a validated transform, and launches the optimisation, each mutating step put to you first.
- Import a spreadsheet. Point it at a CSV or XLSX. It profiles the columns, asks for clarification where the mapping is ambiguous, maps the file to the Optrak data model with UK postcode geolocation, validates it, and proposes an import you review before it lands.
- Combine across projects. Pull together and merge data from more than one project when a question spans them.
Where Its Authority Stops
This is where the discipline matters most. The agent is a large language model, and it is tightly limited. It can only call a fixed catalogue of tools: read a dataset, query the data warehouse, profile a CSV, propose an import, apply a named parameter recipe, clone a dataset, launch an optimisation, compare two snapshots. It does not write raw commands, and it does not touch the optimiser’s internals. No language model produces a route, sets an optimisation parameter or evaluates a cost. The credibility of every figure still comes from the operations-research optimiser, exactly as it does in daily planning. This is the same line Optrak draws wherever it uses an LLM agent: the model orchestrates; it does not optimise.
The toolset splits cleanly. Read-only tools (list datasets and snapshots, query the warehouse, inspect the model, profile a CSV, compare snapshots) run directly. Mutating tools (clone a dataset, apply a parameter recipe, land a reviewed import, launch an optimisation) are the only way the agent changes anything, and each one needs a person’s approval.
The Limits
A person approves every change. Every action that changes data or spends real compute is proposed, not performed. The agent shows you what it wants to do; you approve or deny in the panel; only on approval does anything run against the optimiser or write to a dataset. A request left unanswered times out as a denial rather than proceeding.
A per-customer budget. A monthly budget caps three things (agent token use, optimisation minutes and external address-matching spend) and a turn is refused before it starts if the customer is over budget. Opening modelling up to more people does not open up an uncapped bill.
A constrained change surface. Parameter changes are a small closed set of safe recipes; broader reshaping is a data transform that is validated before it can be applied. The agent cannot invent an arbitrary edit to your operation.
The Model
The agent runs on Anthropic’s Claude today. Because the model sits only at the orchestration layer, the design is model-agnostic: a hosted or local model can be swapped in without touching the optimisation, and the Anthropic adapter is simply the one wired up now. Storage follows the same principle: cloud object storage in production, local storage when you want to inspect the artefacts directly.
Status
The agentic window is experimental. The workbench around it (viewing and comparing datasets, importing data, cloning and adjusting configurations, running the optimiser, and reading the comparison) is essentially ready and does all of this by hand today - through ordinary forms, with no language model configured at all. The agent is a preview of driving those same steps from a sentence: live, tightly limited, and still being integrated with the agent service. See AI in route optimisation for where it fits among Optrak’s AI work.
Frequently Asked Questions
How ready is the agentic window?
It is experimental. The agent works - it translates a request into calls on a fixed catalogue of tools and proposes the result for you to approve - but the integration with the agent service is still being finished, so it is offered to try rather than to rely on. Every step it performs has a manual equivalent in the workbench today, with one exception: a reshape that computes one field from another. That one is written by the model as a query, checked the same way as everything else, and applied only after you approve it.
Does the AI agent plan my routes?
No. No language model produces a route, sets an optimisation parameter or evaluates a cost. The agent only calls a closed set of tools - read a dataset, query the data warehouse, profile a CSV, propose an import, apply a named parameter recipe, clone a dataset, launch an optimisation, compare two snapshots - and the routing itself is done by the same operations-research optimiser that runs your daily operations. This is the boundary Optrak draws everywhere it uses an LLM agent: the model sits at the orchestration layer and nowhere near the optimisation.
What stops the agent doing something expensive or wrong?
Three things. It can only call a closed set of tools, so it can’t invent a raw command or touch the optimiser’s internals. Anything that writes data or spends real compute - cloning a dataset, applying a change, landing an import, launching an optimisation - needs a person’s approval first: the agent proposes, you approve, then it runs. And a per-customer budget caps agent use, optimisation runs and external address-matching spend, so opening modelling up to more people does not open up an uncapped bill.
What can it actually change in my data?
Less than free-form chat might suggest, and that is the point. Settings that apply to a whole dataset go through a closed set of safe recipes - how orders may be combined, whether the 3D load planner runs, the units the data is read in, the data version. Changes to the data itself
- vehicle capacity, a depot’s position, driver shift patterns, how wide a site’s delivery window is - go through a change builder, which names the records it will touch, shows you each one before and after, and proves every record it writes is the original plus exactly the change that was declared and nothing else. Reading and querying are unrestricted within your permissions; everything that mutates is recipe-or-validated and approved by a person before it runs.
Which model powers the agent, and can it run on-premise?
The agent runs on Anthropic’s Claude today. Because the model only orchestrates the closed toolset, the integration is written against a provider-agnostic interface, so a different hosted or local model can be swapped in without touching the optimisation; the Anthropic adapter is the one wired up now. Storage follows the same principle: cloud object storage in production, local storage for inspection and testing.
How does the spreadsheet import work?
You point the agent at a CSV or XLSX. It profiles the columns - types, sample values, which columns look like links to existing data - and asks for clarification where the mapping is ambiguous. It then proposes a mapping into the Optrak data model, validates it (including UK mainland postcode lookup and geolocation), and turns it into an import you review before it lands. The import itself is a mutating step, so a person approves it before it runs.
Related
Technical Summary
The agentic window is a plain-language front end to the strategic workbench, implemented as a separate agent service the dashboard talks to over an RPC boundary (the dashboard never invokes the optimiser or the model directly). The agent calls a closed tool catalogue split into read-only tools (list datasets and snapshots, run a scoped SELECT against the data warehouse, query the input model, describe an entity, profile a CSV, compare two snapshots, and generate but not apply validated transform or import command files) and mutating tools (clone a dataset, apply a named parameter recipe, land a previously validated command file, and launch an optimisation). Read-only tools dispatch directly; every mutating tool needs a person’s approval (the agent proposes, an operator approves in the panel, a timeout counts as denial) before any optimiser or data-mutation JAR is invoked. A per-customer monthly budget meters agent tokens, optimisation minutes and external address-matching calls, refusing a turn before it starts if the customer is over budget. The model provider is pluggable by design (Anthropic’s Claude is wired today), and storage is pluggable on the same principle. The boundary matches the rest of Optrak’s AI posture: the LLM orchestrates a fixed toolset and never produces a route, sets an optimisation parameter or manipulates optimisation scripts; every figure’s credibility comes from the operational optimiser. Integration of the window with the agent service is still in progress; the feature is experimental.
See Optrak on Your Own Routes
Book a demo and we'll model your fleet, depots and constraints — and show the savings on real data.