Asterisk AGI vs ARI: Which Interface Should Power Your Voice Application?

Asterisk AGI vs ARI is often the first architecture decision in an Asterisk-based voice project. Both interfaces let you control calls from your own code, but with very different models. AGI (Asterisk Gateway Interface) runs a script sequentially from the dialplan. ARI (Asterisk REST Interface), introduced in Asterisk 12, exposes channels, bridges and media as resources your application controls asynchronously.

This article compares the two in depth and offers concrete criteria for choosing.

AGI in a nutshell

AGI is the older of the two. The dialplan invokes the AGI() application, which launches a script (or connects to a remote server using FastAGI). The script talks to Asterisk through text commands over stdin/stdout (or a TCP socket with FastAGI): ANSWER, STREAM FILE, GET DATA, SET VARIABLE, EXEC, and so on.

Key characteristics:

• Sequential, synchronous model: one command, one response. The script controls the call while it runs, then hands control back to the dialplan.
• One call, one context: each execution is tied to a single channel.
• Natural dialplan integration: routing logic stays in extensions.conf, and specific steps are delegated to the script (database lookups, number validation, dynamic routing).
• Variants: FastAGI (script hosted on a remote server, avoiding a process per call), EAGI (access to inbound audio), AsyncAGI (driven through AMI).

For more detail, see our Asterisk AGI expertise page.

ARI in a nutshell

ARI flips the model. The dialplan sends the call into the Stasis() application, and from that point your application decides everything. It receives real-time events over a WebSocket (channel entered, DTMF received, playback finished, hangup) and acts through a REST API: answer, play audio, record, create a bridge, add or remove channels, originate an outbound call.

Key characteristics:

• Asynchronous, event-driven model: your application reacts to events and can manage many calls concurrently.
• Low-level primitives: channels, bridges, playbacks, recordings, endpoints. You compose the behavior yourself.
• Multiple channels in one flow: conferences, attended transfers, callbacks and connecting two calls become natural.
• External media: recent Asterisk versions can route a channel’s audio to an external service, which makes it easier to plug in speech recognition engines and voicebots.

Our Asterisk ARI page goes further into these use cases.

AGI vs ARI comparison table

Execution model: the real difference

The fundamental difference fits in one sentence: with AGI, you add code to the dialplan; with ARI, the dialplan hands control to your code.

With AGI, your script runs inline with the call. While it waits for an API response, the call waits too. That’s easy to reason about, but you must watch response times and timeouts. Spawning a process per call (classic AGI) has a cost; FastAGI solves that with a long-running server.

With ARI, your application is a standalone service, often written in Node.js, Python, Go or Java. It keeps per-call state, reacts to events, and can act at any moment, for example stopping a playback as soon as a key is pressed or speech is detected. That freedom comes with responsibilities: state management, recovery after a WebSocket disconnect, and resource cleanup.

Media and voice AI

For a voicebot, audio access is decisive:

• AGI/EAGI gives you the inbound stream, but conversational handling (listening and speaking at the same time, interruptions) quickly becomes contorted.
• ARI supports cleaner architectures: an external media channel sends audio to your STT pipeline, TTS replies are played on the channel, and the application handles barge-in by stopping playback as soon as the caller speaks.

If your roadmap includes a voicebot or real-time analytics, ARI is usually the right foundation. Our article on how AI voicebots work describes that pipeline in detail.

Scaling and high availability

• AGI: FastAGI spreads easily across several application servers. The dialplan remains the source of truth, which simplifies failover when an application server goes down (you can build a fallback path into the dialplan).
• ARI: the application must be designed for resilience. If it loses its connection, calls sitting in Stasis can get stuck. Plan for reconnection, monitoring and a clear strategy for orphaned calls. One application can drive several Asterisk instances, but distribution and affinity need to be designed up front.

Selection criteria

Choose AGI if:

• your logic is mostly sequential (menu, input, lookup, routing);
• you have a rich existing dialplan you want to keep;
• your team is more comfortable with scripts than asynchronous services;
• you’re adding a targeted feature to a stable system.

Choose ARI if:

• you’re building a full voice application (voicebot, contact center, conferencing);
• you need to coordinate multiple channels or bridges;
• you need fine-grained control over media and interruptions;
• you want to expose telephony as an API-driven service, as part of a telephony orchestration layer.

Use both if:

• you’re migrating an existing AGI estate to ARI incrementally;
• simple functions stay in AGI while new flows are built on ARI.

Common pitfalls

• Blocking AGI: an HTTP call without a timeout can freeze the call. Always bound wait times.
• Process per call: with classic AGI, a call spike can overload the server. Prefer FastAGI in production.
• Leaked ARI resources: forgotten bridges, recordings or channels pile up. Build systematic cleanup.
• Non-persistent application state: with ARI, restarting the application must not lose track of calls in progress.
• Security: never expose ARI or AMI without strong authentication and network filtering.

Migrating from AGI to ARI

If you already run AGI in production, there’s no need for a rewrite. A practical path:

1. Inventory your AGI scripts and the dialplan contexts that call them.
2. Pick one self-contained flow (for example a callback request or a lookup-and-route step) and rebuild it as an ARI application.
3. Route a test number to Stasis() for that flow while everything else stays on AGI.
4. Add monitoring for the ARI application: WebSocket connection state, active channels, error rates.
5. Expand flow by flow, keeping a dialplan fallback to the AGI version until each new flow has proven stable.

Conclusion

AGI and ARI aren’t rivals; they’re complementary. AGI remains effective for enriching a dialplan with sequential logic. ARI is the go-to tool for building modern voice applications, especially with real-time AI. The right choice depends on your existing system, your roadmap and your team’s skills.