Building an enterprise-grade infrastructure for omnichannel customer service AI

This post explains how we rebuilt our development engine to get new features to you faster, while simultaneously removing software clutter to significantly tighten our security.

Paul Annetts Principal Engineer
3 min
Share

Overexcited AI engineers love to talk about models and latency…ahem, guilty as charged. But for enterprise buyers, the real deal-breakers are security, reproducibility, and scalability.

At PolyAI, we treat the underlying technology that powers our AI just as seriously as the AI itself. We recently upgraded our central foundation to ensure we meet the strict reliability and safety standards required by major global banks, healthcare providers, and retailers.

This post explains how we rebuilt our development engine to get new features to you faster, while simultaneously removing software clutter to significantly tighten our security.

Reproducibility at scale: The move to Bazel

We manage a massive backend monorepo that powers our conversational agents. To handle this scale, we migrated from plz to Bazel, the build system developed by Google.

Why it matters to partners:

  • Hermetic builds: Bazel ensures that inputs (dependencies, language versions) perfectly match outputs. This means the code we test is exactly the code we deploy to your environment, i.e., no but-it-works-on-my-machine surprises.
  • Velocity: With 79.3% of our build system already migrated, we use aggressive caching to ship updates faster.
  • Support across coding languages: We can seamlessly integrate Python, C++, and other languages in a single build pipeline, allowing us to use the right tool for your specific integration needs.

Security blanket: Adopting distroless containers

Traditional Docker images are bloated with junk (package managers, shells, and unused libraries) that widen the attack surface. Our solution at PolyAI is to use rules_distroless to automate the creation of minimal container images.

The security payoff for clients:

  • Reduced attack surface: Our production containers have no shell and no package manager. Even if an attacker found a way in, they have no tools to move laterally.
  • Rapid patching: In the event of a global vulnerability (like Log4J or Heartbleed), our automated pipeline allows us to rebuild and patch the entire fleet in minutes, not days.
  • Compliance: Smaller, cleaner images mean fewer vulnerabilities to track and patch, simplifying security audits for ourselves and our partners.

Reliability & isolation: A modern deployment architecture

We have unified our CI/CD pipelines on GitHub Actions, aligning our internal workflows with modern industry standards.

We are prioritizing architecturally separating our Build/Test environment from our Production/Staging environments by moving CI to a separate AWS account and aim to complete the process in early 2026. This separation will prevent “noisy neighbor” issues and ensure that rigorous load testing never impacts live client call volumes.

We don’t guess; we run comprehensive Bazel tests on every single master push and nightly, rebuilding test images automatically to ensure immediate feedback on stability.

Future-proofing: Efficiency and cost control

We are integrating support for ARM processors. This allows us to leverage modern cloud compute instances that are faster and more cost-efficient. In other words, we run a lean, sustainable operation capable of scaling cost-effectively as call volumes grow.

Conclusion

This update is about maturity. It’s about moving from “startup speed” to “enterprise velocity.” When you choose an AI partner, you aren’t just buying a voice bot; you are buying the engineering team and the infrastructure behind it.

Request a demo to find out more about how PolyAl can help you resolve up to 90% of calls, access first-party customer data, optimize phone support in an instant, and deliver effortless CX at scale.