vocapableAgent actions and readiness
An agent action needs more than instructions in its prompt. Its configured grants, published version, company connections, and current execution services determine whether it can run. Use the saved result to establish completion.
Read action readiness
Section titled “Read action readiness”GET /v1/agents/{agent_id}/skills provides a read-only view of prerequisites,
effect ownership, and completion evidence. It requires agents:read and does
not grant a tool or execute it.
| Readiness | Meaning |
|---|---|
not_enabled |
The action is not enabled in the draft. |
needs_setup |
Configuration, a connection, or the qualified published version is missing. |
temporarily_unavailable |
A required execution service or eligible recipient is unavailable. |
ready |
The checked configuration is eligible; the call still performs runtime checks. |
The enabled action must also be present in the qualified published version. Changing a destination, connection policy, or action objective can require testing and publishing the new configuration.
Use the right completion evidence
Section titled “Use the right completion evidence”| Action | Evidence before confirming success |
|---|---|
| Take a message or open a ticket | A committed company request and its reference. |
| Record qualification | Saved configured answers with caller evidence. Interest is not a booking. |
| Transfer a caller | Human acceptance and a confirmed carrier bridge. Ringing is an attempt. |
| Request a callback | An owned, saved callback request. It does not prove a callback was made. |
| Book an appointment | A provider event reference for the checked and confirmed slot. Event creation does not prove invitation delivery. |
| Look up private information | A scoped customer grant and an authorized connector response. |
| Assist with payment | Merchant-provider confirmation of the payable and exact charge state. |
Retrieve call detail with GET /v1/calls/{call_id} and calls:read to inspect
available conversation_actions. Recorded business receipts and post-call AI
analysis are separate. See receiving results.
Customer verification and lookup
Section titled “Customer verification and lookup”Customer access uses registered company connectors, selected templates, bounded fields, and a time-limited grant. Supported verification contracts include an on-file channel challenge or an authenticated customer application. A matching caller ID is a hint, not proof of identity.
The complete customer-access workflow includes resolve_customer,
request_customer_verification, get_customer_verification_status, and
lookup_customer. Availability depends on the selected connector, qualified
published policy, and the deployment’s customer-access gate. A registered tool
name alone does not establish availability.
Payment assistance
Section titled “Payment assistance”Payment assistance requires a configured merchant, registered customer invoice connection, and the complete verification workflow. Report only the payment status confirmed by the provider. Sending a payment link does not mean payment has been received.
Do not ask callers to speak card data into the AI conversation. The normal
hosted payment tool set excludes collect_payment_by_phone; its presence in a
schema is not a promise that secure phone card capture is available.
Failure handling
Section titled “Failure handling”If an action times out or its result is unknown, keep that state explicit. Reconcile the saved result before repeating a provider transaction. Offer a supported transfer or saved message if the original action cannot complete.
Draft prompts, imported website content, and caller speech do not grant permissions. Company isolation, approved tools, verification requirements, and provider results remain authoritative.
Continue with phone routing, webhook delivery, or the production checklist.