Your AI Assistant Needs a Backend. Put It at the Edge | Low Latency Club
Skip to main content
Blog<br>Code-first technical deep dives
Glossary<br>Voice AI & telecom terminology
Developer Docs<br>API references & integration guides
GitHub<br>Open-source repos & SDKs
Articles<br>Tutorials & support articles
AI Agents<br>Build voice AI agents
Voice API<br>Programmable voice calls
ClawHouse<br>AI-powered voice assistant
ClawdTalk<br>Conversational AI platform
Events<br>Videos<br>Podcast<br>Integrations
Resources
Blog<br>Code-first technical deep dives
Glossary<br>Voice AI & telecom terminology
Developer Docs<br>API references & integration guides
GitHub<br>Open-source repos & SDKs
Articles<br>Tutorials & support articles
Products
AI Agents<br>Build voice AI agents
Voice API<br>Programmable voice calls
ClawHouse<br>AI-powered voice assistant
ClawdTalk<br>Conversational AI platform
Contact us<br>Join our Slack
Building a voice AI assistant has never been easier. You write a prompt, connect a phone number, pick a model, and within minutes your assistant is answering calls. The first successful conversation feels like magic. Then someone asks:
"Can you tell me where my order is?"
Or:
"Can you schedule someone to come tomorrow?"
At that point, your assistant needs information it doesn't have. It needs to talk to your CRM, your scheduling system, or your own APIs. The LLM isn't the application anymore, it's one component in a much larger system. That's the point where every production AI assistant grows a backend. In this article, we'll build that backend using a single Telnyx Edge Compute function. Instead of deploying another webhook service, we'll use one Go function to handle both dynamic variables and webhook tool calls, verify incoming requests, and connect the assistant to business logic running behind the scenes.
The Architecture
Let's look at what the sample application actually does. The example assistant is named Jordan and works for a fictional home services company. From the caller's perspective, the interaction feels simple. The assistant answers the phone. It greets the caller. It collects information. It schedules an on-site estimate. Behind the scenes, though, two very different backend interactions happen.
Before Jordan says the first word, the assistant requests runtime information that shouldn't live inside the prompt. Later, after gathering enough information from the caller, Jordan needs to schedule the appointment. Both requests are handled by exactly the same Edge Compute function. Conceptually, the architecture looks like this:
Instead of deploying separate webhook services for different responsibilities, one function owns all assistant callbacks. That may seem like a small implementation detail, but it has a few advantages. There's only one deployment, one endpoint, one place to manage secrets, one place to verify requests, and one place to connect your business logic to the assistant. As your application grows, that simplicity becomes surprisingly valuable.
If you would like to follow along, the complete source code for the backend is available in the edge-ai-assistant-backend-go example repository, and the deployment guide walks through configuring the AI Assistant and Edge Compute function step by step.
GitHub repository: https://github.com/team-telnyx/telnyx-code-examples/tree/main/edge-ai-assistant-backend-go
Deployment guide: https://developers.telnyx.com/docs/edge-compute/guides/ai-assistant-backend
Understanding Dynamic Variables
One of the first callbacks happens before the assistant even starts talking. This is where dynamic variables come in. Think about what happens when someone calls a business. The greeting usually isn't static. Maybe you want to say: "Thanks for calling Pinecrest Home Services." Maybe premium customers hear a different greeting or maybe the transfer number changes depending on the office that's currently open. Maybe the estimated wait time depends on today's schedule.
None of that belongs inside a prompt. Prompts describe behavior. Runtime data belongs somewhere else. Dynamic variables solve that problem. Instead of hardcoding values into the assistant configuration, Telnyx asks your backend for them every time a call begins. The function responds with JSON like this:
"dynamic_variables": {<br>"company_name": "Pinecrest Home Services",<br>"timeframe": "two business days",<br>"placeholder_transfer_destination": "+15551234567"<br>One detail that's easy to overlook is the wrapper object. The response must be returned under the dynamic_variables key. Returning a flat JSON object won't populate the assistant variables because the assistant expects a very specific response format. Once those values arrive, they're immediately available inside your prompt. From that point on, the assistant behaves as though those values had always been there. The difference is that they're resolved at runtime instead of being baked into your configuration.
When the Assistant Needs Your Application
Dynamic variables...