Addo AI makes AI do the day job

The problem arrived in a queue. A healthcare transport company, growing at 60% a year for three years, was fielding around 50,000 customer interactions daily. Its contact centre could no longer absorb the enquiries. People needed rides booked, bookings retrieved, plans changed. Growth had produced a rather ordinary bottleneck: too many people waiting for somebody to help.

Addo AI built an agent spanning web, mobile, WhatsApp and SMS, with fifteen service flows and a handoff to human staff for complex cases. The company reports that the agent handled 80% of queries and reduced service-agent spending by 65% in year one. Those are Addo’s figures for this particular deployment. The interesting detail is what the agent could actually do: book, change and escalate.

The queue was the clue

That distinction matters to anyone who has watched a chatbot confidently explain a policy while leaving the underlying request untouched. An answer can be useful. A completed booking changes the operation. Addo occupies the space between those two events, connecting models to the permissions, records and decisions that make a business function.

Its work extends well beyond conversation. In a shipping engagement, empty containers were occupying valuable dock space while planners relied on unpredictable arrivals and ageing assumptions. Addo combined siloed operational data in a pipeline, built forecasts and fed them into scheduling. It reports 86% prediction accuracy and an 11% improvement in capacity utilisation. Here, AI’s contribution was a better estimate of where an empty box would turn up.

Two founders, one inconvenient problem

Ayesha Khanna and Faisal Kamiran founded Addo in Singapore in 2017. Khanna brought experience building information analytics systems on Wall Street and an academic background spanning economics, operations research and information systems. Kamiran brought machine learning research and a doctorate from Eindhoven University of Technology. The pairing helps explain the firm’s range: a boardroom business case at one end, the engineering needed to deliver it at the other.

Addo lists Singtel, Pfizer, SMRT, Mercy, Visa and Schneider Electric among its customers. These are organisations with existing systems, operating rules and consequences for mistakes. A hospital cannot casually substitute a charming answer for the right patient information. A bank needs to know which documents an employee is entitled to see.

The market position is therefore closer to an AI specialist and systems integrator than a self-service software subscription. A buyer might also consider a large consultancy such as Accenture or Capgemini, a smaller engineering firm, or an internal team. Addo’s pitch combines strategy, custom implementation and continuing operations. Its breadth across AWS, Microsoft, Google Cloud and Salesforce lets it work within several established technology environments.

Sometimes the job begins underneath the model. In a healthcare data-platform engagement, duplicated and fragmented datasets blocked timely insight. Addo describes a governed cloud platform built with Azure services and Databricks, and reports halving infrastructure costs. The work includes cleaning up the information on which later AI applications depend.

The plumbing gets a name

Addo calls its reusable architecture Addo Core. Context describes the business: its customers, contracts, rules and records. Agents perform tasks using that context. Learn turns outcomes and corrections into tests and improvements. Control manages permissions, approvals, models and spending limits. The design makes custom delivery more repeatable without pretending every customer runs the same business.

There is a revealing example in banking. Addo describes a compliance agent running on a bank’s own servers, using a fine-tuned Llama model and roughly 25,000 to 30,000 regulatory documents and notices. It compares internal policies with related requirements, flags gaps and recommends changes. Addo reports a 72% reduction in manual review time. The location of the model matters alongside its capabilities: the data stays inside the bank.

A manufacturing HR project makes the same idea easier to picture. Employees ask policy questions, raise leave requests and track tickets through one conversational service. Addo reports handling more than 18,000 monthly enquiries across a workforce of over 5,000, with average responses under two minutes instead of 24 hours. The connection to HR systems gives the conversation somewhere useful to go.

Start with the bill, then the baseline

Buying this work means choosing who will own it. Addo offers a fixed-fee path from pilot to production, managed agents priced by volume with outcome-linked options, and programmes built and operated before transfer to the customer. Each arrangement assigns a different amount of ongoing responsibility to the client. A spending reduction in a case study should never be mistaken for the price of the project.

The customer also contributes people and access. Addo’s delivery method calls for a workflow owner, an IT contact and a leadership sponsor. The team measures current performance, tests against historical cases, then introduces live work gradually. A target must hold for four consecutive weeks before that deployment phase is complete. This gives the buyer something more concrete to discuss than whether a demonstration looked impressive.

“Weeks to the first live workflow”

Addo AI’s stated delivery ambition

The useful kind of friction

Readers can borrow the method before hiring anyone: select one frequent task, name its owner, record today’s cost and waiting time, and define an unacceptable mistake. Test the proposed automation on cases people have already resolved. Give it additional authority only when it passes. This is an editorial takeaway from Addo’s published process, rather than a promise that every workflow should be automated.

The conditions matter. Inaccessible records, contradictory policies and errors with serious consequences make automation harder. Addo’s research lab explicitly studies interrupted workflows, duplicate submissions and incomplete feedback from older software. Those problems explain why reliable delivery needs more than a capable language model. For a buyer, the decisive question is wonderfully practical: can the system complete this particular job, under our particular rules, often enough to be trusted?