Custom constraint optimization: the utility scheduler no off-the-shelf product could build

Every off-the-shelf scheduling product makes the same quiet assumption: that your constraints are independent. Assign the crew, then check the permit, then check the location, each rule evaluated on its own. That assumption holds for most scheduling, which is why those products exist and sell well.

It breaks the moment your constraints interact — when satisfying one changes whether another can hold at all. That’s where this project started, and it’s why custom constraint optimization was the answer instead of another subscription. The engine reached 96% workday efficiency across more than a dozen interacting constraints.

TL;DR: Custom constraint optimization is what you build when scheduling rules interact, meaning satisfying one changes whether another can be satisfied. Off-the-shelf schedulers evaluate rules one at a time by design, so they can confirm a schedule is legal but can’t search for the least wasteful legal schedule. A constraint-programming engine built on lightweight solver libraries and deployed serverless hit 96% workday efficiency across more than a dozen coupled constraints. The 2026 addition: an AI agent doesn’t replace the solver, because a solver’s answer carries a guarantee and an agent’s doesn’t. What an agent is good for is the part before the solver — writing the constraints down.

The problem: constraints that talk to each other

Utility field work is a scheduling problem disguised as a logistics problem. On any given day you’re placing crews against jobs, and the rules aren’t a checklist — they’re a web:

• Geospatial separation. Certain work can’t happen too close to other work at the same time, for safety and regulatory reasons. Where you place one job constrains where you can place others.
• Per-block permit status. Every address in a block carries its own permit state, and a job can’t start until the relevant permits across the block clear — a combinatorial constraint all on its own.
• Permit lead times. A job isn’t schedulable until its permit clears, and permits have variable, sometimes unpredictable lead times. The calendar bends around paperwork.
• Crew skills and certifications. Not every crew can do every job. The eligible set changes per task.
• Travel and routing. Crews move through physical space; a schedule that ignores travel is a schedule that doesn’t survive contact with the morning.
• Equipment availability. Shared, finite resources that two jobs can’t both use.
• Time windows. Hard start and finish boundaries on individual jobs.

…and that’s the short list. Counting the sub-rules each of these expands into, the engine juggles more than a dozen interacting constraints at once.

Each constraint is manageable alone. The difficulty is that they’re coupled. Move one job to satisfy a spatial-separation rule and you’ve changed the travel pattern, which changes which crew can reach the next job inside its time window, which interacts with a permit that won’t clear until Thursday. A human scheduler holds maybe four of these in their head and satisfices. A rules engine checks them in sequence and produces something legal but wasteful — idle crews, and trucks crossing the service area for no reason anyone can defend.

Why off-the-shelf products can’t do this

SaaS schedulers are built for the common case: independent constraints, evaluated one at a time. That’s a deliberate design choice — it keeps the product general and the interface simple. But it means the product literally cannot reason about constraints together. It can tell you a schedule is legal. It can’t search the enormous space of legal schedules for the one that wastes the least time, because it doesn’t model the interactions that make one legal schedule far better than another.

You can feel this when a product “almost” fits and you find yourself doing the real optimization by hand in a spreadsheet next to it. That spreadsheet is the tell. It means the hard part of your problem lives outside the tool, and you are the solver. That’s the moment to stop shopping and start building — not because custom is always right, but because this specific shape of problem is what operations research exists for. The build-versus-buy question is really a question about which of your constraints a template can express.

The build: constraint programming, kept lightweight

The engine models the day as a constraint-satisfaction and optimization problem. Jobs, crews, time, and resources become variables. The rule families become constraints over those variables. The objective is workday efficiency — minimize idle time and wasted travel, maximize productive on-site time — subject to every hard constraint holding simultaneously.

The solver then does what a human and a rules engine can’t: it reasons about the constraints jointly and searches for an assignment that satisfies all of them while optimizing the goal. When a permit pushes a job, the engine doesn’t just flag it. It re-plans the surrounding work so the day stays dense.

Two engineering decisions kept this practical rather than academic.

Lightweight libraries over heavy platforms. This was built with compact Python solver libraries, not a sprawling enterprise optimization suite. The problem was hard; the deployment didn’t need to be.

Serverless deployment. Because the footprint was light, the whole thing runs serverless. It spins up to compute a schedule and spins down. No always-on infrastructure, no standing cost for a tool that’s invoked when the schedule changes. Operations-research-grade results on commodity infrastructure.

The result: 96% workday efficiency

The number that matters is 96% workday efficiency — the share of the workday spent on productive, on-site work rather than idle time, avoidable travel, or schedule churn. Across more than a dozen interacting constraints, the engine consistently produced schedules a human couldn’t match and a product couldn’t compute, and it did it cheaply enough to run on demand.

The 2026 question: can’t an agent just do this?

That question didn’t come up when this was built. It comes up in every scoping call now, so it’s worth answering directly.

No, and the reason is specific. What you buy from a solver is a guarantee. It returns an assignment in which every hard constraint holds at the same time, or it tells you no such assignment exists. That second answer is often the more valuable one. “There is no legal schedule for Thursday” is a staffing decision, not a scheduling one, and you want to learn it on Tuesday.

A language model will produce a schedule that looks right. Looking right is the wrong property. To know whether to trust it you’d have to write a checker for all dozen-plus constraints and run the output through it — and once that checker exists you have written most of the constraint model. At that point the solver is the cheap part. You’ve done the expensive work and stopped one step short of the guarantee.

Where an agent earns its place is upstream, and it’s the part everyone skips: turning “we don’t put two crews on the same block when the main’s open” into something a solver can evaluate. That’s an interview problem and a documentation problem. It is also, reliably, where these projects die.

The evidence on that has gotten less anecdotal. Enterprise Management Associates surveyed 202 enterprise IT and security leaders for a report published on 31 August 2026, commissioned by Cequence, a vendor that sells API and agent security — worth stating, since it shapes which questions get asked. One chart in it went unremarked. Asked which factors were major contributors to agentic AI pilots that stalled, were paused, or were abandoned, respondents put data quality or integration issues at 53.0% — the single most-cited factor. Model performance and reliability came in at 40.1%. Unclear ROI or business case, 35.1%.

The model was not the top reason. It was fifth on a list its own vendors write the headlines about.

The biggest lever is usually a constraint that isn’t real

There’s a result worth sitting with here. A team at Georgia Tech — Liam Jagrowski, Kevin Dalmeijer, Tinghan Ye, and Pascal Van Hentenryck — published a constraint-programming model for paratransit that jointly optimizes route planning and shift scheduling, with a case study in Savannah, Georgia. The paper was revised in May 2026. Their CP model was competitive with an AI-accelerated column generation framework and served significantly more requests than current practice.

Then this, from their own abstract: allowing shifts to start at times other than exactly on the hour yielded an additional 5% improvement in requests served.

Nobody improved the algorithm to get that 5%. Somebody asked whether shifts starting on the hour was a requirement or a habit, and it turned out to be a habit. The constraint was inherited from a scheduling spreadsheet, not from the operation.

Every project like this has one of those. In the utility case, the equivalent question was which permit states genuinely block a start and which were the dispatcher being careful — a distinction nobody had written down, because the same permit reads pending in one system and submitted in the other and everyone had learned to squint at it. Sorting that out moved more schedule than any tuning did.

You don’t find those by improving the solver. You find them by making somebody state the rule out loud and then asking who enforces it.

Where your scheduling problem actually belongs

Shape of the problem	The tell	What fits
Rules are independent; any legal assignment is fine	Nobody touches the schedule after it generates	Off-the-shelf scheduler
Rules are independent, but some legal schedules cost far more than others	Dispatch hand-tunes the output most mornings	Off-the-shelf plus a routing optimizer
Rules interact — satisfying one changes whether another can hold	A spreadsheet open next to the product	Custom constraint optimization
Rules interact and nobody states them the same way twice	Every rule ends with “depends who’s asking”	Process discovery first. No solver yet
You want an agent to produce the schedule	You can’t define “correct” without a person checking it	An agent to help write the constraints; a solver to satisfy them

The fourth row is the one that costs the most money and gets diagnosed the least. A team in that row usually buys something from row one, and the mismatch shows up eighteen months later as a change request nobody can scope.

The solver is not the expensive part

There’s a persistent assumption that this kind of work requires an expensive commercial optimization license. The benchmark data says otherwise. A 2026 comparison published in the Proceeding Series of the Brazilian Society of Computational and Applied Mathematics tested mixed-integer and constraint-programming solvers across 80 Taillard job-shop instance sets. Mixed-integer programming was promising on small instances. Constraint programming gave the best average relative deviation and stronger performance on the large ones — and the free, open-source OR-Tools solver sat in the same comparison class as the commercial products.

So the algorithmic layer is commodity, and increasingly good. CP-SAT will tell you a day is infeasible in under a second. It just won’t tell you which rule to go argue with.

That’s the whole shape of the work. The solver is a library. The constraint model — your rules, written down precisely enough that a machine can hold them all at once — is the deliverable, and it’s the one thing no vendor can sell you, because it’s a description of how your operation actually runs. Which is also why the same layer decides whether anything else you automate works, and why the parts of a workflow that need a guarantee shouldn’t be the probabilistic ones.

Most companies looking at this already have the answer sitting in a spreadsheet next to a product they pay for. That spreadsheet is the specification. If you can read it out loud, it can be built — and if you can’t, that’s the project, and it isn’t an AI project.