for builders · agents you ship to clients
Build the agent once. Let the owner change its authority.
When every limit lives in prompts or code, every change a client asks for is an engineering change for you. With KIFF the owner changes the card, and your agent keeps running the same code.
the idea
Approval does not scale. Delegation does.
work gets cheap
Agents attempt more actions, more often, in more situations.
totals start to matter
Each action may be fine. A thousand in a day is a different exposure.
approval does not scale
If a person signs off every action, the savings stop there.
delegate, with bounds
Defined work, valid conditions, up to a total. People set, change and withdraw it.
Build the agent. Not the authority layer around it: limits, ownership, balances, revocation and evidence come with KIFF instead of being rebuilt for every customer.
the instrument · closer to a pilot’s licence than a credit card
Money is only the first thing a card can count.
REFUND_ORDERonly on a paid order
€5,000 a day
CHANGE_ACCOUNT_EMAILonly once the customer is verified
3 an hour
DEPLOY_SERVICEonly when the build has passed
2 a day
PURGE_ROWSonly on records past retention
50,000 rows a day
Illustrative cards, each expressible today. Not a payment card, and not a badge. The domain decides whether an action is valid at all; a limit bounds exposure. It does not make a wrong action right.
- Observe
Advisory decisions; the agent keeps its flow.
- Issue small
A narrow set of actions and a low limit.
- Widen it on the record
Raise it when the statement earns it.
- Withdraw
Revoke in one step. No redeploy, no call to you.
a card’s day · tap through
What the owner sees, one decision at a time.
You issue the refunds agent its card.
REFUND_ORDER, only when the order is PAID, up to €5,000 per calendar day.
REFUND_ORDERPAID- card issued · €5,000/day · by ops lead
The agent proposes a €4,000 refund on a paid order.
Within the conditions and the ceiling. KIFF authorizes and draws €4,000; your system runs the refund.
REFUND_ORDERPAID- card issued · €5,000/day · by ops lead
- REFUND_ORDER €4,000 · ord_8812 · authorized
The agent proposes a further €1,500 refund.
The order may be eligible, but €1,500 exceeds the €1,000 left today. Refused, nothing drawn.
REFUND_ORDERPAID- card issued · €5,000/day · by ops lead
- REFUND_ORDER €4,000 · ord_8812 · authorized
- REFUND_ORDER €1,500 · ord_9120 · refused, ceiling
You revoke the card.
One action from the owner. No redeploy, no call to the builder.
REFUND_ORDERPAID- card issued · €5,000/day · by ops lead
- REFUND_ORDER €4,000 · ord_8812 · authorized
- REFUND_ORDER €1,500 · ord_9120 · refused, ceiling
- card revoked · by ops lead
The agent is told to try €200 anyway.
New instructions do not restore authority. The proposal is refused.
REFUND_ORDERPAID- card issued · €5,000/day · by ops lead
- REFUND_ORDER €4,000 · ord_8812 · authorized
- REFUND_ORDER €1,500 · ord_9120 · refused, ceiling
- card revoked · by ops lead
- REFUND_ORDER €200 · ord_9377 · refused, revoked
Illustrative decisions, not a customer run. KIFF authorizes; the owner’s system executes.
why not write it yourself?
A limit is quick to write. Keeping it correct is the hard part.
LIMIT = 5000 # per day
spent_today = load_spent()
def refund(order, amount):
if spent_today + amount <= LIMIT:
save_spent(spent_today + amount)
payments.refund(order, amount)A typical first version. Tap each production event to compare it with KIFF.
Two runs refund €800 in the same second, with €1,000 left.
Both read €1,000 left. Both pass. €1,600 goes out.
Draws on a card are locked. The second sees €200 left and is refused.
The payment call times out and the framework retries the same refund.
The retry is counted again. The limit is reached by money that moved once.
The draw is keyed to the proposal. The retry counts once.
The agent is redeployed at noon, or scaled to three workers.
Each process keeps its own count, or starts from zero. The limit multiplies.
One balance per card, held centrally across every run, process and machine.
The store holding the balance does not answer.
The error becomes zero spent. The agent has a full limit.
An unreadable balance refuses. It shows as unknown, never zero.
The agent is told a VIP customer needs more room today.
The limit sits in config the agent’s deployment can change.
The agent’s key cannot change its card. A ceiling change takes the owner’s management key.
The owner asks what happened on Tuesday.
Application logs, written by the same system that acted.
A signed, tamper-evident record of every authorization and refusal.
what building with KIFF includes
Ship the agent without rebuilding its controls.
One workflow at a time: integration and control testing first, then the owner handover, then operations views once it is live.
- Integrate
The first card: the domain, the card and the check before the tool call, on one real workflow.
- Control testing
Did the operation respect the owner’s authority under concurrency, retries, restarts, outages and revocation?
- Hand over
The Card Handover Package: authority, coverage, tests, emergency steps and the owner’s acceptance.
- Operate
Operations views: the owner sees each agent and its authority; you see the health of what you built.
A passing control test shows the protected path holds. It does not prove the whole workflow is safe, or that no other path exists. Actions that bypass the check need their own controls.
# No adapter needed. Wrap the one function that moves money.
def issue_refund(order, amount):
d = kiff.decide("REFUND_ORDER", entity=order, amount=amount)
if not d.allowed:
return d # blocked or held, never execute
payments.refund(order, amount) # your code, unchanged| 08:00 | card issued · €5,000 per day | by ops lead | |
| 09:12 | ord_8812 · order PAID | authorized | −€4,000 |
| 11:40 | ord_9120 · €1,500 | refused · ceiling | €0 |
where this goes · not built today
Authority someone can read.
Today a card is enforced within one KIFF account, for one named agent, on software actions. We are building toward these with the teams who need them; none is available yet.
physical agents
Equipment, areas and shifts a robot may work.
short-lived authority
A card for one task or one window.
agents that delegate
Pass part of the authority on, never growing the total.
across organizations
Show verifiably what an agent may do for another company.
Start with one workflow.
A conversation, not a commitment. Any implementation scope, price and duration is agreed before work begins.