← Reynforce · as markdown

Connect Reynforce to your agent platform

If your agent can make an HTTP request, it can use Reynforce. One endpoint, one bearer token, and no change to how your agent is orchestrated — we never run your agent.

The two values

endpoint	https://app.reynforce.com/t/<your-workspace>/mcp
header	Authorization: Bearer <your agent key>

That is an MCP server over Streamable HTTP. A platform that cannot speak MCP does not need to: the same check is one POST to /t/<your-workspace>/v1/observe, and examples/curl/check-action.sh is that request in full.

What an agent key can do, and what it cannot

tool
search_claims	read the register. A claim's status comes back with it, so the agent can tell a current claim from a stale one
check_action	ask whether an action is permitted

An agent key cannot add a claim. propose_claims, assign_owner, accept_claim, confirm_claim and raise_contest need register:write, which only a signed-in person holds. An agent proposes and asks; a person accepts.

check_action writes a record, and that is not optional. The record is a side effect of the permission check rather than something the agent sends, so a caller can be wrong about its own action and still cannot be wrong about the record. There is deliberately no way to ask without leaving a trace: an agent that could would ask until the answer was yes. intent: "draft" is the honest version — the check is recorded and the touch is not, because nothing was touched.

The six platforms, and which of them anyone has tested

None of them. Not one. We have written down what to paste and marked every platform-side step untested, because we have not read any of their documentation — eleven of their documentation hosts were measured on 11 October 2026 and all eleven refused the request.

platform	status
Claude, and any MCP client	[untested]
Clay	[untested]
n8n	[untested]
CrewAI	[untested]
LangGraph	[untested]
Dust	[untested]

A setup guide that looks right and has never met its client costs the same as an API adapter that has never met its service, and the person who pays it is you, following our instructions. So the notes in examples/clients/ say which single question is unanswered for each one, rather than filling it in plausibly.

One page rather than six. Six pages whose differing sixth is we have not read this would be six thin pages. When a platform's steps are read and written, its section is worth a page of its own and gets one.

The three things to check once it is connected

1. The tool list. An agent key should see exactly search_claims and check_action. If it sees propose_claims, you have given it a person's key.
2. not_checked in the answer. allowed with that list non-empty means something was never evaluated, and not evaluated is not passed. Triggers and budgets can both be in it.
3. A cited claim's status in the answer, not the one you sent. The register replaces it, because usability is derived and a caller does not grade its own citations.

What we store

The action's shape, the decision, and — where the action carried a promise — the sentence that promise was made in, up to 1,000 characters. Not the rest of the message. Data at rest sits on Fly's encrypted disks; the encryption is theirs, not ours. Records are kept for 24 months, an unclosed commitment is never deleted on age, and every deletion is itself recorded.