Every planning vendor now has an “AI agent.” Most of them are a large language model connected to your data through a chat window. They can summarize last week’s performance, draft an email to a supplier and answer questions about a spreadsheet. What they can’t do is reliably produce a production schedule you would actually run.
That isn’t a criticism of language models. It’s a matter of fit. Understanding the factory, computing the plan and reacting to change are three different jobs — and an agent that only has a language model is missing two of them.
Three jobs, three layers
We built Convect as three layers, each owning one of those jobs:
| Layer | The question it answers | What it actually does |
|---|---|---|
| Contour ontology | Does the system understand your operation? | Captures line capabilities, routings, changeover rules, material substitutions, equipment constraints and skills as one semantic network. Traces the impact of any change. New plants and lines are understood the moment they’re registered. |
| Optimization engine | Is this the best feasible plan? | Turns planning into a large-scale mathematical model and solves it under every capacity, material, due-date and routing constraint. Optimizes production, materials, inventory and transport together, and re-solves incrementally when data changes. |
| Planning agents | What do we do now that something changed? | Sense → reason → decide → act → learn. Replan automatically around rush orders, breakdowns and late materials, diagnose root causes, and send explained recommendations for human approval. |
Contour stands for Convect Ontology Unified Representation. It isn’t another master-data table. It is an explicit representation of your business rules — the things that used to live in your planners’ heads and in the comment column of a spreadsheet.
One rush order, all three layers
Take a familiar situation: a large rush order arrives and has to fit into a schedule that’s already full.
- Order arrives. An agent picks it up and classifies it as a rush order.
- Impact analysis. The ontology resolves which materials, lines and warehouses the product depends on. The agent traces the graph and finds the line it normally runs on is fully loaded this week.
- Options generated. The ontology supplies the set of qualified alternate lines and their process constraints. The optimizer finds the best ways to fit the order — for example, resequencing a different line and deferring low-priority work.
- Trade-offs evaluated. Each option is scored on cost and service. Another agent checks that procurement and logistics can support it.
- Decision. The recommendation and its reasoning go to the planning manager for one-click approval.
- Learning. The decision path is recorded so the next similar order is handled better.
Look at steps 2 and 4. The ontology defines what “feasible” means. The optimizer compares feasible options. The agent gets the conclusion in front of the person who decides. These are not three separate features — they’re one chain, and the chain breaks if any link is missing.
What breaks when a layer is missing
A language model without an ontology can converse and summarize, but its reasoning has no traceable business structure behind it. Ask it whether a line can run a product and it will give you a fluent, confident answer that may be wrong — because nothing it knows encodes that the mold for that product is mounted on a different line. The ontology gives the agent context it can follow relationship by relationship, and that you can audit afterwards.
Rules without optimization can produce a plan that’s feasible, but you never know how far it is from the best one, or which constraint is holding the result back. Teams end up endlessly re-ordering rule priorities — which is still a human doing trial and error, just inside software.
Optimization without agents makes the first plan easy. Everything after that is hard: every rush order, breakdown and shortage still needs a person to notice the change, update parameters, re-run the whole model and manually compare the new plan to the old one.
What a language model is actually good for here
None of this means language models don’t belong in planning. They’re excellent at what they’re good at: understanding a question asked in plain English, explaining why a plan looks the way it does, drafting the message to a customer about a revised date. In Convect, that’s exactly their role. The numbers — quantities, dates, line assignments — always come from the optimizer working on the ontology, so they satisfy your constraints by construction.
The bottom line
The ontology provides understanding. The optimizer provides answers. Agents combine the two into a system that can run on its own — inside guardrails you set. The planner’s job moves from doing arithmetic to making decisions.
If you’re evaluating agentic planning tools, ask each vendor where their numbers come from and how their agent knows what’s feasible in your plant. We’ve written up seven questions to ask, and you can see how the layers fit together on our platform page.
