"Batch campaigns write for a persona. This system talks to a person."
https://www.loom.com/share/a96b6efb337a4ca8b461858a9d1e3d16
A full working demo of an AI-native customer lifecycle management product, built for telecom companies. Three-layer agent architecture running over WhatsApp. Strategy defined by humans, execution handled entirely by AI.
Built for live client pitches at Boring Workflows, a 4-person telecom AI startup, during a 4-month internship.
This wasn't a prototype with hardcoded flows. It was a general system: any customer, any segment, any configuration.
Telecom CVM teams run batch campaigns. Segment customers into groups. Send the same message to 100,000 people. Measure open rates. Repeat.
The structural problem with that model is that the message is written for a persona, not a person. A customer who just upgraded their plan gets the same upgrade nudge as someone who's one month from churning. The system doesn't know the difference and doesn't try to.
The hypothesis behind AutoCLM was that a different model is possible: one where the strategy is written by a human CVM team, but the execution is handled by an agent that actually knows the individual customer and adapts in real time based on how they respond.
The engineering challenge was making that general, not just demonstrable. A system that works for five customers because their journeys are hardcoded is not interesting. The architecture needed to handle any customer, any segment, any blueprint configuration.
The system is built around hard architectural separation between strategy, planning, and execution. Most multi-agent demos have separation on paper. Here it's enforced in the code.
Layer 1: Blueprint Engine
A YAML-based strategy layer authored by the CVM team. A Blueprint defines engagement rules, tone of voice, offer limits, message frequency caps, and guardrails per customer segment. It expresses what the business wants to happen. It never talks to a customer directly.
Layer 2: Journey Agent