What production CX agents need after launch (Sponsored)
Getting a CX agent live is only the first step. The harder work starts once real customers are using it.
Our new guide looks at how teams at Lyft, Vodafone, and LATAM Airlines run CX agents in production. It covers how they evaluate responses, monitor failures, and use production conversations to improve the system over time.
You’ll learn how to:
Keep prompt quality from slowing development
Build observability into the agent from the start
Catch failure modes before they affect more customers
Turn customer conversations into useful signals for support, product, and operations
Choose architectures that hold up in real CX workflows
This week’s system design refresher:
How the JVM Actually Works (Youtube video)
MCP vs RAG vs AI Agents
9 Distributed Systems Patterns You Should Know
Virtualization vs. Containerization
HTTP vs. HTTPS
How the JVM Actually Works
MCP vs RAG vs AI Agents
MCP is an open standard protocol. It connects AI models to external tools and data sources. These can be APIs, databases, or apps like Gmail, Slack, or GitHub. So instead of you writing the integration or doing the integration for each of these applications separately, MCP basically gives you a standard way to connect to these systems.
In RAG, the model pulls the fresh information when a query comes. And this is why the model does not have to make stuff up on its own, but instead it fetches the fresh information from external data sources, like docs, PDFs, and databases, to give the most up-to-date answer to the prompt.
An AI agent is kind of an AI system where the agent performs the task autonomously and takes the decisions. And then making sure everything is working fine, instead of a chatbot, which is really a request-response.
9 Distributed Systems Patterns You Should Know
In replication, you make exact copies of your data and store them on different servers.
In sharding, you break a large database horizontally, so different rows live on separate machines.
In consistent hashing, you distribute data across different machines or servers using a virtual circular ring.
PubSub is an asynchronous messaging pattern that decouples service creators from service consumers.
In circuit breaker distributed pattern, it stops an application from repeatedly executing an operation that is likely to fail.
In Retry with a backoff pattern, you handle temporary network glitches or brief service timeouts. It is a resiliency pattern.
In the leader election pattern, you designate a single master node to manage actions and maintain cluster state. It’s what stops two nodes from thinking they’re in charge.
In quorum read/write pattern, you ensure enough replicas agree on each read and write so that the set overlaps. It is a data consistency pattern that is used in distributed databases to guarantee up-to-date information.
Saga is a design pattern that manages distributed transactions through a sequence of local transactions across multiple microservices. If one step fails, each earlier step is undone by its own compensating action.
Virtualization vs. Containerization
Before containers simplified deployment, virtualization changed how we used hardware. Both isolate workloads, but they do it differently.
Virtualization (Hardware-level isolation): Each virtual machine runs a complete operating system, Windows, Fedora, or Ubuntu, with its own kernel, drivers, and libraries. The hypervisor (VMware ESXi, Hyper-V, KVM) sits directly on hardware and emulates physical machines for each guest OS.
This makes VMs heavy but isolated. Need Windows and Linux on the same box? VMs handle it easily. Startup time for a typical VM is in minutes because you’re booting an entire operating system from scratch.
Containerization (OS-level isolation): Containers share the host operating system’s kernel. No separate OS per container. Just isolated processes with their own filesystem and dependencies.
The container engine (Docker, containerd, CRI-O, Podman) manages lifecycle, networking, and isolation, but it all runs on top of a single shared kernel. Lightweight and fast. Containers start in milliseconds because you’re not booting an OS, just launching a process.
But here’s the catch: all containers on a host must be compatible with that host’s kernel. Can’t run Windows containers on a Linux host (without nested virtualization tricks).
Over to you: What’s your go-to setup: containers in VMs, bare metal containers, or something else?
HTTP vs. HTTPS
When you open a website, the difference between HTTP and HTTPS decides whether your data travels safely or in plain sight. Here’s what actually happens under the hood:
HTTP:
Sends data in plain text, anyone on the network can intercept it.
The client and server perform a simple TCP handshake: SYN, SYN-ACK, ACK
Fast but completely insecure. Passwords, tokens, and forms can all be read in transit.
HTTPS (SSL/TLS):
Step 1: TCP Handshake: Standard connection setup.
Step 2: Certificate Check: Client says hello. Server responds with hello and its SSL/TLS certificate. That certificate contains the server’s public key and is signed by a trusted Certificate Authority.
Your browser verifies this certificate is legitimate, not expired, and actually belongs to the domain you’re trying to reach. This proves you’re talking to the real server, not some attacker pretending to be it.
Step 3: Key Exchange: Here’s where asymmetric encryption happens. The server has a public key and a private key. Client generates a session key, encrypts it with the server’s public key, and sends it over. Only the server can decrypt this with its private key.
Both sides now have the same session key that nobody else could have intercepted. This becomes the symmetric encryption key for the rest of the session.
Step 4: Data Transmission: Now every request and response gets encrypted with that session key using symmetric encryption.
Over to you: What’s your go-to tool for debugging TLS issues, openssl, curl -v, or something else?
MCP / RAG / agents as three layers is clean. Production still fails on the fourth: who is allowed to act. Observability without an approval boundary just records the damage.
Good framing. The MCP section is the one I’d stress-test. “A standard way to connect these systems” is accurate. It’s also where the pain lands: the integration work moves into the policy layer, which decides what the model can touch and logs what it did. The calls that can move money or delete data still need a human sign-off. I’d also quibble with the agent definition. “Performs the task autonomously and takes the decisions” describes the demo. In production the loop proposes and the policy layer decides. Bounded retries and a tested kill switch. The diagram’s missing layer keeps you employed.