Reply Intelligence Group · What we govern
Does the AI make you money? Can you prove what it did?
Reply Intelligence Group builds the intelligence and the control infrastructure a business needs to deploy AI profitably and provably. Both rest on one primitive: every outcome, and every action, traces back to the evidence that produced it.
Commercial Intelligence
Does the AI make the business money?
Whether AI engines recommend you. What happens when someone gets in touch. Where revenue leaks and what is recovered, with every booking attributed to the message that started it.
- ReplyScore — Are you being found?
- ReplyBench — Are you converting what finds you?
- ReplyOS — The runtime that recovers it.
AI Control
Can the business trust, prove and constrain what its AI does?
An agent that sends messages, changes records and books appointments is no longer answering questions. It is acting. Acting needs a register of what it may do, a ledger of what it did, and a gate that proves it still behaves after the software changes.
- DriftGuard — The gate between a change and the next deploy.
- Weft — A governed runtime for generated interfaces.
The shared primitive
Attribution and attestation are the same idea.
In ReplyOS a recovered booking is bound to the message that started it. Not asserted by a dashboard. Bound, so the number at the end of the quarter can be traced back message by message.
In DriftGuard an agent's clearance verdict is bound to a SHA-256 of the artifact it actually inspected. If the artifact changes, the verdict is void and nothing ships.
Provenance for money. Provenance for machine actions. One discipline, two ledgers, and a group that refuses to fake certainty in either.
What Control records
Four records. No policy documents.
Most governance tooling reports risk and stops there. Control sits beside the revenue column, because the group owns the runtime that produces it.
Register
per agent- Owner and purpose
- Model and provider
- Data it can reach
- Actions it may take alone
- Actions that need a human
- Actions it may never take
Ledger
per action- What it did, and to which record
- Autonomous, approved or escalated
- Whether personal data was touched
- What it cost
- Revenue influenced and recovered
- Policy check: passed or refused
Gate
per change- Attestation re-hashed before ship
- Invariant locks no agent can negotiate past
- Refusal on mismatch, not a warning
Trust page
per practice- Which AI acts on patients' behalf
- What data it handles and where
- Where a human is in the loop
- Generated from the ledger, not written by marketing
How it fits together
One control layer. Three governed runtimes.
Control
Register · Ledger · Gate · Trust page
Commercial
- ReplyScore
- ReplyBench
- ReplyOS
Reliability
- DriftGuard
Runtime
- Weft
Status
What runs today, and what does not yet.
Running in production
- Attribution ledger in ReplyOS: every recovered booking traced to its source message.
- DriftGuard gate inside the ReplyOS pipeline, with invariant locks for tenant isolation, inbound enquiry capture and email threading.
Being built
- Agent register and action ledger inside ReplyOS, with ReplyOS's own recovery agents as the first entries.
- A per-practice trust page generated from that ledger.
Not yet
- No control mapping to ISO/IEC 42001, NIST AI RMF or the EU AI Act until there is runtime evidence to map. No certification claims of any kind.
- No connectors to third-party AI a business already runs. Control governs the agents the group operates, and publishes the evidence.
Why it is credible
Every governed runtime on this page is ours.
ReplyOS is the first customer of Control. It runs autonomous agents that read patient enquiries and book appointments, so the register, the ledger and the gate get built where the stakes are real, and the revenue they influence sits in the same table as the risk. That is the only way we know to sell governance honestly.
Start where the evidence is.
Practices start by measuring the leak. Product teams start with the gate.