Give an agent a budget, not your credit card.
Operity Platform sits between the agents your company runs and the money they spend. You fund them, set what they may do, and see everything they did, without putting any of that control inside the agent.
Who this is for
Teams running agents that already act on their own. If an agent of yours calls paid services, buys data, or is heading toward paying other agents, the finance question arrives before you are ready for it.
You probably recognise one of these:
- An agent holds a shared API key with no cap, and nobody is comfortable about it
- Every purchase waits for a human, which removes most of the reason to have an agent
- Someone in finance asked what the agents spent last month and the answer took two days
- You have twelve agents and one spending policy, applied by hope
What an agent gets
Identity.
Its own name and keypair, not a shared credential pasted into a prompt. Actions belong to the agent that took them, and that record survives restarts, redeploys and model changes.
A balance.
Funded by you, spent as it works, and when it reaches zero the agent stops. The balance is the ceiling on what an agent can ever cost you through Operity.
Limits.
How much per transaction, per day, per month, and who it may pay. You set them. The agent cannot change them, and no instruction reaching it can.
A record.
Every movement, permanent, inspectable, exportable. When someone asks where the money went, the answer is a record rather than a reconstruction.
How it works
Create the agent.
It gets an identity separate from your account and from every other agent you run.
Fund it.
Move credit across. Top up or take back at any time.
Set the limits.
Per transaction, per day, per month, and an allowlist of who it may pay.
Let it work.
It pays as it goes. Anything outside the limits is refused before money moves.
See everything.
Filter, review, attribute, export.
The code
agent = operity.agents.create(handle="research-bot")operity.agents.fund(agent, credits=250)operity.agents.set_limits(agent, per_transaction=25, per_day=40) # within the limits, settlesoperity.transfers.create(agent, to="supplier-01", credits=12)# => Transfer(status="settled", balance=238) # one credit over the per-transaction cap, refusedoperity.transfers.create(agent, to="supplier-01", credits=26)# => PolicyError: per_transaction limit is 25 (requested 26)
The refusal is not a shortage of funds. The balance is 238 and the day has room. The transfer asks for one credit more than the per-transaction limit allows, and that alone is enough. The check runs on our side, so it arrives as an error rather than as a payment you have to unwind.
Illustrative of the API in development. Shapes will change before release.
Private deployments
For companies that cannot put agent spending data on shared infrastructure, Operity runs as a dedicated instance: your own database, your own keys, your own domain, with the same API.
Available to design partners first. Talk to us about what your compliance team needs before we build the wrong thing.
What a balance is, and is not
Today it is a test credit.
A unit of account inside Operity. No payment provider is connected, so a balance does not yet correspond to money you have paid in.
Funding and withdrawal are planned, not built.
When they exist they will run through a regulated payment provider. None is confirmed, and we will name one here when that changes rather than before.
It caps Operity-controlled spending only.
Not your model tokens, not your cloud bill, not anything your agent pays for by another route.
Stopping is not unwinding.
An exhausted balance blocks further spending. It does not cancel work already commissioned or release money already held against it.