RELIANT SCALE ATLAS · AGENT ACCOUNTABILITY
Your agents are making consequential decisions.
Can you account for one?
Not “do you have logs”. Pick a single decision an automated agent made last week that affected a customer, and answer four questions about it: which actor decided, what evidence it held, what it was authorised to do, and what happened afterward. Most organisations can answer the first and the last. Atlas is built so you can answer all four, months later, without depending on anyone's memory.
Held stateCONTROLLED ENTERPRISE ENGAGEMENT · NO PUBLIC SIGNUP · NO SELF-SERVICE CREDENTIAL
01 / The four questions
Easy to ask.
Expensive to answer late.
These are the questions a regulator, a claimant's lawyer, or your own risk committee asks after something goes wrong. The cost of answering them is set long before they are asked — by whether the record was written at the time or is being assembled now.
- 01
Which actor did this?
Not which service, and not which model — which principal, holding which credential, under what scope. When one agent calls another and that one calls a third, the chain is recorded rather than inferred afterward from logs that were never designed to carry it.
- 02
What did it rely on?
The evidence reference that was available at decision time, stored with the decision rather than reconstructed later from whatever the source system happens to say today.
- 03
Was it allowed to?
The authority evaluation, recorded as part of the action. A refusal is accountable work too: an action denied for being outside its scope produces a receipt, because a prevented unauthorised action is the system doing its job.
- 04
What happened next?
The observed outcome, and whether anything has changed since. Where nothing has changed, Atlas says so — because “no later change has been admitted” is itself a finding worth recording.
02 / Why this is hard to retrofit
Agent-to-agent work
dissolves attribution.
A single agent is traceable. A fleet of agents that call each other, reusing the same service identities, produces a causal chain with no single operator who watched it happen. Application logs record what executed. They rarely record which principal held which authority, on what evidence, at that moment — because nobody needed that until the actor stopped being a person.
Revoking access must never erase the account of what was done.
- 01
Revocation takes effect on the very next request
There is no session and no cache. Every request re-reads the credential's state, so a revoked key stops working immediately rather than at the end of a token lifetime.
- 02
The record outlives the credential
Receipts survive revocation and termination. Ending an agent's access does not remove the account of what it did while it had access.
- 03
Retrying is safe and is not charged twice
Send an idempotency key. A retry returns the same receipt. Reads are never charged, so inspecting your own record does not cost you anything.
03 / The engagement
One agent. One workflow.
One accountability record.
The Founding Enterprise Pilot is a bounded engagement at US$20,000, credited toward the first year of consumption. It is deliberately narrow: one consequential workflow, taken end to end, so that what you get is a working record rather than an architecture diagram.
What a receipt is hereAn accountability receipt is a durable, attributed record of one action and the inputs that were knowable when it was decided. It is not the same object as the Ed25519-sealed verification receipt described elsewhere on this site, and it does not claim to be.
Begin
Bring us one decision
you would not want to explain from memory.
We will run the four questions against it in front of you, using the live interface. If your existing systems already answer all four, you do not need us, and we will say so.
partnerships@reliantscale.com
Atlas is accountability infrastructure. It is not a compliance certification for any regulation, and nothing on this page should be read as one.