Building enterprise dialog AI with the PolyAI ADK

Own the code behind your enterprise dialog agents — build on PolyAI's ADK from your terminal.

Brady Walker Senior Content Marketing Manager

Jun 30, 2026

6 min

Every enterprise AI platform you have worked in has made the same architectural decision on your behalf, and it is worth naming plainly: the agent lives in the vendor's system. You configure through a UI someone else controls. When something needs to change — a prompt, a flow, an escalation path — the path runs through a services team and a ticket queue and a deployment window that is not yours to set.

This is a structural commitment the platform made on your behalf, usually sometime before you were in the room. The developers who understand the agent's behavior best — who built the integrations, who know the edge cases, who got paged at 2am when something broke — are the furthest from the code that produces it.

ADK is PolyAI's architectural answer to that situation. The premise: developers who build and maintain enterprise dialog agents should own the code, work in their own environment, and ship on their own timeline.

But owning the code only matters if you understand where it actually lives — and that requires a clear picture of how the stack fits together.

How the stack fits together

ADK is not a standalone tool. Understanding where it sits in the stack shapes how you use it and what you can reasonably expect from it.

Agent Studio is the shared system — where agents run at scale, where analytics and monitoring live, where enterprise governance is enforced. It has been PolyAI's core platform for years, deployed across contact centers in healthcare, financial services, utilities, retail, and hospitality.

ADK is the build layer that sits in front of it: your IDE, your terminal, your YAML files. The web call and chat modules are the distribution layer — browser-based, WebRTC, no telephony integration required to test or demo an agent.

The relationship that matters: the YAML files ADK manages locally are the same underlying configuration a non-technical colleague can view and edit in the Agent Studio browser UI. Different interface, identical data. poly push sends your local changes to Agent Studio. poly pull brings remote changes back. You do not choose between the two interfaces; you move between them as the work demands.

The build workflow

The fastest path from zero to a working agent runs through a handful of commands. If you want to accelerate the initial build, a coding agent running alongside your project changes the math considerably.

For self-serve accounts, poly start handles signup, API key generation, and initial project setup directly from the terminal. No browser required, no procurement process. Enterprise teams authenticate with poly login --region instead.

Once authenticated, poly init connects your local environment to an existing Agent Studio project. YAML files load into your IDE: topics, flows, configurations, agent settings. From here, the workflow splits into two paths, and most developers use both depending on what they're building.

The direct path: edit YAML in your IDE, create a working branch with poly branch create, inspect changes with poly status and poly diff, test locally with poly chat, push when satisfied. The agent-accelerated path: open Claude Code or Cursor alongside the project and feed it source material — a website URL, a PDF, a call script, a call transcript — and let the coding agent scaffold topics and flows from that material.

Dane Street lead developer Ben Pottinger on what this unlocked for his team: "The PolyAI ADK unlocked a massive increase in our development velocity. By bringing our dialog agents into standard, Git-like local workflows, our engineering team can iterate, validate, and push updates across multiple projects with incredible speed."

The workflow is familiar because it is designed to be. Your IDE, your branching, your tools. The ADK commands are the interface to Agent Studio, not a replacement for the environment you already work in.

What "80% in 45 minutes" means

Early deployments have reached 80% of a production-ready agent in under 45 minutes. What that figure means precisely: an agent with knowledge, flows, and functions built out and testable via poly chat. You can interact with it, stress-test it, identify gaps. That is the baseline a developer reaches in under an hour.

The remaining 20% is environment promotion — moving the agent from development through to production. That step is also doable directly from ADK. The full deployment cycle, terminal to production, without leaving your tools.

Two things determine how fast you close that gap. The first is the quality of your source material: a detailed call script or well-structured knowledge base produces a stronger first draft than a sparse website. The second is the templates already baked into ADK's project structure — guardrails encoding PolyAI's deployment expertise from real enterprise accounts. Those guardrails are already in the scaffolding when you run poly init.

One honest note on coding agents: output varies. Fast and accurate when they work; requiring iteration when they don't. This is the state of the tooling, not an ADK-specific constraint. The guide gets you to a working, testable agent faster than any platform that routes changes through a services team. The refinement is yours. When you are ready to ship, that step is yours as well.

The model layer

PolyAI's proprietary LLM, Raven, was built specifically for voice-based customer service. General-purpose models handle text well; they were not trained on the conditions that make dialog AI hard in production: overlapping speech, background noise, callers who speak in fragments, the low-latency demands of a live phone call. Raven was. In internal benchmarks and live A/B tests against GPT-4o and Claude, Raven outperforms on the metrics that matter in a contact center. When you build on ADK, model quality is not a variable you need to solve for — it is already in the stack.

Enterprise considerations

ADK is not a new product and not an added SKU. It is an expanded entry point into Agent Studio targeted at technical teams that previously had no path to work the way they wanted to work — in code, in their own environment, on their own schedule.

For engineering leadership evaluating the platform: a developer working in ADK is building into the same system that runs production deployments for enterprise accounts. Monitoring, analytics, agent management — all unchanged, all sitting in Agent Studio. The governance layer does not need to be bolted on after the fact; it is already in the project structure from the moment you run poly init.

The practical implication for enterprise teams is the co-build motion: developer hands in the tools, agent behavior traceable to code the team owns, path from sandbox to production running through a system that engineers understand rather than a vendor queue they don't control.

The platform entry points now cover the full spectrum — Agent Studio for teams who prefer a browser UI, ADK for teams who live in the terminal, the Agent Studio API for teams building custom integrations. Different entry points for different working styles, within the same organization, against the same underlying platform.