nMODL2
Business modeling with AI
Engine built
“Could you model my business for me?”
nMODL2 is a simulation engine for a business. A model describes the parts of the business, such as a packing team or a supplier, and how they deal with each other. Give the model a starting point and nMODL2 plays the business forward one event at a time, keeping every event it recorded.
An AI works with nMODL2 through MCP tools or a command line.
I’m building it so that an AI can write the model with you. You’ll bring company records and explain how the work gets done. The AI will write the model, ask about what it doesn’t understand, and revise it with you. Suppose orders are piling up. Before hiring another packer, you could test whether the problem is too little packing capacity or the phone calls that keep interrupting the work. nMODL2 runs the model, and you and the AI can follow the events that led to each result.
Do we need another packer?
Planned conversation, invented resultsYou & your AI
Could you model our order-fulfillment business?
I’ll start with these records. What usually holds an order up?
Packing. The same two people also handle customer calls.
Then the model needs both jobs drawing on the same two people’s time. I’ll set up the current workflow as the baseline, then try two changes against it: more packing capacity, and moving the calls to someone else.
Show me the queue in a chart.
An AI-written brief
Moving the calls leaves
fewer orders waiting.
The model assigns packing and calls to the same two people. In these runs, moving the calls reduces the packing queue more than adding capacity.
| Scenario | Orders waiting |
|---|---|
| Current workflow | 36 |
| Add packing capacity | 18 |
| Route calls elsewhere | 14 |
Who would answer them, and what other work would they have to put aside? We should include that work in the model before deciding.
A diagram drawn by your AI
Two people are
doing both jobs.
Both jobs draw on the same two people’s available time.
Next, we can include the other work done by whoever would take over the calls.
“Why should I believe that?”
It’s the right question to ask an AI about your business, and nMODL2’s answer is the record. A model is made of agents (not AI agents; here an agent is an actor in the simulation, like the stand or its supplier). To keep models easy to write and to understand, agents can only communicate through channels called contracts: one agent says something, and a contract delivers it to the agents that need to hear it. That is a narrow set of allowed interactions, but a flexible and rich one. And since nothing passes between agents any other way, every statement and every delivery is a row, and each row names the row that caused it.
The AI reads that record. It can’t write a row of it. Only running the model does that, and what the AI writes about a run is labeled as its interpretation. Here is the complete record of one run of the smallest model I have: a lemonade stand, three customers, and a supplier.
| # | Agent | What was recorded | Cause |
|---|---|---|---|
| 0 | Customer | seedIntentcount 3 · units 1 · price 2 | start |
| 1 | Customer | saidOrder placedunits 1 · price 2 | row 0 |
| 2 | Customer | saidOrder placedunits 1 · price 2 | row 0 |
| 3 | Customer | saidOrder placedunits 1 · price 2 | row 0 |
| 4 | Stand | heardOrder receivedvia customer_ | row 1 |
| 5 | Stand | heardOrder receivedvia customer_ | row 2 |
| 6 | Stand | heardOrder receivedvia customer_ | row 3 |
| 7 | Stand | saidRestock requestedunits 1 | row 6 |
| 8 | Supplier | heardRestock requestedvia supply_ | row 7 |
| 9 | Supplier | saidShipment dispatchedunits 1 | row 8 |
| 10 | Stand | heardShipment receivedvia supply_ | row 9 |
“But no model is ever right, is it?”
No. As the statistician George Box put it, all models are wrong, but some are useful. The record above is exact, but only about the model, and the model is an approximation of your business. So what you want is often the gist, not a number: not that the packing queue fell from 36 to 14, but what that did to whoever took the calls.
Conventional simulations hand you numbers. Frontier AI models are good at gist, because the lessons are already in them: they have read more about how businesses work than any person could. What’s hard is getting those lessons out, and a table of totals gives a model little to recognize.
So I invented a way for nMODL2 to record what a run was like for each agent, in the language those lessons were learned in. The events an agent hears and the state it keeps each carry a short, plain statement of what they mean, and after a run nMODL2 gathers every occurrence for an AI to read. I call this Qualia, the philosopher’s word for what an experience is like from the inside, like the taste of coffee. The statements only say what happened. What it adds up to is the AI’s reading, labeled as interpretation.
Chess programs made a leap when they stopped scoring positions with hand-written rules and used networks that had learned judgment from millions of games. I’m looking for the same leap in business. As the AI models improve, the same run will tell you more.
| Dimension | Meaning, and what was measured | Evidence |
|---|---|---|
| Stand | ||
| Customer demand | Customer lemonade orderorder units total 3 · order price latest 2 | rows 4, 5, 6 |
| Inventory | Lemonade inventory balanceinventory balance 2 | its own state |
| Inventory | Lemonade restock shipmentrestock shipment units total 1 | row 10 |
| Cash | Lemonade sales cash balancecash balance 6 | its own state |
| Supplier | ||
| Replenishment | Lemonade restock requestrestock request units total 1 | row 8 |
Reality gets a vote.
You record what actually happened, with its source. A later run replays those facts up to today and projects from there, and the difference between the earlier projection and what happened is reported as exact arithmetic. When the stand’s register counted four customers instead of the three the model assumed, the result was sales +1, cash +2, inventory −1. Nothing grades the forecast for you.
Built, and next.
Running today: the engine and its record, the agent-by-agent check, Qualia, and the comparison of a projection with what happened. nMODL2 has no AI of its own; the reading is done by whichever AI you connect. Written but not yet something an AI can call: ranking which agents’ experience changed most between two runs. Next: the AI writing the model with you, which is what the first question asks for.
How a model is built, checked, and kept honest
nMODL2 has its own modeling language. A model declares the agents, what each one hears and says, the contracts between them, and the shape of every message. Each agent’s rules are written in Python. The engine refuses what would break the record: an agent addressing another agent, a contract that changes a message in transit, or a rule that reads a clock or shared state.
Two models exist today: the lemonade stand above, and a vacation-rental business with eight agents, from occupancy and guests through stock, supplier, billing, and cash. Detail grows where it would change a decision. A supplier can start with one rule, ship on request, and later gain a model of its own stock and lead times while keeping the same contracts with the rest of the business.
Models have no clock and no dice. Run one again, in another process, and you get the same record, row for row. A finished run can also be checked agent by agent: each one is re-run alone and must reproduce its own rows and final state. If anything had passed between agents off the record, that check would fail.
Qualia is derived after a run and never during one. Rows that match an authored meaning become occurrences. Occurrences accumulate into an observation for each dimension of an agent’s experience, observations make up that agent’s profile, and a bounded window onto the profile is what an AI reads. Every step keeps references to the rows and meanings it came from. Nothing in the chain calls an AI, and none of it feeds back into a run.
Changes are tried as alternatives branched from the same starting point and compared on the same evidence. A model’s own rules can refuse one: ask the stand to serve more customers than it has lemonade for, and the run stops and says so rather than inventing a sale. Accepting a change is your decision, recorded as yours. Because every run keeps its complete record, you can bring a more capable AI to the same evidence later and ask again.
