# 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.

## 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](/guide/reading-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](/agent-engineering/integration-patterns/), [Build your first
  agent](/agent-engineering/first-agent/), [Collect facts and
  evidence](/agent-engineering/collect-facts/), [Read answers](/agent-engineering/handle-answers/),
  [Evaluate, debug and upgrade](/agent-engineering/evaluations/).
- **Build an agent that finds the question itself** — [Connect and
  discover](/agent-engineering/connect-and-discover/), [Pin context, editions and
  time](/agent-engineering/context-and-time/), [Read answers](/agent-engineering/handle-answers/).
- **Run a multi-step task** — [Follow a task guide](/agent-engineering/task-guides/),
  [Cases and processes](/agent-engineering/case-lifecycle/), [Human decisions,
  interpretations and scenarios](/agent-engineering/decisions-and-scenarios/).
- **Before release** — [The agent contract](/agent-engineering/agent-contract/),
  [Safety and reliability](/agent-engineering/safety-and-reliability/), [Prepare and
  publish an answer](/agent-engineering/publishing/).

[Assist formalization and review](/agent-engineering/formalization-agent/) 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](/agent-engineering/files/instructions/apply-canon/SKILL.md).
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](/agent-engineering/agent-engineering-examples-0.5.0.zip) with
per-file hashes in its manifest. Commands show unpacked-archive paths
(`files/...`).

Next: [Choose an integration pattern](/agent-engineering/integration-patterns/)