Platforms that stay up, and the AI built on top of them

Challenge

Enterprise messaging is sold as one product and is really three. RCS, the WhatsApp Business API and SMS each arrive with their own provisioning model, their own template rules, their own carrier relationships and their own idea of what "delivered" means. Sales sells a platform. Engineering inherits the differences.

Constraints

Multi-tenant from the first line, so one tenant’s traffic spike cannot become another tenant’s outage and no tenant can ever see another’s data. Every send costs real money, which makes a retry that fires twice a bill rather than a warning. And the carriers sit upstream: their rate limits, outages and schema changes are facts to absorb, not bugs to fix.

Trade-offs

A queue between the API and the carriers instead of sending inline. It costs immediacy and a lot of operational surface, and buys back per-tenant rate limiting, ordered retries and somewhere to stand when a provider goes down. Idempotency keys on every send, paying the storage and lookup cost, because double-charging a client is unrecoverable in a way that latency never is. One internal message model with thin per-provider adapters, so a new carrier costs an adapter rather than a fork. Delivery receipts arrive as webhooks and land in a reporting store kept separate from the operational one, so an analytics query can never slow down sending.

Outcome

It runs as the core of the CPaaS product across all three channels, and onboarding a new enterprise tenant became a configuration exercise rather than an engineering project. The send path was never the hard part. The work that decided whether this was any good was the provisioning, the delivery tracking and the reporting around it - none of which anyone has ever asked to see demoed.

Challenge

Support conversations that a person handled well and a scripted bot handled badly. Putting a language model in front of them is the obvious move. The non-obvious part is that a model which is right most of the time is a liability in a channel where every reply goes out under a client’s brand, to their customer, with no way to take it back.

Constraints

It runs across many tenants, each with their own catalogue, tone and rules, so there is no single prompt to tune and no single definition of a good answer. Every token is billed and every second is felt, because someone is watching a typing indicator while it thinks. And a wrong answer is not a bug report - it is a customer who now believes something untrue.

Trade-offs

An evaluation suite before any of the interesting work: a golden set of real conversations, model-graded scoring, and regression tests running in CI, so a prompt change became a reviewable diff instead of a vibe. Routing ordinary turns to smaller models and reserving the expensive one for the turns that earn it, which costs architecture and saves most of the bill. Prompt caching and context compression in preference to simply buying a longer context window. Structured outputs everywhere, because a parse failure is far easier to handle than a confidently wrong sentence. And a deliberate handover to a human when confidence drops, which lowers the automation rate on purpose.

Outcome

Automated resolution rose and escalations caused by wrong answers fell, but the durable result was the harness rather than any particular prompt. Once every change had to clear the same set of conversations, prompt engineering stopped being folklore and became something a team could review, argue about and roll back.

Challenge

Several products, years of accumulated Angular, and a framework that had moved a long way underneath all of it. The application booted by loading nearly everything it might ever need, real-time conversation state was handled by whoever happened to write that screen, and each product had quietly grown its own version of the same button.

Constraints

These are tools people use to do their job, so there is no maintenance window and no appetite for a rewrite. The upgrade had to cross several major versions without a release where the product stopped moving. And the team was shipping features throughout - nobody was ever going to fund a quarter of pure refactoring.

Trade-offs

One major version at a time, shipping after each, which is slower and considerably more boring than jumping straight to the latest and never leaves the product broken. Legacy modules refactored into a lazy-loaded architecture so the first paint stopped paying for screens most users never open. Real-time state standardised on RxJS with a single pattern for subscription lifecycles, because the race conditions were not hard bugs - they were the same bug written many times over. And a shared component library across products, accepting the coordination cost, so that a fix lands once.

Outcome

The applications load faster on a smaller bundle, and a framework upgrade is now routine rather than an event. The more useful outcome is quieter: new screens start from a component that already exists, so the interesting decisions get spent on the product instead of on re-deciding what a table looks like.

Challenge

A busy life is spread across a wearable, three inboxes, a bank, a broker, a calendar and a notes app. Every one of them organises information and none of them remove work. The assistants shipping today make that worse: they are reactive, so you have to ask; siloed, so each sees one domain; and theatrical, so they impress on a stage and change nothing on a Tuesday.

Constraints

It reads health, cycle, money and mail, so private data cannot leave the device by default. It is self-hosted and privately deployed, built in the hours around a full-time job. And it has to hold one line that never moves: prepare anything, send nothing. No email, no payment, no irreversible action, at any level of trust.

Trade-offs

On-device inference first with the cloud as a fallback that never sees raw data, which spends capability to buy privacy. A deterministic ladder - rule, cache, reasoner, projection, then a model - rather than calling an LLM for everything, trading elegance for latency and near-zero running cost. Autonomy is earned by matching how the user would have judged it, in shadow, about ninety per cent of the time, rather than granted by a settings toggle. And it counts what it decided not to say, because in this category silence is the feature.

Where it stands

The reasoning is built and in daily use: the cross-domain brain, the model of the user, forecasting, and the per-domain agents. The honest read is that it knows considerably more than it reliably acts on, so the bottleneck now is reach and action rather than intelligence. That is the better problem to be left with, because behaviour can be measured and iterated and intelligence mostly cannot.