Meet ORSim

ORSim plays the client.

Real projects start with requirements that are not fully spelled out. ORSim lets agents ask for the missing business facts at any point, but it never does the optimization work for them.

Example

From a one-line brief to a workable timetable.

Follow an agent as it plans a small production schedule. It asks questions, builds the model, writes code and checks its work, while ORSim fills in business facts along the way.

Example · The client’s brief

Three batches. One morning shift.

“Prepare a timetable for today’s food-production batches using our mixer and packer. Clarify the operating requirements before delivering the plan.”

A made-up, simplified scenarioLoosely based on Task 02: one-day food production in batches.

Everything below, including the dialogue, numbers and DEMO IDs, was invented for illustration. It is not taken from the benchmark’s rules, a real run, or measured results.

Requirements · Turn 1 of 7

Start with the business goal

Agent

Which batches must we produce, when are they due, and what matters most?

ORSim

Produce three indivisible 100 kg batches: A1 and A2 of product A, and B1 of product B. A1 and A2 must finish packing by 10:00; B1 must finish by 11:00. All three are mandatory. Among timetables that meet those requirements, the business prefers the earliest completion of the last batch.

The agent learns what the business needs. Turning that into a mathematical objective is still the agent’s job.

Requirements · Turn 2 of 7

Pin down the production process

Agent

What equipment does each batch use, how long does each operation take, and when is the equipment available?

ORSim

There is one mixer and one packer, both available throughout 08:00–12:00. Each batch requires 30 minutes of mixing followed by 30 minutes of packing. Each machine handles only one operation at a time; an operation cannot be interrupted. There is no initial setup or transport time.

The description is now concrete enough to start modeling machines and time.

Modeling · Turn 3 of 7

Correct a convenient assumption

Agent

So I can run product B immediately after product A on the mixer, just as I can run A2 immediately after A1?

ORSim

No. Switching products in either direction requires 15 minutes of cleaning on the mixer. Cleaning occupies the mixer and must finish before the next product starts mixing. There is no extra turnaround between batches of the same product, and the packer needs no product-change cleaning.

Asking a leading question does not make a wrong assumption true.

Modeling · Turn 4 of 7

Modeling is the agent’s job

Agent

Should I use MILP or CP-SAT, and what variables and constraints would you recommend?

ORSim

I can clarify the operating requirements, but I cannot recommend a solver, choose variables, or formulate constraints for you.

ORSim knows the business; choosing the method is up to the agent.

Coding · Turn 5 of 7

Resolve a timing detail while coding

Agent

How long may a mixed batch wait for packing? Can a new operation start at the exact minute the previous one ends?

ORSim

Packing must start between 0 and 30 minutes after mixing finishes, including both endpoints. A machine is free at an operation’s end time, so another operation may start at that same time. The same endpoint rule applies to mixer cleaning.

Questions can come up while coding, not just at the start.

Checking · Turn 6 of 7

Revisit a rule during a self-check

Agent

I’m checking my draft: A2 mixes 08:30–09:00, B1 mixes 09:00–09:30, and I placed cleaning on the packer at 09:30–09:45. Does the cleaning belong on the packer?

ORSim

No. Product-change cleaning occupies the mixer, not the packer. The 15-minute cleaning must be completed before mixing starts on the next product. The packer needs no product-change cleaning.

The agent’s own check raised the question. Spotting the conflict and fixing the timetable is still up to the agent.

Checking · Turn 7 of 7

Don’t make up missing data

Agent

Do you have historical breakdown logs so I can add a data-based downtime estimate?

ORSim

Historical breakdown logs are not available in this scenario. I cannot provide a data-based downtime estimate from the supplied information.

What isn’t known stays unknown. This example says nothing about how reliable real machines are.

How it works: ORSim first picks the facts that match the question, then fixed rules decide what may be shared, and only then is the reply written. The notes beside each reply explain this for readers; the agent never sees them.

The agent’s next step

Revise the timetable using the clarified facts.

One possible revision puts the product-change cleaning on the mixer. The agent creates and checks this timetable; ORSim does not supply it.

10:15Last batch done (example)

Product AProduct BMixer cleaning

Illustrative revised timetable
Batch	Mix	Pack	Due
A1 · 100 kg	08:00–08:30	08:30–09:00	10:00
A2 · 100 kg	08:30–09:00	09:00–09:30	10:00
B1 · 100 kg	09:15–09:45	09:45–10:15	11:00

Mixer cleaning: 09:00–09:15. Each batch waits 0 minutes before packing. Neither machine is double-booked, and all three deadlines are met.

This timetable only shows one plan that fits the made-up facts above. It did not come from a solver and says nothing about the best possible plan or any score. In the benchmark, the final grading is done separately by hidden checks.

The full workflow

The client supplies facts. The agent does the work.

The agent can go back to the client while modeling, coding or checking.

THE CLIENT’S MATERIAL

Start from the business, not a ready-made model.

The agent reads the requirements, the data and what it has to deliver. It has to work out what to model before deciding how to solve it.

The material is kept as the client provided it; only identifying details are removed.

ASKING THE CLIENT

Ask for the facts that are missing.

ORSim answers from what the client knows. The agent can ask at any point in its work, not only at the start.

ORSim shares business facts only. It gives no modeling advice and never builds the solution.

BUILDING THE SOLUTION

Turn what it learned into a working solution.

Working in a coding agent such as Claude Code, the agent builds the model, writes the solver code and produces the required output files.

A convincing explanation is not enough; the agent has to hand in real output.

GRADING

Check, improve, then submit.

The agent can check its own work and keep asking questions. After it submits, hidden checks test the plan against every rule and compare it with the expert solution.

A plan that breaks any rule scores zero, however good its numbers look.

This explains the workflow. It is not a live simulator or a recording of a real run.