Agent Engineering with Arxo

Build an agent whose answers come from a pinned canon — a law, a standard, a methodology compiled to an executable model — instead of from the model’s memory. The agent talks to the person, collects the facts, and explains the result; the engine decides, and every answer can be replayed from its hash.

Most products put the canon underneath and never show it: the model calls a tool named after the task, and the application answers it with the engine. Some agents explore canons themselves over MCP. This section covers both and starts with a running agent of the first kind.

A few terms recur on every page:

• Canon — a published executable model, pinned by name and version: norms or methods, their source text, and the questions it is built to answer. Law is the first subject, not the only one.
• Typed facts — the inputs a question reads, in the shape the canon declares. A fact that does not fit is refused before evaluation.
• Provenance — where a fact came from: the person’s message, a quoted passage of a document, a human decision.
• Pinned context — what fixes an answer for replay: the canon and its version, the facts, and the date of law. A person names that date; the agent never assumes today.
• Grounds — the facts and rules a conclusion stands on, with the sections of the source they come from.
• Reading — a named interpretation of an ambiguous norm. A person chooses it; the agent passes the choice in.

Build your first agentRead the agent contract

Who this is for

You build applications or agents and are comfortable with APIs and typed data. You do not need to know how canons are compiled. If you have never seen an Arxo answer, read How to read an answer first.

Role	Carries
Canon author	the executable model, its pinned sources and its question cards
Application developer	domain tools, transport, validation, storage, presentation
Agent	the dialogue: eliciting facts, calling tools, explaining within the answer’s bounds
Human principal	what no software decides: the date of law, readings, assumptions, publication

Reading routes

• Ship a product on a canon — Choose an integration pattern, Build your first agent, Collect facts and evidence, Read answers, Evaluate, debug and upgrade.
• Build an agent that finds the question itself — Connect and discover, Pin context, editions and time, Read answers.
• Run a multi-step task — Follow a task guide, Cases and processes, Human decisions, interpretations and scenarios.
• Before release — The agent contract, Safety and reliability, Prepare and publish an answer.

Assist formalization and review is about a different job: an agent that helps build or review a canon rather than apply one.

Examples used across the section

• The first agent — a Claude Agent SDK agent with one domain tool, period_end, over de.bgb.fristen@0.1.0 (periods of the German Civil Code). The engine runs locally through @arxo/law; the model never sees Arxo. Complete facts give an end date with its section and hash; a missing fact gives an empty result that the agent must not fill.
• A — one labour-law question over MCP — an agent searches for feeding_break_too_short in kz-labour-code (Labour Code of Kazakhstan), reads its inputs, collects facts and asks. It shows the pattern where the agent explores the canon itself.
• B — a multi-step document — the uncertainty-report task guide of the jcgm.gum measurement model: steps, stops, open fields and the finished document. It is a methodology, not state law.

Every example carries an explicit status: ran locally, ran via a named MCP endpoint, fixture, labeled pseudocode, or not run with the reason and a reproduction. Pages never show invented output.

Instructions for an agent that applies a canon

The reusable instruction set is the apply-canon skill: the engine decides; the agent routes, asks and copies; a person names the date of law; a stop is not an answer. It ships in the example bundle under instructions/apply-canon. The pages explain the reasons; the skill is what you give the model. Obligations that must hold even when the model misbehaves belong in your application code, not only in instructions.

What this section does not do

It does not add an agent framework, an engine, a protocol or a scoring service. It shows small examples on top of existing mechanisms and names the line where your application code ends and the platform begins. Handing a case to another agent or person is an application concern: the platform has no native handoff envelope or merge.

How the pages were checked

Runnable examples were executed and the command is on the page. A replay of recorded tool calls, an adapter test or a tool check without a model is reported as exactly that: it does not show how a live model behaves. Anything that needed a live model run and did not get one is marked not run.

All runnable examples ship in one versioned example bundle with per-file hashes in its manifest. Commands show unpacked-archive paths (files/...).

Next: Choose an integration pattern