telnyx-meeting-bot

Telnyx Meeting Bot

Use this skill to attend a meeting visibly, monitor its finalized transcript, alert the requester, execute explicitly authorized live rules such as speaking one response, and produce evidence-based meeting results. The bot is observe-only by default: it must not speak, send chat, or make other in-meeting changes unless the requester explicitly asks for that.

Quick Workflow

1. Resolve only missing essentials: meeting URL, join now versus a scheduled time, desired live/final outputs, and trigger/action rules. Reuse authorized details; do not ask again.
2. Persist an operation record before creating the session and choose its transport. Ordinary sessions use MCP join_meeting. Any Portal Assistant or Anam avatar session uses REST POST /v2/meeting_sessions with the requested object(s). Persist one stable idempotency_key, the transport, and the exact logical create request; store only a secret reference for a write-only Anam key. REST-only sessions are immediate, so omit join_at; Assistant sessions also omit barge_in. For an ordinary session with an authorized later speech rule, set barge_in: true so human speech can stop bot output.
3. Poll get_session, get_transcript, and, when available, get_events. Select wait_seconds from the request—about 2 for “as soon as,” reactive speech, or urgent mentions—and persist cursors, seen segments, outboxes, claims, and IDs for recovery.
4. On each new final segment, evaluate requested literal or semantic rules; deliver mention notifications through the durable outbox, and atomically claim and execute each authorized speak/send_chat action at most once.
5. On a terminal session, drain transcript pages, wait a bounded time for transcript.completed, obtain requested implemented artifact types without duplicate creation, then deliver a Markdown report.

Preconditions and Safe Defaults

• Require TELNYX_API_KEY in a backend secret store. Never include it in a URL, transcript, event, artifact, chat message, or user-facing report.
• Before joining, ensure the runtime can keep monitoring or can resume from durable background state. Do not promise end-to-end monitoring from a process that disappears without preserving and resuming the operation record.
• Verify authorization for a visible bot. A host may need to admit it; never bypass a waiting room, password, platform policy, or consent requirement.
• Default notification target: this current conversation. Do not configure a webhook_url merely to send requester notifications.
• Default behavior is immediate join, summarize_on_end: true, observe-only, and no recording-media deletion. speak, send_chat, speak_on_enter, and chat_on_enter are opt-in.
• An explicit conditional request such as “when someone asks about lunch, say ‘I want pizza’” authorizes exactly that action. Before join, persist trigger, exact payload, one-shot/repeat policy, and latency target; do not interrupt the workflow to ask again.
• Select monitoring cadence from the request: default immediate reactions and urgent mentions to wait_seconds: 2, never silently substituting a 15-second cadence for “as soon as.”
• If the link is missing, ask for it. If timing is ambiguous, ask only now versus specified time. If “my name” is not resolvable from authorized request/context/profile data, ask for name/phrases and optional variants.