# For GTM engineers

**You built the agent. Reynforce is the call it makes before it promises a
price, a date or a discount — and the record of what it promised.** One MCP
connection, two tools, and no change to how your agent is orchestrated.

You already know the failure mode. The agent is good at the conversation and
has no way to tell a number somebody confirmed last week from a number that
was true in a deck eighteen months ago. Nothing in the model knows which it
is, and nothing in your prompt can know either, because the prompt is where
the stale number came from.

## What the connection gives the agent

| | |
|---|---|
| `search_claims` | the claims your company stands behind, each with an owner and the date it was last checked |
| `check_action` | *may I say this* — answered against the mandate your company set, and recorded |

**The agent reads; it never writes a claim.** There is no tool that files a
commitment, and that is deliberate: what a caller sends is a description of an
action, what it gets back is a decision, and the record is a side effect of the
check on our side. So an agent can be wrong about its own action and still
cannot be wrong about the record.

**And there is no way to ask without leaving a trace.** An agent that could ask
*would this be allowed* with nothing written down can ask until the answer is
yes. Drafting is the honest version of that: say so, and the check is recorded
while the touch is not, because nothing was touched.

## What an answer looks like

Three things come back: whether it is allowed, which claims it would be
relying on and what state each of those is in, and what the check did **not**
evaluate. That last one matters more than it sounds — an answer that said
`allowed` while quietly skipping the budget it could not read would be the
confident wrong answer this exists to prevent.

A claim with no owner, one past its check date, or one two people disagree
about comes back **unusable**, and an unusable claim may not be repeated
whatever else is relaxed. The agent escalates and tells the buyer it is
checking. It does not answer around it, and that is not a setting.

## What it does not do

- **It does not orchestrate.** Your framework runs the agent; this answers a
  question. There is nothing here competing with the thing you already chose.
- **It does not block, today.** Every answer carries `observation_only: true`,
  and that travels in the answer rather than in documentation so that a caller
  honouring it keeps working unchanged the day it becomes false.
- **It does not read your mailbox or your CRM** unless you connect one. It
  does not read the text of the messages your agent sends — what it reads is
  your description of the action. **What it keeps is the sentence a promise
  was made in, capped at 1,000 characters**, so the promise is checkable.
  </privacy.md> is the full account.

## Connect it

</docs.md> is the quickstart: one line, and the tool list appears. **Early
access** — tell us what shape your agent is and we will tell you honestly
whether this helps yet.