• 

  logo

• 

  main operating screen

• 

  scheduling screen

About the Project

Inspiration

Scheduling sounds simple until real-world constraints begin interacting: machines become unavailable, urgent jobs receive deadlines, tasks depend on one another, and operators override assignments.

Traditional optimization software can solve these problems, but describing a model often requires specialized mathematical knowledge. AI assistants make natural-language interaction easier, but an LLM should not be trusted to invent a schedule and claim it is valid.

ConstraintLab combines the strengths of both:

Humans express goals and judge trade-offs. AI agents translate intent into structured actions. A deterministic solver computes and validates the schedule.

We built ConstraintLab to explore what an agent-native optimization workspace could look like—one where the human interface, AI agent, solver, and audit history all operate on the same canonical application state.

What It Does

ConstraintLab is a browser-based job-shop scheduling workspace.

Users can:

• View jobs, machines, dependencies, deadlines, and downtime windows.
• Inspect schedules through an interactive Gantt chart.
• Add or edit scheduling constraints manually.
• Ask a WebMCP-capable AI agent to inspect and modify the model.
• Run a real mixed-integer linear programming solver in the browser.
• Detect when a solved schedule becomes stale after the model changes.
• Receive deterministic explanations when a model is infeasible.
• Review every human, agent, and solver action in an audit timeline.

A typical interaction looks like this:

“Machine 2 will be unavailable between 1 PM and 3 PM, and Job 7 must finish before noon.”

The agent discovers ConstraintLab’s site tools, adds typed constraints, and requests a solve. The HiGHS solver—not the language model—computes the resulting schedule.

If another request creates a contradiction, ConstraintLab reports the genuine infeasible result and identifies the relevant constraints using deterministic conflict analysis.

How We Built It

ConstraintLab is built with React, TypeScript, Vite, Zustand, Zod, Web Workers, WebAssembly, HiGHS, WebMCP, Vitest, and Netlify.

The most important architectural decision was to maintain one canonical application state.

Human interface ──┐
                  ▼
            Domain actions
                  ▲
AI agent ─────────┘
                  │
          Canonical Zustand store
             ├── Solver
             ├── Gantt chart
             └── Audit timeline

The interface and WebMCP handlers call the exact same domain actions. There is no separate “agent state” or hidden model that can drift away from what the user sees.

ConstraintLab exposes nine typed site tools:

get_problem_state
add_job
update_job
add_constraint
remove_constraint
set_objective
solve_problem
get_solution
analyze_infeasibility

Every tool input is validated with Zod, and write operations are validated again inside the domain layer. Agent arguments are treated as requests—not as trusted data.

For optimization, we compile the scheduling problem into a CPLEX LP-format model and send it to HiGHS running inside a Web Worker. This prevents the WebAssembly solver from blocking the interface.

The objective is to minimize makespan:

$$ \min C_{\max} $$

For every job (j), completion must satisfy:

$$ C_{\max} \geq S_j + p_j $$

where (S_j) is its start time and (p_j) is its duration. Precedence, deadlines, machine assignments, availability windows, and non-overlapping jobs are represented as linear constraints. Binary ordering variables handle jobs that may compete for the same machine.

The resulting assignments are translated back into application objects and applied through a single solver-result domain action.

We also track a modelVersion. Every structural edit increments this version, and every solution records which version it solved. If the two differ, the interface immediately displays:

Model changed — re-solve required.

Challenges We Ran Into

One major challenge was correctly separating language understanding from mathematical correctness. The agent is useful for translating a human request into typed tool calls, but it must never become the scheduling engine. Keeping that boundary strict influenced the entire architecture.

The solver integration was another challenge. HiGHS accepts LP-format text rather than a convenient JavaScript model object, so we built an explicit model compiler and solution translator. Variable names had to remain stable enough to map solver columns back to jobs and resources.

Scheduling downtime is more complicated than adding a simple bound. A job must occur either before or after an unavailable window, which requires additional binary decisions and big-(M) constraints.

Infeasibility explanations were also difficult. A solver can report that a model is infeasible without producing an explanation suitable for a user. Instead of asking an LLM to guess, we built typed, rule-based checkers that examine deadlines, precedence chains, locked starts, resource assignments, and machine availability. The generated summaries are based on computed scheduling facts.

Finally, WebMCP is still an emerging browser capability. We needed feature detection, top-level tool registration, a fallback path, and a clear unavailable state so that the human scheduling interface remains functional even when WebMCP is not enabled.

Accomplishments That We’re Proud Of

We are especially proud that ConstraintLab demonstrates a complete agent-to-solver loop rather than a simulated AI demo.

• The AI agent modifies the same state that the human sees.
• The schedule is computed by a real deterministic MILP solver.
• Constraints have stable IDs and structured types.
• Invalid agent inputs are rejected safely.
• Solver work runs outside the main browser thread.
• Model edits automatically invalidate stale solutions.
• Infeasibility explanations come from deterministic analysis.
• Every human, agent, and solver action is auditable.
• The entire application works without an AI agent.
• The complete optimization stack runs inside the browser and can be deployed as a static application.

Our headline demo intentionally creates a real contradiction involving Job 4, Machine 2, machine downtime, and a deadline. The solver returns an actual infeasible status, and ConstraintLab identifies the relevant conflict instead of showing a scripted response.

What We Learned

We learned that the most valuable role for an AI agent in optimization is not solving the mathematics itself. Its value is translating intent, operating tools, and helping users navigate the model.

Typed tools are essential. Allowing an agent to submit arbitrary mathematical expressions would make validation, auditing, and explanations significantly less reliable. A deliberately small vocabulary of structured constraints creates a much safer system.

We also learned that shared state is more important than chat history. The collaboration feels trustworthy because every agent action appears immediately in the visual workspace, and every human edit is visible to the agent during its next inspection.

Finally, infeasibility is not merely an error state. In real optimization work, discovering why requirements conflict can be as valuable as finding an optimal schedule.

What’s Next for ConstraintLab

The current version deliberately focuses on one excellent scheduling loop. Future versions could expand that foundation with:

• Multiple optimization objectives, including lateness and utilization.
• Saved scenarios and side-by-side solution comparison.
• Checkpoints and reversible model changes.
• Transactional batches of agent-proposed changes.
• Interactive rescheduling and assignment locking.
• Richer deterministic conflict analysis.
• Larger industrial scheduling models.
• Import and export support for operational datasets.
• Additional optimization domains such as workforce, classroom, and logistics planning.
• Collaboration features for teams reviewing the same model.

The longer-term vision is for ConstraintLab to become a general agent-native optimization workspace: natural enough for anyone to describe a problem, rigorous enough for experts to trust the answer, and transparent enough for humans to remain in control.

Built With

• and-the-challenges-you-faced.-format-your-story-in-markdown
• highs
• how-you-built-your-project
• react
• tailwind-css
• typescript
• vite
• web-workers
• webassembly
• webmcp
• what-you-learned
• zod
• zustand