Agent Skills
Compact operating contracts for agents that call Ando.
Use these skill blocks when an agent needs stable instructions for Ando inference. Choose one path. Do not blend the account-owned and accountless payment flows.
Ando Account Inference
Use this for agents that belong to an Ando account and should draw usage from that account's connection, controls, and spend limits.
# Ando Account Inference
Use Ando account inference when the agent has an Ando Virtual Key.
Endpoint:
- Base URL: https://inference.andoai.xyz/v1
- Chat: POST /v1/chat/completions
- Models: GET /v1/models
Authentication:
- Send Authorization: Bearer <your-virtual-key>.
- Keep the Virtual Key server-side.
- Never expose the key in browser code, logs, screenshots, traces, or prompts.
Request rules:
- Use the OpenAI-compatible chat shape.
- Check GET /v1/models before hard-coding a model.
- Set max_tokens or max_completion_tokens for predictable spend.
- Use the connection's default routing unless the operator needs a fixed model.
Error handling:
- 401 means the key is missing, invalid, revoked, or sent to the wrong route.
- Budget or policy failures happen before model execution.
- 429 means back off; do not create new keys or parallel retries.
- 5xx can be retried with bounded exponential backoff and the same
idempotency semantics.
Boundaries:
- Do not send Authorization: Payment to account-owned routes.
- Do not send this Virtual Key to /v1/mpp/chat/completions.Ando Tempo MPP Inference
Use this for accountless agents that should pay with Tempo MPP instead of holding an Ando API key.
# Ando Tempo MPP Inference
Use Ando Tempo MPP only for the accountless paid inference endpoint:
POST https://inference.andoai.xyz/v1/mpp/chat/completions.
Default request:
- Use model_optimization=true unless the caller explicitly needs a named model.
- Omit model when model_optimization=true.
- Set max_tokens or max_completion_tokens for predictable spend.
- Send buffered requests only until Ando enables streaming MPP.
Payment rules:
- Use Tempo MPP session credentials only.
- Treat 402 as a payment challenge.
- Retry only after the Tempo credential is bound to the exact same request body.
- Use the Ando challenge amount as the 1 USDC.e cumulative voucher bucket.
- Open or reuse a Tempo session whose channel deposit covers the active voucher
authorization.
- Treat the suggested 5 USDC.e deposit as a reusable-session hint, not a hard
Ando minimum.
- Do not blindly increase the cumulative voucher on every HTTP retry. Reuse the
current cumulative voucher until Ando returns
mpp_voucher_bucket_refresh_required.
- Close the Tempo session when the agent is done with the workflow so accepted
voucher spend settles to Ando and unused deposit returns to the agent.
Boundaries:
- Do not send an Ando Virtual Key to the MPP endpoint.
- Do not send Authorization: Payment to ordinary Virtual Key endpoints.
- Treat a 200 response without Payment-Receipt as a failed payment path.
- Never log raw payment credentials, signatures, wallet addresses, receipts,
idempotency keys, or prompt content.
Expected error handling:
- 402: obtain or refresh a Tempo session credential.
- 401: wrong route or wrong auth scheme.
- mpp_session_deposit_below_request_cost: top up or reopen the Tempo session.
- mpp_voucher_bucket_refresh_required: sign a fresh or higher cumulative
voucher.
- mpp_body_digest_mismatch: stop; the paid retry body changed.
- mpp_payment_verification_failed, mpp_reservation_failed, or
mpp_commit_failed: stop and surface the failure.
- 429: back off without opening additional sessions.
- 5xx: retry with bounded exponential backoff and preserve idempotency.Quick selection
The agent belongs to an Ando account, should use a Virtual Key, and should appear in account analytics.
The agent is accountless, has a Tempo-compatible wallet, and should pay at request time.
Authorization: Bearer and Authorization: Payment belong to different routes.
Give every agent call an explicit output cap before it reaches Ando.