AgentStream: what to use when

short chooser for connecting voice ai over exotel agentstream https //docs exotel com/exotel agentstream/connect voice ai api there are two control models model how call logic is defined typical entry flow (app bazaar) dashboard applets (voicebot, stream, connect, passthru, gather, greeting) exophone → appbazaar flow, voicebot applet or passthru/ connect applet with url exoml (programmable voice apis) your code reacts to grpc leg events and issues leg actions (start stream, start say, start play, hangup, bridge, …) no app bazaar flow required number attached to grpc endpoint (inbound), or post /legs (outbound) your bot websocket (agentstream) is the same either way choose the telephony control plane , not a different bot protocol quick chooser you need… use outbound answer → bot only connect voice ai api https //docs exotel com/exotel agentstream/connect voice ai api outbound answer → bot with custom routing logics via applets voicebot applet and then / ivr / greeting / dtmf / agent handoff via connect applet in exotel connect voice ai with flow api https //docs exotel com/exotel agentstream/connect voice ai with flow api outbound or inbound full runtime control in code, per call stream url, parallel greeting while bot connects exoml / programmable voice apis https //docs exotel com/exotel agentstream/programmable voice apis with agentstream inbound dashboard flow with voicebot applet assign virtual number (exophone) to an app bazaar flow that includes voicebot applet inbound no flow — events to your app, you drive the call attach virtual number to a grpc endpoint (exoml / programmable voice) outbound 1\ connect voice ai api — simplest outbound docs connect voice ai api https //docs exotel com/exotel agentstream/connect voice ai api what happens your api dials the customer on answer, exotel opens bidirectional wss to streamurl use when campaigns, surveys, reminders — bot is the whole experience no ivr, no compliance applet, no agent transfer in exotel fixed bot url is fine in the request (streamurl + streamtype=bidirectional) not for menus, disclosure before bot, bot→human, or per leg programmable actions your api → dial customer → answer → agentstream wss ↔ bot 2\ connect voice ai with flow api — outbound + app bazaar journey docs connect voice ai with flow api https //docs exotel com/exotel agentstream/connect voice ai with flow api what happens same connect call, but url points at an app bazaar flow after answer, applets run when the flow hits voicebot / stream , exotel opens wss stream url is configured in the applet , not in the api body use when compliance greeting → bot ivr / dtmf → bot bot → connect (human) or passthru (your system) unidirectional stream for assist / transcription not for pure “answer → bot” (use connect voice ai), or code owned per leg control (use exoml) your api → dial customer → answer → app bazaar flow → voicebot/stream → wss ↔ bot common flow patterns greeting → voicebot · gather → voicebot · voicebot → connect · voicebot → passthru 3\ exoml (programmable legs) — outbound in code docs programmable voice apis with agentstream https //docs exotel com/exotel agentstream/programmable voice apis with agentstream · exoml introduction https //docs exotel com/voice apis/exoml introduction what happens you post /legs to dial the customer, receive events on your grpc leg event endpoint, then issue leg actions yourself (e g start stream, optional start say / start play) use when stream url / routing decided per call at runtime parallel filler while bot connects (sales / collections “instant feel”) you want application owned call logic, not a dashboard flow scenario pattern bot first / tech support leg answered → start stream sales / collections / cc simulation leg answered → start stream + short start say / start play → on stream started → stop say / stop play your api → post /legs → grpc events (connecting / ringing / answered) → your app start stream (+ say/play) → agentstream wss ↔ bot inbound inbound has two separate paths do not mix them with the same mental model a flow based inbound (app bazaar + voicebot applet) what happens customer dials your exophone the number is linked to an app bazaar flow applets execute in the dashboard defined order voicebot opens bidirectional agentstream to your bot use when you want visual / applet based journeys (voicebot, greeting, ivr, bot, agent handoff) same patterns as connect with flow outbound, but the customer dials in customer → exophone → app bazaar flow → voicebot → wss ↔ bot setup procure exophone → assign voice url / flow → include voicebot (and optional connect / passthru / gather) b exoml programmable inbound (no app bazaar flow) what happens customer dials your exophone the number is attached to a grpc endpoint (programmable voice / legs), not to an app bazaar flow exotel pushes leg events to your grpc service your application is the flow — you answer/control the leg with leg actions (start stream, say, play, gather, bridge, hangup, …) use when call logic must live entirely in code per call dynamic stream url, a/b routing, crm driven branching same exoml action model as outbound legs (inbound or outbound legs) customer → exophone (attached to grpc) → grpc leg events → your app → leg actions (start stream, say/play, …) → agentstream wss ↔ bot setup implement grpc event endpoint → register it → attach exophone to that grpc endpoint → on inbound events, issue leg actions exoml inbound does not require a voicebot applet or app bazaar flow the programmable “flow” is the sequence of leg actions your service sends in response to grpc events side by side connect voice ai connect + flow exoml (legs) inbound flow + voicebot inbound exoml direction outbound outbound outbound and inbound inbound inbound control plane single connect api app bazaar applets grpc events + leg actions app bazaar applets grpc events + leg actions app bazaar flow no yes no yes no where wss url is set api streamurl voicebot/stream applet start stream action voicebot/stream applet start stream action parallel greeting while bot warms bot owned flow play applet start say / start play + stop on stream started bot owned same exoml say/play pattern best for simple outbound bot multi step outbound code first, dynamic control dashboard inbound journeys code first inbound decision tree who starts the call? │ ├─ customer dials (inbound) │ ├─ want dashboard applets (voicebot,passthru, connect)? │ │ └─ exophone → app engine flow → voicebot │ └─ want logic in your app (no flow)? │ └─ exophone → grpc endpoint → leg actions (exoml) │ └─ you dial (outbound) ├─ bot only, fixed streamurl? │ └─ connect voice ai api ├─ need exotel flow (voicebot applet/passthru / agent handoff)? │ └─ connect voice ai with flow api └─ need grpc + leg actions / dynamic stream / parallel say play? └─ exoml programmable legs api same bot, four front doors entry who dials control who configures wss connect voice ai your api connect api streamurl in api connect + flow your api app bazaar voicebot/stream applet exoml outbound your api (post /legs) grpc + leg actions start stream body inbound flow customer app bazaar voicebot/stream applet exoml inbound customer grpc + leg actions start stream body references connect voice ai api docid\ owtjagrpfwe8djhjiqsli connect voice ai with flow api docid\ ykd82kkkovavq4vrnghpe programmable voice apis with agentstream docid\ ip28bojsuuu9kz1pu1miv exoml — introduction docid\ ju t9acidadhkkoafydwp agentstream developer guide https //developer exotel com/docs/agentstream/developer guide implementing your grpc endpoint for real time call events docid\ ah1nmj4tfrvxbu6fhhzeb