Unknown tools count as writes
A tool not marked as read only is treated as a write and sent to the gate. A new connector cannot quietly change records.
Platform
Every agent step runs through one contract. The model proposes, guardrails check, only allowed tools run, writes wait for a person and the ledger records it all. The rules sit in the platform, so no single agent can skip them.
The runtime contract
Your risk team reviews one contract instead of a different design per agent. Voice AI, LiveAssist, NEQQO and Collections all run on it.
The agent asks a model for its next step through the model router, under the policy your tenant set.
Spine checks the answer before anything happens: personal data, contact rules, hardship policy and more.
The agent can call only the tools its profile lists. Anything else is refused and recorded.
Any action that changes a record waits for a named person to decide. No approval, no action.
The step, its checks and any decision land on the hash-chained ledger for your tenant.
Default deny
Each agent runs from an Agentic Orchestration Profile (AOP): a versioned file that lists the tools it may use and the checks it must pass.
A tool not marked as read only is treated as a write and sent to the gate. A new connector cannot quietly change records.
Checks run after each model step, not once per conversation. Collections guardrails cover FDCPA, Reg F and TCPA style rules.
Before any outreach Spine checks contact windows, do not call lists, consent, open disputes and jurisdiction rules.
Tenant isolation
Isolation is enforced by Postgres row level security, not only by application code. A bug in one screen cannot show one tenant's records to another.
Each record is stamped with its tenant and the database only returns rows for the tenant on the request.
Connector calls and audit entries carry the tenant too, so each tenant has its own chain of evidence.
Why it matters to you
We will run a real agent step and show each check, the gate and the ledger entry it leaves.