Unified Communication Infrastructure
CommAgent
Centralized communication platform replacing fragmented legacy systems across Email, SMS, WhatsApp, and Voice.
Problem
The communication stack was fragmented across legacy systems. Every service that needed to reach a customer implemented its own email, SMS, and voice integrations — different providers, different retry logic, different failure modes.
The cost wasn't just duplicated code. It was operational: when a provider degraded, services failed in different ways. Nobody could answer "did this message reach the customer?" without digging through logs across systems. Adding a new channel meant touching every consumer.
Solution
CommAgent replaced the fragmented systems with one centralized communication platform. Services describe what they want to send — a message, a channel preference, a recipient — and the platform owns everything after that: provider selection, delivery, retries, and status tracking. It now powers customer and operational communication across 100+ customer environments.
The core is an adapter architecture. Each channel (Email, SMS, WhatsApp, Voice) is an adapter implementing a common contract: send, status, and inbound webhook normalization. Providers are swappable behind adapters, so a failing provider can be routed around without any consumer changing code — and new channels integrate rapidly.
Every message flows through one pipeline — validation, templating, routing, dispatch, delivery tracking — which is also where the agentic workflow platform hooks in, so AI agents can communicate across any channel as part of multi-step workflows.
Architecture
Consumers never talk to providers. The unified API is the only entry point, and adapters are the only exit point — everything between is channel-agnostic.
State lives in one place. The message store is the source of truth for delivery status; webhooks mutate it, and consumers subscribe to changes instead of polling providers.
Challenges
Retries without duplicates
Providers fail mid-request, and "did it send?" is often unknowable. Every send is idempotent — keyed by a client-supplied idempotency token — so retries are safe by construction, and a dead-letter queue catches what exhausts its retry budget.
Webhook ordering
Delivery receipts arrive out of order: a "delivered" event can beat the "sent" event it follows. Status transitions are modeled as a monotonic state machine, so late or reordered events can never regress a message's state.
Provider failures
Health checks and error-rate tracking per provider feed a circuit breaker; when a provider trips, traffic shifts to a fallback within the same adapter without dropping in-flight messages.
Observability
Every message carries a trace ID from API call to provider callback. One query answers the question that used to take an afternoon: where is this message, and what happened to it?
Lessons
Design the adapter contract around the ugliest provider, not the nicest one. The clean APIs fit any abstraction; the messy ones define its real shape.
At-least-once delivery plus idempotency beats chasing exactly-once. Accepting duplicates as a fact of distributed systems simplified every layer above.
Observability isn't a feature you add later — the per-message trace ID was the single highest-leverage decision in the system.