Agents
An agent cannot pass KYC or hold a card. It can hold a key and spend a balance — which is all Outis asks.
The pattern#
- Point it at /llms.txt. It is the contract written for models, and it opens with what the service may not be used for.
- Give it its own key. Name the key after the agent so the ledger and the key list tell you which one did what, and revoke it alone if it misbehaves.
- Have it quote, then buy.
POST /v1/quotereturns the exact debit. A well-behaved agent checks the quote against its budget before calling the paid endpoint. - Let it handle 402.
NO_CREDITmeans stop and report, not retry.
Bounding spend#
Keys are not scoped yet, so the balance is the limit. The simplest guardrail is a separate account per agent, funded with only what it is allowed to spend — the balance cannot go negative, so the worst case is the balance.
Rules the agent must follow#
The acceptable use policy applies to software exactly as it applies to people, and llms.txt tells agents so directly: if the task, or the project the account would serve, is on the prohibited list, the agent should stop, spend nothing, and tell the person who asked. A key acts for the account that issued it; what an agent does is what the account holder did.
Waiting on slow operations#
Domain registration can take a while and server provisioning is not instant. Wait for the response to POST /v1/domains rather than retrying it, and poll GET /v1/servers/:id until ips is set.
Example: register if affordable#
q=$(curl -s -X POST https://outis.sh/v1/quote \
-H "Authorization: Bearer $OUTIS_KEY" -H "Content-Type: application/json" \
-d '{"method":"register-domain","params":{"domain":"nobody.example","years":1}}')
echo "$q" | jq .quote.priceUsd # compare with the budget, then:
curl -s -X POST https://outis.sh/v1/domains \
-H "Authorization: Bearer $OUTIS_KEY" -H "Content-Type: application/json" \
-d '{"domain":"nobody.example","years":1}'