The eight primitives
The only tools Jax uses
Jax operates the world the way a developer operates a filesystem. Eight generic primitives — and only eight — let one platform design fiber networks today and water grids tomorrow without rewriting the agent.
Core concepts
The agent has no domain-specific tools. There is no add_fiber_splitter and no route_water_main. There is Read, Write, Edit, Delete, Glob, Grep, Run, and Solve. A water valve and a fiber splitter are both files in the DataStore, and both are manipulated with the same primitives.
This is the design choice that makes Nexma horizontal:
- The domain comes from the Ontology. What exists, how it connects, and which rules bind it are defined in the typed world model, not in tool code.
- The capability comes from the tools. The eight primitives are everything the agent can do mechanically.
- The knowledge comes from the system prompt. Domain expertise — splitter ratios, voltage drop, retention rules, TIA-598 — lives in Skills as prompt and validators, not as hardcoded tools.
When the schema changes, the agent does not. Swap the ontology and a fiber planner becomes a logistics planner with the same eight tools.
The eight primitives
| Primitive | Purpose |
|---|---|
| Read | Read any file in the DataStore, with offset / limit pagination |
| Write | Create or overwrite a file with full content |
| Edit | Patch an existing file in place, find-and-replace style |
| Delete | Remove files by path or pattern |
| Glob | Find files by pattern across the store |
| Grep | Search file contents at planetary scale |
| Run | Deterministic geo-math — haversine, centroid, snap-to-roads, route-along-roads, isochrone |
| Solve | Optimization dispatch — MIP, VRP, CP, simulation, heuristic |
The first six are the file primitives; they give humans and agents one consistent, safe interface to every object in the store. Run and Solve are the compute primitives — Run for fast, deterministic geometry and Solve for optimization handled by the MathEngine.
How it works
Each primitive does one thing, and they compose. A small task reads, computes, and writes:
1Read designs/current/route.geojson
2Run route_along_roads(start, end) → path geometry
3Write designs/current/route.geojson → updated routeA larger task searches, optimizes, and patches:
1Glob layers/**/*.geojson → candidate inputs
2Grep "status":"unserved" layers/ → demand points
3Solve { family: "mip", objective: "min cost", constraints: [...] }
4Edit designs/current/plan.json → apply the optimized planNotably absent:
- No Rename — compose it from
Write+Delete. - No Mkdir — directories are implicit in paths.
- No Bash — general shell is split into
Run(deterministic geo-math) andSolve(optimization), so every computation is scoped and reproducible.
Why generic, not domain-specific
A domain-specific toolset grows without bound. Every new entity type, every new domain, demands new tools, new validators, and new agent training. The tool surface becomes the bottleneck.
Generic primitives invert that. The tool surface is fixed and small, which means:
- Safety. Eight well-understood operations are easy to scope, permission, log, and reverse. Every action the agent takes is one of eight known shapes.
- Portability. A workflow built for one domain ports to another by swapping the ontology — the steps are still Read, Write, Solve.
- Auditability. Because there are only eight verbs, the audit trail is uniform and replayable across every domain.
Domain knowledge belongs in the system prompt and the ontology's constraints — never in tool code. That separation is what lets the same agent operate a water utility, an electric grid, a drone corridor, and a logistics network.
Where to go next
- See where the primitives operate: DataStore-first architecture.
- Learn how
RunandSolveexecute: The Agent Computer. - See how domain knowledge is packaged: Skills.
- Go deeper on optimization: MathEngine and GeoEngine.