RelayRelay

Support automation usually fails in one of two directions. Either it is too timid to be useful — a classifier that tags tickets a human then reads anyway — or too bold, taking actions that cost money on the strength of a confidence score.

The distinction that matters is not how capable the model is. It is whether the authority to act is defined in code, in a place a team can read and change, rather than implied by a prompt.

Authority in code

Amount ceilings, rate limits and always-review action classes live in configuration, outside the model.

Policy as retrieved text

Behaviour changes when the policy document changes — no prompt edit, no redeploy.

Idempotent side effects

Every external action is keyed, so a retry cannot issue a second refund.

A legible audit trail

Each decision must be explainable months later, including which policy version applied at the time.

Requests are classified on arrival, then context is assembled — account state, billing history, prior contacts — before any reasoning happens. The agent proposes an action and must cite the policy clause that permits it. A proposal without a citation is rejected by the layer above it.

Action limits are then enforced by deterministic code. Some classes of action, refunds among them, are marked always-review no matter how confident the agent is, because the cost of being wrong is asymmetric.

Escalation is treated as a first-class success path rather than a failure. A request that reaches a person with the account history, the applicable policy and a proposed action already attached has been meaningfully handled, even though nothing was automated.

Intake classifier

Cheap, reversible intent and urgency classification, logged for review.

Context assembler

Parallel fetches from CRM, billing and ticket history with per-source timeouts and partial-failure handling.

Policy retrieval

Versioned policy documents retrieved as text with owner and clause references.

Proposal engine

Produces a typed action proposal with a required policy citation and confidence value.

Authority layer

Deterministic limit enforcement: ceilings, windows, per-account rate limits, always-review classes.

Tool adapters

Narrow, idempotent, individually permissioned functions per external system, with backoff and circuit breaking.

Approval surface

One screen showing action, cited clause and evidence, with approve, override and escalate.

The approval queue is designed to be cleared, not browsed. Each item presents the proposed action, the clause it rests on and the evidence behind it, and resolves with a single decision.

Overrides are the most useful signal the system produces. When an approver consistently overrides a particular proposal type, that is evidence the policy and the code disagree — and the queue surfaces that pattern rather than burying it in logs.

Required policy citation

Forcing the agent to point at a clause makes wrong decisions traceable to either a misreading or a genuinely ambiguous policy.

Always-review classes independent of confidence

Confidence is not a measure of consequence. Money leaving the business is a human decision.

Durable workflow state

A request paused for approval may wait for days. Workflow state is persisted, not held in memory.

Narrow tools over a general API client

Each tool does one thing with one permission, which makes the blast radius of a mistake small and legible.

The evaluation set is built from request transcripts paired with the action policy requires — including cases where the correct behaviour is to escalate without acting.

We scored two failure types separately, because they are not equally bad. Acting when the system should have escalated is a safety failure. Escalating when it could have acted is a cost failure. Conflating them hides the only tradeoff that matters.

Tool adapters are tested against recorded fixtures of the third-party APIs, including their error and rate-limit responses, which are the behaviours integration code actually has to survive.