Jax, the agent
Speak, and it becomes
Jax is Nexma's spatial intelligence agent. You describe what you want in plain language; Jax reads and writes the DataStore, reasons against the active Ontology, runs the engines when it needs to compute, and produces the artifact you would otherwise build by hand — a network design, a route plan, a spatial answer, a styled map layer. The interface is conversation. The output is real, auditable changes to your project.
Core concepts
Jax is not a chatbot bolted onto a map. It is an agent that operates a live world model the same way an engineer operates a codebase.
- It works the world model, not a copy. Every read and every write lands in the DataStore, the single source of truth. When Jax moves a transformer or adds a sensor, the map, tables, graph, and panels all react at once — no export, no sync.
- It knows your domain. Jax reasons against the active Ontology, so it already understands your entity types, relationships, and constraints. You do not restate the rules in every prompt.
- It calls the engines. When a question crosses from "look it up" into "compute the answer," Jax dispatches to the MathEngine, GeoEngine, InsightEngine, or SatelliteEngine.
- It shows its work. Every action is visible on the timeline. You can step back, ask why, and replay the reasoning grounded in the actual run.
Ask Jax for the weather and it will offer to add a weather feed to your project instead. It answers by changing the world model, not by reciting trivia.
The eight primitives
Jax acts through eight generic primitives — never through domain-specific tools. The same eight cover fiber, water, electric, defense, logistics, or any domain the Ontology describes. This is what keeps the agent safe, portable, and auditable: every action is one of eight known shapes, scoped and reversible.
| Primitive | What it does |
|---|---|
Read | Read a file from the DataStore, with offset and limit |
Write | Create or overwrite a file with full content |
Edit | Patch an existing file by find and replace |
Delete | Remove files by path or pattern |
Glob | Find files by pattern |
Grep | Search across file contents |
Run | Deterministic geo-math — haversine, centroid, snap-to-roads, isochrone |
Solve | Optimization dispatch — MIP, VRP, CP, simulation, heuristic, routed to browser or server |
Domain knowledge — standards, hierarchy rules, cascade depth — lives in the Ontology and the active Skill, not in tool code. The primitives stay generic; the meaning comes from the world model.
How it works
Every Jax request runs the same loop: read the relevant state, reason against the Ontology, compute through the engines where needed, write the result, and render it on every surface.
1You: "Plan distribution for every household in this polygon. Snap to existing duct."
2 1. Read — load the polygon, the household layer, the duct network
3 2. Reason — apply the active Ontology's rules and constraints
4 3. Solve — formulate the layout, dispatch to the MathEngine
5 4. Write — commit the design to the DataStore
6 5. Render — map, tables, and panels update; the timeline records each stepYou watch each step as it happens. Nothing is a black box, and nothing bypasses the rules and data you gave it.
How to talk to Jax well
A good prompt has three pieces. State them, and skip the rest.
- Objective — what you want produced (a network, a route, a layout, an answer).
- Scope — where it applies (a polygon, a layer subset, a time window).
- Constraints that matter to you — anything beyond what the Ontology already enforces.
Do not restate rules Jax already knows. If your Ontology caps splitter ratios at 1:32, you never mention it. Be specific only about what is non-default.
Pointing at things that already exist beats describing them in prose:
Use the polygon I just drew as the scope. Snap routes to the road network already loaded. Avoid existing duct.
Jax navigates your project on its own. You do not spell out where things live.
Iterate in small bites, and ask "why"
You can ask for the whole world in one prompt, but iteration is cheaper and easier to verify. Build up step by step, inspect on the map, and roll back any time.
- "Plan the cabinet locations."
- (Inspect.) "Move cabinet 7 closer to the existing handhole."
- "Now route distribution from those cabinets."
- "Validate against the constraints and list any violations."
Jax is built to explain itself. Use "why" aggressively — both to learn the system and to catch silent mistakes.
- "Why did you put cabinet 4 there?"
- "What was the cost driver?"
- "Which constraints were binding?"
When Jax pushes back
Sometimes Jax tells you a request is infeasible — the polygon has no road access, the constraint set is over-specified, the math did not converge. Take that seriously. Loosen a constraint, narrow the scope, or ask Jax for a counter-proposal. A confident answer to the wrong problem is worse than an honest "this cannot be done as stated."
Where to go next
- Nexma AgentEngine — compose, schedule, and observe Jax in repeatable workflows.
- Skills — the domain packages that reconfigure Jax for fiber, water, electric, and more.
- The agent-computer architecture — why the world model is the interface.
- The eight primitives — the full reference for how Jax acts.