Enterprise GenAI · Customer Operations
CygnusAlpha
Multi-tenant GenAI platform: RAG and multi-agent automation for enterprise customer operations on chat, email, social, voice bots and automated follow-up calls.
- Client
- Enterprise clients incl. Badho.in and Ferns N Petals
- Domain
- AI customer support
- My role
- Led the platform
The problem
- Repetitive, expensive supportMost tickets were routine status questions, handled one by one by human agents.FixAI agents answer routine questions on every channel, including voice bots and automated follow-up calls.
- Answers live in other systemsOrder status, balances and account details sit in CRMs and internal APIs, not in documents.FixAgents read live data from each client's CRM and order systems.
- Acting safely, not just talkingLetting AI change records is only acceptable if every action passes the rules a human would.FixA short list of allowed actions, each checked against the client's business rules.
- One platform, many clientsEach client needs its own data, prompts and limits on shared infrastructure that holds up under load.FixOne multi-tenant core: per-client data, prompts and limits on an event-driven backbone.
How it works
- 01A tenant's customer writes on WhatsApp, email or social and reaches that tenant's own agent; voice calls and follow-up calls go to a separate voice agent.
- 02The agent hands it to the tenant's workflow: receive, guardrails, classify, fetch, rule check, respond.
- 03The workflow calls the agents on the LangGraph runtime (Router, Knowledge, Action), which read and write the data stores and the client's tools.
- 04The answer or a rule-checked action goes back; hard cases go to a person, follow-up calls go out automatically.
The agents
Each request is handled by a small team of agents. Every agent gets only the tools its job needs, and only Action can write.
- Router
Reads the request and picks the right agent.
no tools, routes onlyNO TOOLSe.g. "refund" goes to the Action agent - Knowledge
Answers from the client's own content, with retrieval.
search client contentREAD-ONLYe.g. A return-policy question - Live data
Reads the client's CRM and order systems, read-only.
order lookupREAD-ONLYaccount lookupREAD-ONLYe.g. "Where is my order?" - Action
Takes only allowed actions, each checked by business rules.
create ticketWRITE · RULE-CHECKEDupdate recordWRITE · RULE-CHECKEDe.g. Raises a support ticket - Voice
Voice bots answer calls, and automated follow-up calls go out, on the same agents.
speech in and outVOICEfollow-up callsVOICEsame tools as chatREAD-ONLYe.g. An automatic follow-up call - Hand-off
Passes hard cases to a person, with full context.
human queueWITH CONTEXTe.g. A disputed refund
Key insight
An AI assistant becomes production-ready when it is allowed to do less: a short list of actions, every one checked by rules it cannot override.
- order lookup
- create ticket
- update record
- any refund
- delete data
- change prices
The hard parts
- AI that changes data. Every change is checked against the client's business rules.
- Production, not a demo. High load, many clients, strict uptime, all at once.
- Quality over time. Changes are evaluated locally before reaching a client.
- The trade-off. Two vector stores - Pinecone for the managed production path, ChromaDB for local iteration and evals - some duplication in exchange for not running vector infrastructure ourselves.
My part
I led the platform: the event-driven service architecture, the RAG and multi-agent pipelines, and taking it to production for 5+ enterprise clients on a 99.9% uptime SLA.
What I took away
- Give an assistant a short list of allowed actions, not open access.
- Keep business rules where the model can't override them.
- The cheapest regression is the one a client never sees.
Want the detail behind the numbers - architecture, failure modes, what I’d change? Happy to walk through it.
Talk about this project →