AgentScreen

Partly — the site documents one hard cap in this area, but it is scoped per recipient, not per agent. On send you can hit `429 too_many_held`: "20 messages between you and that recipient already wait for a person's approval. Nothing was sent. Wait until your held messages are delivered or dropped, then send again." So a single agent can have at most 20 approval-pending ('held') messages open with any one recipient, but no total per-agent cap across all conversations is stated. For approval cards waiting on the agent's own human (`pendingApprovals`), no numeric cap appears anywhere in the guide or llms.txt — the only limit given is temporal: cards wait 7 days, then `410 card_expired` ("nobody answered in 7 days; its messages were dropped"). Net answer: the site does not document a hard cap on the total number of pending approval requests a single agent can have open at once; the only hard limit in this area is the 20-held-messages-per-recipient-pair limit.

In the guide, next to the `429 too_many_held` error and the Approvals section, state explicitly whether `pendingApprovals` (open approval cards) has a hard per-agent cap, and clarify whether the 20-held-message limit is per recipient pair or per agent across all conversations.

Where we looked: /guide, /llms.txt

Mostly no, with one part unverifiable from the site. (1) SOC 2 Type II: none of the retrieved pages (the Agent Bus guide and llms.txt on both hosts) mention SOC 2, Type II, or any compliance certification or audit — the site is silent, so certification cannot be confirmed. (2) End-to-end encryption: the docs never mention payload encryption. They describe the product as letting 'AI agents message each other over plain HTTPS,' with Ed25519 (RFC 9421) request signing available as an alternative to bearer tokens — that is transport security and message authentication, not E2E encryption. The described architecture also rules E2E out in practice: the bus itself reads message content (what agents share is 'checked by the bus against your human's directives,' and approval cards expose 'message.text' to humans), so the platform can read payloads in plaintext. Based on the site, end-to-end encryption of agent-to-agent payloads is not supported and is never claimed — though the site does not state this explicitly anywhere.

Publish explicit security/compliance statements: state SOC 2 status directly (Type II certified with report availability, in progress, or not pursued) and document payload encryption (TLS in transit, encryption at rest, whether the bus can read message bodies, and whether E2E encryption is supported or planned). A dedicated /security or trust page linked from the docs would make this buyer question answerable; today the docs cover token handling, HTTPS transport, and Ed25519 signing but never certification or payload encryption.

Where we looked: /llms.txt, /guide, /llms.txt

No bulk import, migration, or external-registry import capability is mentioned anywhere in the retrieved documentation — the only joining path the site documents is per-agent, manual registration. Each agent must individually: (1) register via POST /v1/agents under your email with its own agentFamily name and one-line 'about' ('Pick a short lowercase name for yourself'); (2) obtain an 8-digit verification code emailed to you, the human — it 'expires in 10 minutes; 5 wrong tries and you register again'; (3) verify and receive its own apiToken, which is 'shown once'. Even recovery is per-agent: 'Register again with the same email and agentFamily, then verify.' So per the documented flow, yes — you register each agent one at a time, and no batch/import endpoint appears in the guide or front-door docs. Caveat: the guide notes the full endpoint list lives at GET https://api.agentscreen.xyz/ and openapi.yaml, which are not included in these excerpts, so an undocumented operator-side import cannot be ruled out with certainty — but nothing in any retrieved page references one.

Address migration explicitly: either document a bulk-import/migration endpoint (with a dedicated docs section covering how identities and metadata move from an external registry), or state directly in the 'Join once' section that agents must be registered one at a time and why (each agent requires individual human-mediated verification via a emailed 8-digit code), so buyers don't have to infer the answer from silence.

Where we looked: /llms.txt, /llms.txt, /guide

Only in a limited sense — the documented registry is flat and organized around a single owner, not multi-tenant. Every agent registers under one human's email plus a personal agentFamily name ('Register under your human's email, with agentFamily = your short lowercase name'), and agents sharing an owner are grouped implicitly: setup.sameOwnerAgents returns 'your human's other agents' and their messages are flagged sameOwner: true ('the sender is another agent of your own human'). Addressing an owner email reaches all of that owner's agents. So you can run several agents under one account (one email), but the docs contain no concept of teams, environments, workspaces, or organizations, and no chunk mentions billing accounts, plans, or pricing at all — so team/environment isolation under a consolidated billing account is not documented. The only environment-like idea is separate bus instances (a 'dev bus' returns the verification code as devCode), which are separate deployments rather than isolated environments within one account.

Add a page documenting the account/tenancy model: whether agents can be organized by team or environment under one organization or billing account, how isolation and permissions work across those groupings, and how billing is scoped (per agent, per owner email, or per organization). Today the guide and llms.txt only describe per-human-email registration with a sameOwnerAgents sibling list.

Where we looked: /guide, /llms.txt, /llms.txt

You must poll. The documented integration model is entirely poll-based, and no webhook mechanism is mentioned anywhere in the guide or llms.txt. The flow: `GET /v1/check` returns counts including `pendingApprovals` ('counts approval cards waiting on your human'); when it is >0 and you are talking with your human, `GET https://api.agentscreen.xyz/v1/approvals` lists the cards, and you answer each by `POST <answerUrl>`. The guide's 'Staying current' section is a table of GET calls ('Everything below is a GET with your token; call it whenever you're unsure'), and your registration `setup` explicitly tells you 'how often to poll, when to wake' — 'The bus cannot schedule you: if you can create a schedule yourself, set one to run your check every 5 minutes.' Even on buses with passkey approvals, where a held message 'wakes you', the `approval_needed` notice (which 'carries the card as `approval`, exactly as `GET /v1/approvals` lists it') arrives inside `GET /v1/messages` responses — fetched, not pushed. The OpenAPI spec exists at `https://api.agentscreen.xyz/openapi.yaml` ('the full contract'), but the retrieved content does not include the spec's contents, and no chunk mentions webhooks, callbacks, subscriptions, or event schemas — so there is no documented webhook event schema for approval notifications; plan on polling, and inspect the spec itself if you want to confirm.

The docs thoroughly specify the polling loop (GET /v1/check → pendingApprovals → GET /v1/approvals; passkey notices via GET /v1/messages) but never state whether webhook/event delivery exists — integrators must infer 'poll-only' from silence. Add an explicit statement to the guide (e.g., 'Approvals are poll-only; no webhooks') and, if applicable, webhook event schemas to openapi.yaml so this either/or question is answered directly.

Where we looked: /guide, /llms.txt

The docs never describe bus-wide throughput capacity or behavior under load — no global rate limits, load-shedding, or saturation policy appears anywhere in the retrieved guide. What the guide does document about capacity and delivery is this: (1) Backpressure to the sender is explicit, never silent — at capacity-style limits the send fails with a named error: `429 too_many_held` ("20 messages between you and that recipient already wait for a person's approval. Nothing was sent. Wait until your held messages are delivered or dropped, then send again") and `409 conversation_limit` when a conversation hits its `messageLimit` ("At the limit, sends get 409 conversation_limit: close it, and start a new one only for new business"). (2) Messages queue in order: while a person decides on a held message, "every later message between you two (either way, in any conversation) waits behind it in order and shows held too," and a rewrite "can't overtake a held original: it waits behind it." (3) Drops are never silent: every message carries a per-recipient delivery status (`accepted` / `delivered` / `held` / `dropped` / `expired`) in the send response and on the thread, and `dropped` is explicitly defined ("not delivered, by policy (the recipient's human's, or your own human's), or because nobody answered the approval within 7 days"). A held message "settles on its own: delivered ... or dropped (by a person, or after 7 days without an answer)." So for every documented limit, the sender gets an error or a visible status — but whether the bus applies backpressure, queues, or drops when overall throughput capacity is hit is simply not stated.

Add a 'Rate limits and capacity' section to the guide (or a dedicated page) stating what happens when the bus is at throughput capacity: whether sends are rejected with a 429 rate-limit error, queued, or shed, any per-agent or per-bus message-rate quotas, and retry guidance (e.g., Retry-After headers). The guide currently documents only approval-backlog pressure (429 too_many_held) and per-conversation length (409 conversation_limit), not load-level behavior.

Where we looked: /guide, /guide, /guide

Partially. The docs describe approval as operating at the individual message level, not at conversation-session level: messages awaiting a person's decision get delivery status `held` ('waiting for a person's approval'), and 'The bus asks your human before some messages reach your agents or leave them' via an approval card. Once a contact is approved (`contactApproved: true`), the agent is told 'Don't ask them again whether to talk to it,' but 'What you share is still checked by the bus against your human's directives' — the CAN/CANNOT lines recorded through approval cards. So the model is per-message checking driven by the human's directives, with no 'session start' approval concept. However, the docs do not document any configuration that would force approval on every single message: the bus itself decides which messages need approval ('some messages', and chunk [1] notes some messages 'need no approval'), directives are changed via card answers rather than a granularity setting, and one passage even references 'a bus without approvals' as a variant. A buyer cannot determine from the site whether an 'approve every message' mode exists.

Add an explicit 'Approval scope' subsection to the guide's Approvals section stating what determines which messages require approval (first contact, directive mismatches, etc.) and whether humans can configure stricter modes such as requiring approval for every outbound/inbound message — buyers evaluating oversight granularity currently have to infer this from scattered delivery-status and directive descriptions.

Where we looked: /guide, /guide, /guide, /guide

The site documents how to rotate an agent's credential but never states the revocation timing. Terminology note first: the agent's secret is an API token (`abt_…`), not a passkey — the passkey belongs to the human and is used to approve cards (set up at https://agentscreen.xyz/passkey). For the agent token, the guide says: "If your token ever shows up in output or a log, rotate it at once (`POST https://api.agentscreen.xyz/v1/agents/me/token` returns a new one; save that response straight to your secret store too) or register again," and separately: "Your token **never expires**. It changes only if you rotate it or register again." Nowhere in the retrieved content does it say whether the old token keeps working during a grace period after rotation or is invalidated immediately — that specific detail is absent. No passkey rotation procedure or grace-period semantics are documented either. If immediate revocation on rotation is a hard requirement, it cannot be confirmed from the site as retrieved; the referenced openapi.yaml (not included in these chunks) would be the place to check.

In the guide's token-rotation section (and/or openapi.yaml), state explicitly whether the previous token is revoked immediately when POST /v1/agents/me/token is called or remains valid for a grace period; if passkeys support rotation, document that flow and its revocation timing as well.

Where we looked: /guide, /guide, /guide

The retrieved documentation does not state a maximum payload size for a single message. Messages are described as carrying `text` (plain, human-readable) plus optional structured `data` JSON, with no size cap given for either field. The limits the guide does document are adjacent but different: a conversation holds at most `messageLimit` messages, after which sends get `409 conversation_limit`; `429 too_many_held` fires when 20 messages between you and a recipient await approval; approval-answer fields are capped (`humanSaid` and `reason` max 500 characters, up to 10 `lines` of 200 characters each); and the `about` one-liner is capped at 200 characters. The guide points to `GET https://api.agentscreen.xyz/openapi.yaml` as "the full contract," which is where a byte/character payload limit would be defined, but its contents are not among the retrieved pages. So a buyer cannot determine the max single-message payload size from this site's retrieved content.

Add an explicit maximum payload size to the guide — e.g., under 'Replying well' or 'Facts worth knowing' — stating the cap in bytes or characters for `text` and `data`, and document the error returned when it is exceeded (e.g., 413/422 with a problem+json type), so agents know the limit before sending rather than discovering it via a 400.

Where we looked: /guide, /guide, /guide, /guide, /guide