# Reynforce and the guardrail and observability tools

**They check what an agent says. Reynforce checks what it commits your company
to, and keeps the record.** Most teams who arrive here already run one of them
and have just found the gap — so this is a boundary rather than a bake-off.

## The three categories, and the question each one answers

| | the question it answers | what it reads |
|---|---|---|
| **wording guardrails** | is this output acceptable? | the text of the output |
| **tracing and observability** | what did the system do, and how much did it cost? | spans, prompts, latencies, token counts |
| **evaluation** | is the model good enough at this task? | a fixed set of cases, scored |
| **Reynforce** | is this true, who says so, and may this agent say it? | a register of claims with owners and dates, and a mandate |

The first three are about the **agent**. Reynforce is about the **company** —
what it stands behind, and what has been promised in its name. That is why
they stack rather than compete: a trace tells you the agent said something, and
a register tells you whether it was the company's to say.

## Where the gap shows up

A wording guardrail sees *we can have that live by the end of the month* as a
polite, on-brand, perfectly acceptable sentence. It is. It is also a deadline
with nothing behind it, made in your name, and the guardrail has no source of
truth to check it against — not because it is badly built, but because that is
a different kind of input.

Tracing has the opposite shape: it would have the sentence, verbatim, in a
span. What it does not have is **the claim the sentence relied on, the state
that claim was in at the time, and the authority the agent was acting under** —
so you can find the promise if you know to look, and you cannot answer *was it
ours to make*.

## Three things that are genuinely different, not just positioned differently

**The record is append-only and we cannot edit it either.** That is the point
of it. A log a vendor could tidy is not evidence in a disagreement with your
customer.

**An unusable claim cannot be cited whatever else is relaxed.** Usability is a
fact about the claim — nobody stands behind it — rather than a confidence
threshold. Turning a dial up buys latitude with current sources, never
permission to repeat a stale one.

**It has no opinion about your stack.** Reynforce never runs your agent, which
rules out competing with the orchestration frameworks and makes this a decision
function rather than an execution engine.

## What we will not tell you

**We have not characterised any named product on this page, and we are not
going to from memory.** Every vendor's documentation host is unreachable from
where this page was written — measured, not assumed — and a comparison table
built from recollection of somebody else's product is the exact thing this
company exists to argue against.

**[unread] The named rows.** `competitor docs` is the reader pointed at each
tool's own published pages. When a run returns passages, the rows go here with
the page each one came from and the date it was read, in that vendor's own
words — and if their own page contradicts something on this one, that is a
finding and the page changes.

Until then: the categories above are a fair description of what the three kinds
of tool are **for**, which is a claim about shape rather than about any
company's features.

## If you already run one

Keep it. The honest version of this page is: wording guardrails and tracing are
doing a job this does not do, and if you have them you are further along than
most. What you are missing is the source of truth, and
</agent-promise-register.md> describes it.