Valem compared to the alternatives

If an AI agent has to keep numbers and rules straight, there are several ways to do it. This page compares Valem with the ones people usually reach for first, including the cases where the other option is the better choice.

  1. The short version
  2. Valem vs letting the LLM do the math
  3. Valem vs a code interpreter
  4. Valem vs hand-written application code
  5. Valem vs a rules engine
  6. Valem vs a form library with computed fields
  7. Valem vs a spreadsheet as a backend
  8. Try it

The short version

Approach Recomputes on every change Enforces invariants Explains a value Same answer every run Rules editable without a deploy
The LLM computes in the chat No No Only by re-asking No Yes
The LLM writes code and runs it (code interpreter) Only if re-run Only if coded By reading the code Yes, per script Yes, but each change is new code to review
Hand-written application code Yes, if every caller does it Yes, if coded By reading code and logs Yes No
Rules engine (Drools, json-rules-engine) Fires on facts Through rules Partly (rule firing logs) Yes Yes
Form library with computed fields In the UI only Field validation No Yes No
Spreadsheet as a backend Yes Weakly (data validation) By tracing cells Yes Yes
Valem Yes, in dependency order Yes, before commit Yes (explain, audit trail) Yes (pure core) Yes (spec evolution on a live model)

Valem vs letting the LLM do the math

This is the default and the comparison that matters most. An LLM can describe a loan, an invoice, or a tax rule very well. It is much less reliable at keeping the resulting numbers consistent over a conversation: a total stops matching its line items after an edit, a limit that was checked earlier is not re-checked, and arithmetic over many fields picks up small errors. Nothing tells you when that happens.

With Valem the LLM still does the part it is good at: it writes the rules as a ModelSpec. Valem does the rest. Every change recomputes the dependent values from the formulas, every invariant is checked before the change commits, and any value can be traced back to its inputs. The agent reads the result with get_state instead of recomputing it.

Pick the plain LLM when the answer is a one-off estimate that nobody will edit or rely on later.

Valem vs a code interpreter

Having the model write Python and run it fixes the arithmetic, but each answer is a new program. Rules live in throwaway scripts, state lives in the conversation, and a follow-up edit means writing and running the code again, hoping it still matches the last version.

A Valem spec is the program and the state, kept together. It is declarative JSON, so the runtime can validate it, run its embedded tests, and dry-run a change before applying it (validate_spec, test_spec, dry_run in the MCP tools). It is also safe to run without a sandbox, because expressions are JSONata, which has no file, network or process access; any I/O goes through declared effects.

Pick the code interpreter when the work is analysis: loading a CSV, fitting a curve, plotting. That is general computation, and Valem deliberately is not a general programming language.

Valem vs hand-written application code

Covered in detail in the FAQ. In short: code is the right answer for a few stable rules. Valem pays off when rules change often, must be auditable, or are generated by an LLM, because a rule change becomes a spec evolution on a live model instead of a release.

Valem vs a rules engine

Rules engines such as Drools or json-rules-engine match conditions and fire actions. Valem computes values in a dependency graph, closer to a spreadsheet than to an inference engine, and rejects any change that would break an invariant. The FAQ covers the differences.

Pick a rules engine when your problem really is event routing or classification (“if these facts hold, do that”) rather than keeping a set of derived values correct.

Valem vs a form library with computed fields

JSON Forms, Formik and similar libraries can show computed fields and validate input. The logic runs in the browser, so it is gone for any other client: an agent, a batch job, or the server that has to trust the result. Valem keeps the computation on the model itself; every client (UI, agent, API) writes to the same model and reads the same derived values. A spec can also carry a view definition, so the form is generated from the same document as the rules.

Pick a form library when the logic is purely presentational and nothing downstream depends on it.

Valem vs a spreadsheet as a backend

This is the closest relative: Valem is a spreadsheet’s recalculation model applied to a JSON document. The differences are what an application needs from it:

  • Structure. Fields have names and JSON paths, not cell addresses, and arrays of records ($.items[*].lineTotal) are first-class.
  • Invariants. A constraint can roll back a change; a sheet can only highlight it.
  • API and concurrency. Mutations are serialised per model and broadcast over WebSocket; agents connect over MCP.
  • History. Committed changes are logged and replayable, and with an audit store configured they land in a hash-chained, tamper-evident audit trail.

Pick a spreadsheet when a person will do the editing and nothing else needs to call it.

Try it

The quickest way to see the difference is to build something: the sandbox turns a plain-language description into a live model, and Connect your agent lets Claude or any MCP client drive one.