XCall AI Assistant
An in-app AI agent that runs a whole calling business from one chat in Bangla or English, also exposed over MCP.
~30,000 lines of agent code, guarded by 1,300+ tests and a scored evaluation set.
XCall is a calling platform for Bangladeshi shops: browser and app calling, call scripts, Bangla AI voice agents, automations, data tables, SMS and team management. The assistant turns all of it into a conversation. An owner says what they want, for example "call these 300 contacts about an offer, then SMS the interested ones", and the agent plans the job, builds the sheet, script, AI agent and automation through the same services the pages use, places a test call, then runs it. It shows the plan with live progress and the cost before spending, asks for approval only where money or customers are involved, and leaves an Undo. One capability registry covers every area of the product, filtered by each member's role, and area catalogues load on demand so the prompt stays small. The same powers are published as an MCP server, so an external AI client can operate a store too. Includes attachments, dictation, result cards and an evaluation set of real requests in Bangla, English and Banglish scored by an LLM judge.
This is a client system, shown as an architecture narrative only: no source code, credentials, or user data are exposed.
Problem
XCall can do a lot, but its users are shop owners and call agents, many of them non-technical and thinking in Bangla. Setting up a campaign meant visiting six pages in the right order: import contacts, build a script or AI agent, wire an automation, test, then pay for the calls.
Constraint
An agent that can spend wallet money and call real customers cannot be allowed to guess. Every member's role permissions had to hold inside the chat too, raw customer phone numbers could not be sent into a model prompt, and the model in use made one tool call per response, so token cost per job had to stay bounded.
Decision
Built the assistant on the app's own services rather than a parallel API, so anything it does is exactly what the page would do. A single capability registry describes every action with its role requirement and safety tier: reads run freely, builds need one approval, spending needs a second, and every change records an Undo. Area catalogues load only when a request touches that area, and the same registry is served over MCP.
Tradeoff
Routing through the product's real services means the assistant inherits every quirk of those services and has to be retested whenever a page changes. Accepted, because a separate assistant API would drift from what the pages do, and drift is how an agent ends up doing something the owner did not see coming.
Result
One conversation now takes a job from "go" to a running campaign with two approvals and no page visits, across calls, contacts, SMS, tasks, team, billing, scripts, agents and automations. (Architecture narrative, company system, no code or data shown.)