Here's the headline: you shouldn't notice anything.

What's actually changing

Under the hood, this is one of the more significant changes we've made to the portal in years. Login moves from our own custom flow to an industry-standard OpenID Connect service running at auth.simwood.com, built on Keycloak - the same battle-tested open-source identity platform trusted by banks, governments, and Fortune 500s alike.

When the switch happens, the login page will look a little different (same Simwood branding, new address), and that's the extent of it:

• Your email and password work exactly as before. No reset, no re-registration, no "welcome to the new system" email demanding action.
• Your two-factor authentication carries over. If you use an authenticator app today, the same app and the same codes keep working.
• Everything in the portal behaves as it did. Same features, same account, same permissions.

In our earlier post we said the migration would involve an invitation to set a new password. We've since done better than that: credentials migrate transparently, and your existing password is seamlessly upgraded to the new platform the first time you log in. The best migrations are the ones you never notice, and we've engineered this one to be exactly that.

Why bother, then?

Because what you don't see matters, and because of what it unlocks.

The new flow is built on the OAuth 2.0 Authorization Code flow with PKCE - today's standard for browser-based login - with short-lived access tokens, refresh tokens in httpOnly cookies the browser's JavaScript can never read, and central session management so a revoked login is revoked everywhere, immediately. Your portal session now carries the same granular scopes as our API keys, so one consistent permission model governs every request that touches the platform, whether it came from a script or a person.

Managing your login remains self-service, now through a dedicated account console - change your password, manage two-factor authentication, and, new this time, review and revoke your active sessions, all without a support ticket.

But the bigger reason is where this takes us next.

What it unlocks

Our old login flow was ours alone, which meant every improvement to it was ours to build alone. Standing on an open standard changes the economics entirely. On the roadmap, in rough order:

• Passkeys. Passwordless login using the biometrics already on your device - Face ID, Touch ID, Windows Hello, or a hardware key. Phishing-resistant by design, and faster than typing a password ever was. This is the one we're most excited about, and the new platform supports it natively.
• Sign in with the identity you already have. Google, Microsoft, and GitLab to begin with - handy for teams who manage access centrally and would rather not maintain another password at all.
• Finer-grained roles for your team. Today it's owners and users; the same scope model that powers our API keys lets us offer more precise roles over time, so you can grant a colleague exactly the access they need and nothing more.

None of these were realistic on the old system. All of them are natural extensions of the new one.

What you need to do

Nothing. That's the point.

The switchover is imminent. When it lands, log in as normal; if you're curious, the only tell will be the address bar reading auth.simwood.com for a moment while you sign in. As ever, if anything doesn't behave as promised, our support team wants to hear about it - but we've tested this one to the point where we'd be surprised.

We said earlier in July that authentication was being done right. This is what that looks like when it reaches the portal: a foundation you can't see, carrying features you'll soon be very glad of. Watch this space!

Every day, tens of thousands of calls try to cross our network and don't make it. Not because of congestion, not because of a fault - because they were scams, sprays, and spoofs, and we stopped them. Over a million a month. Fifteen million in the last year, and growing.

We tightened the net hard through last summer, and at the peak we were rejecting nearly six in every hundred call attempts based on their identified signature. If you've heard us cite "around 5% of traffic", that's the era it comes from, and it was true. It is about half now owing to two factors.

Traffic across our network has two sources - our own customers where we see 100% of their attempts usually, and other networks where we see a proportion of their attempts broadly equivalent to our market share. In the worst cases, we’ll see both - traffic across multiple customer accounts and attempts coming in across multiple peers. We’re agnostic about origin, it all gets treated the same, but we can and do terminate accounts. Sometimes this is within days of passing KYC and having service established. Other times, it's long-standing customers who have regrettably been seduced by apparently easy money. We don't discriminate: bad is bad.

What we’ve seen is a substantial reduction in the proportion originating on-net (of the 100% we see) and a substantial increase in that which originates off net (of the market-share percentage we see). This is of course in part traffic from those accounts we've terminated which has been welcomed with open arms by others. But the vast majority is simply the ongoing inflation in this type of traffic. Over the past year, the share of hostile calls in the traffic our peers hand us has roughly doubled - across every peer.

Part of the driver for this is simply economics. Wholesale phone calls are so cheap and actually free for the originator unless they connect. So turning up the volume, harassing more end users remains a lucrative and viable business, even if only a tiny proportion of them ever engage positively.

We tried to encourage Ofcom to change these motivations in a recent consultation, sadly to no avail.

One network in particular who we have called out repeatedly for their pious virtue-signalling, and specifically in the context as the “Fox in the Hen House”, has KYC requirements as pitiful as their technical standards. By our measurements, they are ten times more likely to be the origin of a spam call than the cleanest of our peers - which, credit where due, is BT. We won’t allow our customers' end-users to be ripped off or harassed, even if they will. I presume this is lax KYC rather than wilful targeting of that market segment, but the result is no different for the poor person on the receiving end.

That is based on the route traffic takes but it is equally interesting if one looks at the Range Holders problem numbers are assigned to. There are some really bad ones but if we look at the top 10, and then consider which networks host these, let’s just say it looks like the route probability would suggest. The smallest of aforementioned hosting operators is clear number one, with 5.6x BT’s number of blocked calls. Market-share weight this and things get exponential. Simwood, despite hosting more ranges than the number one spot, and seeing 100% of the traffic by virtue of the sampling taking place on our network, doesn’t appear on that list at all. So this appears to be Range Holders with lax KYC, favouring hosts with lax KYC, who also have lax KYC over the traffic they pass. How many times can you say correlation isn’t causation before giving up?

I’d dearly love to publish these league tables, maybe as a real-time dashboard like we have internally. I think they’d be really insightful to policymakers and hopefully drive responsible CPs to make different choices. Unfortunately various rules in our industry introduce hurdles to that. Maybe Ofcom will s135 us for this data? The blurred images above are the best we can do for now.

The result of all this on our side is a dramatically cleaner network: the failed-call share has fallen, and the population of abusive numbers originating here at any moment has fallen by roughly two thirds.

Meanwhile, excluding the effect of customers terminated, our catch rate is rising. Same customers, sharper filter. That's the pair of numbers that matters: cleaner network, keener blade.

Despite us catching more bad stuff in a cleaner population, the really important thing for us is false positives. Anyone can block 1m calls and in fact we’ve already told Ofcom we could block 30m just by enforcing one of their long-standing rules. The trouble is, doing so unilaterally we’d be out of business because those blocks would result from decades of poor discipline by other operators, either not knowing or not caring about the existence of said rule.

We treat blocking a legitimate caller as a serious incident. The entire system is engineered backwards from that:

• No block is forever. Every block is time-limited and expires automatically. A number is re-judged on what it does next, not on what it did once. However, persistent offenders now escalate, i.e. the blocks get longer each time.
• Every block candidate gets a second opinion. An independent AI adjudicator now reviews the evidence behind every candidate - and it argues in both directions. It can overturn a block as readily as confirm one, and every verdict it gives is logged and scored against what actually happened next.
• Evidence protects the innocent. Numbers with genuinely healthy calling relationships are structurally protected - a borderline signal cannot block them. And where evidence is missing or stale, the benefit of the doubt always goes to the caller. Absence of proof is never treated as guilt.
• We audit our misses, not just our mistakes. We now randomly re-examine traffic we cleared, so we can measure false negatives as rigorously as false positives - and tune the balance on data rather than anecdote.

Everything above is measured against real outcomes, continuously. This month we validated a new early-warning technique against a full year of enforcement history - strictly past-predicting-future - and found it concentrates almost half of the next month's brand-new offenders into a third of a percent of the number space. That means checking bad numbers before they've hurt anyone, not after.

That is a difficult one because compliance won’t always allow us to act upon the profiling of a number based on which Range Holder on which network and which interconnect the calls come from, even though statistically that gives great signal. The danger comes where some innocent user has seen the light and ported out which fails our false positive rule.

We also had an independent machine-learned model audit our hand-built rules: it agreed with every one of them, which is either reassuring or suspicious, and we choose reassuring - it also found two new signals we're now evaluating.

None of it ships as blind automation. New signals face direct scrutiny first and blocking only with corroboration. The system is learning all the time, both from its own evolving baselines and the signal of proven hypotheses. There are now well over 40 proven factors go into any block/don’t block decision, which individually have high statistical probabilities before tying them together.

Lastly we have recently licensed TPS and CTPS data. Calling those numbers isn't signal on its own because we don’t know the intent of those calls, but there are some interesting patterns in there which will no doubt help over time. One of the aforementioned operators purports to offer TPS screening as a service, despite not being a licensee of the data. Curious in itself considering the other data points.

Nuisance calling is an ecosystem problem. Every network that tolerates it - through indifference, through fear of the support tickets that come with imperfect blocking, or because the margin on a spam machine is too nice - keeps the problem alive for everyone. Our experience says the fear is misplaced: block precisely, expire automatically, review everything, measure both error types, and bin abusers. The only question is whose network they land on next, and our stats already answer it.

We would be very interested to hear from other network operators who would be interested in a feed of what is blocked, especially what is blocked coming from their network.

Klarna is the poster-child for this. In early 2024 they announced, proudly, that their AI assistant was doing the work of 700 customer service agents. Fifteen months later the CEO was on record admitting that optimising for cost had produced lower quality, promising customers would always be able to reach a human, and hiring people again. But before anyone in telecoms enjoys that too much or takes any kind of affirmation from it: at least Klarna bothered to try. At least they moved, learned something expensive, and corrected.

By contrast, our industry cannot even be bothered to make the mistake. I've heard it said that "AI is for our customers to build". They just don't get it - and here's the uncomfortable bit - even if they did get it, they couldn't act on it, because acting on it requires infrastructure and operations somewhere near this millennium. You cannot point intelligence at a business run on spreadsheets, fax-era processes and a billing system nobody dares touch. Well you can, but it is a much bigger ask, and a bigger roll of the dice by those who have proven effort- and risk-aversion.

My own conclusions came from having no choice. My recent health and long-standing family situation mean I don't have the luxury other CEOs take for granted any more, especially in respect of time and geo-mobility. The only way for me to compete is to be massively more productive in the hours I do have, and I'd argue I am, despite one hand tied behind my back. Automation and recently AI amplification is how: the mornings my inbox used to eat now belong to the work only I can do. I realised amplification works because I had to operate this way, and that lived experience is the whole philosophy in miniature - don't replace the human, amplify them, make them superhuman. If it does that for someone running with a handicap, imagine what it does for a whole team at full strength. Everything we've built recently reflects this.

What's been interesting, having arrived there out of necessity, is looking up and realising I'm not alone. Jensen Huang has been telling audiences "you're not going to lose your job to an AI, but you're going to lose your job to someone who uses AI" - true, though I'd go further, and will below. Erik Brynjolfsson gave the phenomenon a name years ago: the "Turing Trap" - build machines to imitate humans and the best you can ever achieve is a cheaper human; build machines to augment humans and you create things that were impossible before. Klarna walked straight into the trap. Much of the queue behind them is still shuffling forward.

And then there's the opposite camp, which is louder. Dario Amodei - whose company builds the very models we use, so hardly a luddite - warned that AI could eliminate half of all entry-level white-collar jobs within five years. On the narrow point he's probably right: if AI can do the meaty-medium tasks you used to hire junior people for, you'll need fewer junior people. But the bloodbath framing misses what happens at the other end, which is where the real story is.

We've been here before, incidentally. In weaving, the power loom was going to decimate employment in the mill towns - places with no other industry - and people smashed machines over the fear of it. What actually happened is one of the most instructive statistics in economic history: over the 19th century, automation removed 98% of the labour needed to weave a yard of cloth. Now you could read that as it took 98% of jobs but in fact by 1902 a single weaver minding 18 power looms produced 50 times what their predecessor had a century earlier. Employment should have collapsed by any replacement logic. Instead, not only did a single weaver achieve 50x more, but the number of weavers quadrupled between 1830 and 1900, because cloth got so cheap that demand exploded. That is a 200x improvement in output with an expansion of employment.

Of note, the people who were ruined weren't weavers as a class - they were the handloom weavers who kept doing it the old way while the world industrialised around them. Read that again with today's headlines and particularly telecoms in mind. The job didn't go extinct - it grew exponentially - but the people and businesses that refused the technology did.

A senior manager used to leverage themselves through a team of ten humans, and spent most of their week diluted across managing them - the coordination, the checking, the chasing. Give that same manager ten AI agents instead and the dilution disappears. They're not managing anymore, they're amplified: the judgement that made them senior applied at ten times the surface area. I made exactly this point to Raj, our CRO, in our 1:1 last week. The conventional playbook says hire x more people to do back-office functions in support of account managers. The better answer is ten-plus agents doing the work agents can do, with the budget that would have gone on those hires spent instead on humans doing the things only humans can do - the relationships, the trust, the judgement. And here's the twist: as AI becomes ubiquitous, the human bits don't get less valuable, they get more valuable. Everyone will have the agents. Not everyone will have people freed up to be human. Replacement shrinks a business to save cost. Amplification multiplies what the same business can do, and redeploys the humans to where humans compound. These are not the same strategy, and they emphatically do not produce the same outcome.

This is running in both directions at Simwood - outwards in what we ship, and inwards in how we work.

Outwards, Conversation Intelligence is amplification made product. When a fraud signal fires mid-call and a whisper delivers guidance into the handler's ear, the AI hasn't taken the call off the human - it's made that human better at their job than they could ever be alone. The handler with an Operator watching their call is not a cheaper handler. They're a superhuman one.

Inwards is where it gets more interesting, because this is the part no customer will ever see. I wrote recently about kaizen that remembers - me and an agent doing a task together once, it documenting every decision as it's made, and it just happening from then on. These are the tasks where previous automation efforts couldn't quite reach. What started as email triage is now something closer to an operating system we're expanding across the business: standing rules, codified skills, memory that executes rather than a wiki that rots. I said to Charles only last week that there is little point newly humanising processes with internal portals and the like when we can liberate the human altogether to a level we couldn't imagine in our last round of automation - which itself led to the requirement for the button for the human to click. Our biggest wins are increasingly coming from the unglamorous internal plumbing - reconciliations, month-end, reporting, the thousand paper cuts of running a carrier - places nobody outside the business will ever see. Competitors won't see any of it, they'll just wonder, as they probably do now, how a company our size is this insanely productive, the same way they've spent a decade wondering how we run a network like ours with a team the size of ours.

But here's where it gets exponential, and where I think the extinction actually happens.

By my reckoning Simwood is 10 to 15 years ahead of our peers on infrastructure, and objectively 20 years ahead of those who prefer to invest in Ferraris to show (themselves) how successful they are. We've consistently been a generation or two ahead at every turn. Despite being significantly smaller than many of them, our margins are ahead of businesses 100 times our size because our operation is more efficient - our financial statements are public if you want the receipts. That lead was built the slow way, over decades, a few percent at a time. And now we're ahead on AI adoption too - the entire Conversation Intelligence platform was designed, documented, built and shipped by a small team amplified in exactly the way described above. We could not have built it at all, under any previous model, with the team size we have.

Think about two cars that accelerate at the same rate, where one simply starts sooner. The second car never catches up - the gap is permanent even with identical performance. The follower can spend a lot more on a faster car - I mean literally invest in the business not themselves - and might gain a few percent faster acceleration. They can spend telephone numbers buying our customers too but the common thread is spending a lot more, in the often vain hope of catching up. In the old paradigm that could work in theory, although I've yet to see it in practice in telecoms.

However, now amplify the first car's acceleration ten, a hundred, a thousand-fold, because that's what AI adoption does to a team that already knows how to move - and remember the compounding: every rule written down, every skill codified, makes the next amplification cheaper. By the time the second car pulls away from the line, the first isn't merely ahead - it's over the horizon. The word "race" doesn't even apply and no realistic amount of money makes catch-up feasible.

I've been generous here in assuming the laggards recognise the need to even leave the start line, which, given some of them still don't have a usable API in 2026, and survive servicing knuckle-draggers, is quite the assumption.

So yes, I think AI is an extinction-level event. But the thing going extinct isn't the human's job, it is the businesses that can't move. Those businesses are the ones that are already inefficient, already a decade behind, already hanging on by their fingernails - the ones who could just about survive against competitors marginally better than them, but cannot survive against competitors 10, 100 or 1,000 times more efficient. Remember what happened to cloth prices - the laggards simply could not compete. Huang had it nearly right: you won't lose your job to AI, and your business won't lose to AI either. It will lose to a business that uses AI. The asteroid isn't aimed at your staff. It's aimed at your slower competitors, or - if you wait, or if you think AI is something your customers should build - at you.

Which brings me to the part that really excites me. This revolution is one where size doesn't matter; Simwood is proof of that. What matters is agility and adoption, and every one of our customers has both available to them. Since we launched Conversation Intelligence I've watched new businesses being formed on top of it, and existing customers genuinely getting it - taking what we've given them and developing their own propositions at a pace that would have been impossible in conventional times. The best part: they're augmenting their own people with AI in order to build on the AI capabilities we've handed them. Amplification stacked on amplification. That's the exponent doing its work, and it's available to a two-person startup just as readily as to us.

I genuinely think we're only years away from a trillion-dollar company, run by a single person. The asteroid has already hit. The only question left is whether you made it outside the crater. Your move.

The point of writing about these, as I said at the time, is that they're the only way to show the work and investment behind an architecture that's designed to survive this stuff. I do so not to gloat (although some will disagree) but because it is a genuine point of differentiation and I live in no small hope that those who have other priorities for investment (Ferrari-cough, cuddly-dogs-cough) might be motivated to up their game. This industry improving benefits us all, not least end-users and our customers who cannot solely depend on us in an industry that is by its very nature interdependent.

I write now because you’ll see another entry on our status page for Monday (13 July 2026 if you’re reading this in the future) relating to our Slough Availability Zone (AZ). It might have cost some of you a portal login, an API call, or a chunk of an afternoon trying to update your locked balance; or you might not have noticed. It is more likely you did notice because this actually affected some services ancillary to our main services - actual call volumes were normal and not a single 999 call failed (we specifically alert on that, however caused). There’s learning here for us though, and everything I said above would be hypocrisy if we didn’t similarly share. I’d also sooner you heard the truth from source rather than a distortion from a Mustard Moron in some dark corner at the CCUK Christmas party. 

So… there are four factors at play here that set some context: 

• Firstly we’ve been refreshing hardware around the network. You won’t have noticed because that’s how we’re designed. The London AZ, the Manchester AZ, Newport which isn’t an AZ but regrettably still exists - all done. Slough, next on the list and thus still running old gen hardware and build. 
• Secondly, you’ll have seen us talk about new auth and you’ll have probably seen that relating to the API already in the portal and you may even be using it. The portal itself hasn’t been moved across yet - for you at least, we’re using it in staging. That means it is dependent on an API you’ve never heard of (v4) which should never have existed and was written way back in the day by a French man - our resident chaos monkey, a title he’ll still be proud of - because he was fed up of waiting on another former colleague to make the changes he needed to API v3 - the one you do know and love. It has sat as middleware for selected portal functions (like login) for way too long. v4 is completely replaced by the new API architecture, which I’ll call v5 for simplicity even though it introduces independently versioned services starting at v1. So v4 never existed and v1 comes after v3; with me so far? Good.
• Thirdly, we rely heavily on DNS for global service discoverability where local load-balancing or internal anycast can’t cut it. For that we use DNSMadeEasy and in particular their Constellix product which allows automatic failover of records and we’re hooked into its API for dynamic updates. They used to happen within the TTL (15 seconds) which was great. Constellix was bought by Digicert in 2022 and it's apparent their standards have deteriorated.
• Lastly, we recently parted ways with a long-serving and very capable engineer. That left gaps in ownership and institutional knowledge we hadn't fully backfilled - which matters below.

That's the context. I hasten to add not excuses, the ownership comes later!

So, at 14:27, an old host in our Slough AZ died. Not gracefully - disk I/O error, no IPMI, no way to even power-cycle it remotely. It was one of the older boxes on the estate, with less monitoring wired into it than anything we've bought in the last few years, and it had passed a health check a month earlier. It just went, the way hardware does, with no warning anyone could have acted on. 

But that is what we plan for and nobody outside of our DevOps team should have noticed. Other hosts have failed the same way more than once this year and it's been a non-event every time, because they're on current hardware with proper out-of-band management and deployed to our current standards. This one wasn't, and that's the actual story here.

We have hundreds of container images, deployed dozens of times in some cases, making for a large estate. Within AWS we use Kubernetes to orchestrate this, but in our three on-net UK AZs, they use Docker with our own network stack. This is something I’ve blogged and presented on many times in the past as, uniquely, a container is a first class citizen on the network, speaks BGP to its host, pushes its own firewall rules to the edge etc. etc. All good but a lot to orchestrate and therefore we have strict policies around deployment to ensure availability between AZs and across hosts within an AZ. Anycast makes light work of this for many things - just run them everywhere - other things such as our database of record Galera is a cluster with a node per AZ, ElasticSearch is sharded and distributes shards according to its own strict policy and so on. We also make enormous use of Redis - like 500,000 requests a second levels of use - around the network. Read nodes are anycasted so everything consumes it closest, often local, usually on the same box, for minimum latency. If you know Redis though you’ll know it has a single master under which everything else is a slave. To manage the master-candidates around the network we use Sentinel, which seamlessly promotes a new master and ensures everything uses it. Much code is hooked in to use Sentinel to benefit from this but certain code which can’t instead uses DNS which is updated automatically on a state change.

The box that died had all of the above on it, as well as loads of other services. They all, even Galera, did what they should and just got handled. Manchester and London AZs, as well as the many on AWS, and our Global Edge, all continued completely uninterrupted exactly as they should. That is worth celebrating I think because I don’t think any of our competitors would have gone without a major outage losing primary database nodes, let alone primary nodes across dozens of services. But this isn’t about them, and we hold ourselves to a higher standard.

What didn’t work was Redis. Sure, the slaves carried on working, as designed, which is why other sites didn’t skip a beat and why call volumes remained normal (voice runs on different hosts altogether - Voice Compute Nodes (VCNs) vs Compute Nodes (CNs) in our parlance), but nothing could write to the master because Sentinel hadn’t failed over. Also, a load of services which rely on Sentinel to discover the new master failed to connect because there simply wasn’t one - the old one was in Slough on a host which was now dead. It's fair to say all hell broke loose in Slough and a cascade of weirdness ensued.

Notably portal logins failed on Carrier Services because API v4 couldn’t connect to Redis. Portal logins failed on Hosted for similar but independent reasons. API endpoints like ‘calls in progress’ stopped working because call events weren’t being processed and customers relying on the balance-update endpoint were understandably concerned, since the API writes to Redis as well as Galera and couldn't. It didn’t matter though because millions of CDRs weren’t being billed because requisite services couldn’t reach Redis. Finally, we also lost a SIP proxy in Slough which was wrongly deployed on the Compute Node which had failed, but I’ll return to that.

On investigation we found out that Sentinel didn’t exist anymore. Rather than existing in every site per our spec, it only existed in Slough on the old host which had failed. Let's say that was an ownership problem in origin - Sentinel hadn't been deployed elsewhere as hosts had been upgraded, so Slough was the only node. I believe in decentralised command - or trusting people to do their job - especially where people are technically so capable, but the reality is you can’t delegate accountability and we did. We have to own that and make sure it can’t happen again.

In terms of mitigation, we didn’t just want to stand up a new Sentinel with unknown consequences for the now unmanaged cluster so we promoted a new master manually. That triggered a DNS update but the services which use DNS for discovery of the write node didn’t update. It turns out that despite a 15 second TTL, Constellix took over 30 minutes to push the change out. Digicert’s support team wasn't aware of the product last time we contacted them recently and we were in the middle of forcing changes in other ways when the change took. That left the other services which consumed Sentinel in order to discover the write node; Sentinel which wasn’t there anymore. They needed patching, testing and deploying one-by-one to resolve. That had to be done in priority order and meant some things, themselves 2 minute fixes, took longer to resolve than they otherwise would have done. 

Out of hours after the incident we redeployed Sentinel and, with appropriate escape routes in place, let it control the cluster. It did so with the poise and lack of drama we know and love it for, and which it would have done during the day had it been there.

That covers pretty much all the weirdness customers saw with two exceptions. 

The first was “calls in progress” and “locked balances”. The latter was a simple case of Redis writeability being restored and that was one of the earlier services to be fixed. However, customers polling the calls in progress endpoint and firing off updates to locked balances were seeing an out of date balance simply because calls in progress wasn’t updating - a low priority thing to address. It wasn't low priority to them as they believed they’d run out of credit any second or that their change hadn’t worked; even when writability was back and CDRs were catching up, they were updating their locked balance to an impossible figure by virtue of decrementing a historic figure.

The second was the outbound carrier proxy in Slough. The customer facing proxy was working as was the rest of the stack but on the way out of the network there is another edge proxy in every AZ. We knew this was down from our monitoring, and some customers in Community Slack even told us, but it was low priority as voice calls were working fine according to our own automated testing and volumes. In days gone by the very first thing we’d have done in an incident like this is modify DNS to fail traffic away from the affected AZ, regardless. On this occasion we didn’t and that was a mistake, even though it would have been far more latent than designed due to Constellix issues. When a new carrier proxy was deployed onto the VCNs, the correct home, Slough was back to 100% even with the other Redis based issues. I stand by our record since 2018 that voice continued working across the network as other sites were unaffected and even Slough telemetry was fine. However, we did have a couple of tickets from sensible customers who experienced odd issues and we owe it to them to work through those thoroughly and mitigate them in future if there is a way of doing so.

There are two books I love. The first, Black Box Thinking, contrasts airlines with healthcare in terms of how one learns from mistakes and the other covers them up. I’m determined we’re more like the airlines and continue to improve wherever we can, and like the airlines, share that knowledge. The other one is Extreme Ownership by Jocko Willink. Jocko recorded the intro for the SimCon just before the pandemic for those who were there. I hope this post demonstrates how we embrace his teachings. One of his expressions is “discipline is freedom” which I think really captures the true root cause here. Yes, it was a Redis failure resulting from a hardware failure, but that was designed out of being a problem 10+ years ago. The reality is that for all the designs, and playbooks and testing, we ultimately relied on someone to do their job. The fact he took shortcuts is our problem and we should have identified and remedied them before they had an opportunity to cause an issue. The spine running through all of that is a lack of discipline.

There are a few lessons and actions here which we’re applying or have already applied:

• Sentinel is everywhere, per the design
• Services which were patched to bypass Sentinel are being corrected and redeployed
• We need to look at DNS to find an alternative or at least mitigation for Constellix. We already use another dynamic DNS provider for our Kubernetes services.
• We need to investigate and address those presumably carrier proxy derived edge cases.
• We need to fail-over DNS away from affected sites in such an incident in future, as we used to, rather than being overconfident in the local redundancy in place.
• The staging portal will be rolled out to customers ASAP, enabling v4 API to be retired.
• The chaos monkey role is very helpful and we’ve missed the sharpness having one causes. The longer stuff works, the more scary it breaking becomes and the rustier you are at responding. We intend to program in regular datacentre visits (even if no work is planned) and part of their function will be to trigger failures, to test redundancy and keep everyone sharp. Impending legislation requires annual reboots anyway so this is a necessary direction of travel everyone will have to take.
• Containerisation, as I’ve opined many times before, ensures every version of every container is identical, which was a massive win for us a decade or more ago. We can’t have an instance like some of our peers where two magic boxes have different manual configurations. But, only policy directs the placement of those containers and requires them not to be changed without going through a change control and deployment process. It is very clear we need to use some of the amazing tools at our disposal now to enforce that policy. We will have a single pane of glass, separate to monitoring, which visually enforces our policy and would have told us that Sentinel wasn’t compliant with it in terms of running instances and their placement, with the bonus of verifying the signature of the code running to affirm it hasn’t been “hot fixed” since deployment. That wasn’t an issue here but could have been and can be easily mitigated at the same time. Exposing policy violations enables them to be addressed when it isn’t an emergency and necessary changes made to ensure they don’t happen again. As we say in Bitcoin: trust, but verify. 
• Slough upgrades are being prioritised to complete the rollout.

I hope that provides some assurance and explanation to all those who wondered what was going on. This isn’t an RFO as the O didn’t happen, but it was far closer to happening than we’ve been in a long long time and shouldn’t have been. We pride ourselves on our architecture and technical performance so flog ourselves more than anyone outside ever could. We appreciate you trusting in us to do so.

As usual, these changes are colour-coded in our full rate files available through the portal as below. Where your account has custom rates, these are now reflected in the rate files. Remember, if you'd like more granular prefixes (inc. NPA-NXX) or a more compact rate file, we've got you covered.

Unlike other operators, we are not passing on UK origin surcharges, relying instead on our advanced technology to protect you and us from this industry's latest sleazy money-grab. We will maintain this position as long as possible so our customers do not need to worry.

Rate files Full rate sheets with codes are now only available through the portal or from our API for active customers. Once logged in to the portal you can find them in the "commercial" section.

The SMS A-Z rate sheet is now available on our portal or via API.

Please contact our sales team if you are not a customer and would like to see our rates.

Ancillary charges (inc. SMS & fax) Our charges for ancillary services can be found here.

100% SLA Our Service Level Agreement (SLA) for our UK carrier services customers is a guarantee of 100% Simwood service availability. Read more here.

MSA Our MSA is here.

Acceptable use policy Our AUP is here.

Hardware supply schedule Our Hardware supply schedule is here.

Hosted pricing Looking for Hosted pricing? Click here.

There’s a category of engineering problem that doesn’t show up in postmortems or sprint reviews: the slow accumulation of undocumented decisions. Nobody documents the decision in the moment because the context is obvious – everyone involved knows why. Some time later, that context is gone, and someone makes the same mistake again, or undoes something that was done deliberately, or spends days rediscovering reasoning that exists somewhere in a Slack thread from years ago.

I actively monitor our developer Slack channels. It’s not unusual to see someone “fixing” something that is apparently obviously wrong and very much was done that way for a reason – a reason that would have been right in front of them if it had been recorded anywhere. In our case, “some time later” can mean twenty years later. The decisions made in the early days of the platform are still embedded in the codebase, often with no trail left to explain why. This is a cost that compounds, quietly, for as long as the product lives.

Architecture Decision Records (ADRs) are the tool the Simwood engineering team now uses to stop that accumulation.

An ADR is a short structured document that records a decision: what was decided, what the alternatives were, what the reasoning was, and what the follow-on questions are. Written at the time the decision is made. Stored in the codebase alongside the code it relates to. Never deleted – only superseded, with a link to the successor.

This might sound like bureaucracy. It is not. A well-written ADR takes perhaps twenty minutes to produce. In return, it gives any future engineer the ability to understand why the codebase looks the way it does. The auth model uses ForwardAuth claims injection for a specific reason – documented in an ADR. The Keycloak migration is being done via bulk import rather than on-demand provisioning for a specific reason – documented in an ADR. These decisions exist. Without ADRs, they exist only in memory. With ADRs, they’re searchable.

ADRs are internal. They contain implementation details, open questions, and reasoning that isn’t relevant to API consumers. They’re not published at docs.simwood.com; they live in the internal platform docs repository, alongside architecture briefs and service guides that are equally internal.

The simwood-docs MCP (Model Context Protocol) server makes this internal documentation queryable by AI agents working on the Simwood codebase. When an AI is helping an engineer work on a service, it can consult the ADRs directly rather than working from first principles or from assumptions about what might have been intended. “Is there a recorded decision about how API key revocation is handled?” should have an answer, not require trawling Slack history or asking whoever was there at the time.

This is a specific, practical consequence of documentation-first development. The investment in writing good ADRs pays off here in a concrete, immediate way: the AI can reason about decisions that have been recorded, and it can flag when it encounters something that appears inconsistent with a recorded decision. It’s also why Part 2 describes AI as integrated into the development process rather than just assistive – the documentation is the context that makes that integration work.

There’s an onboarding benefit too. When a new engineer joins and asks “why does the auth model work this way?” – the answer should not be “ask Charles.” The answer should be: “Read this ADR.” That’s it. Question answered, without involving anyone else’s time.

The discipline of recording decisions as they’re made is not natural. Most engineers find it easier to get on with building. What Charles and his team have demonstrated is that the upfront investment – writing the brief before the code, recording the decision before moving on – pays back quickly and compounds over time. The codebase is more navigable. The AI assistance is more accurate. New team members get productive faster. The institutional knowledge that would otherwise walk out the door when someone leaves is preserved in a form that stays.

The template for adding a new service – the checklist, the ADR format, the guide structure – also lives in the internal docs. Which means the process of adding a new service is itself documented, followable without asking anyone, and improvable over time.

This is the last post in the series. If you’ve read all twelve, you now understand something that I think matters: the platform isn’t just the Conversation Intelligence features, and the features aren’t just code. They’re the product of a process – documented before it was built, AI-integrated throughout, decisions recorded so they can be found – that we think is genuinely better than how most engineering is done. We’ll find out whether that’s right over the next decade.

For now: the platform is live, the docs are real, and the APIs work. If you’re building on it, we want to hear how it goes.

Previous: Part 11 – Documentation as a product

Back to Part 1 – series index

Most API documentation in telecoms is a reference dump. A list of endpoints. Parameters, types, response codes. If you’re lucky, an example. If you’re very lucky, an example that actually works.

This is not adequate. A reference is useful when you know what you’re looking for. It is nearly useless when you’re trying to understand how something works, why it works that way, or how to combine capabilities to achieve something real. Developers who hit a reference dump when trying to figure out a new platform spend the first hour reading the same three sentences over and over and then go to find someone to ask. That’s a failure of documentation design, not developer competence.

The restructured docs site at docs.simwood.com is built on a different principle: reference is for lookup, guides are for learning. They are different things and should be written, maintained, and presented as different things.

The structure separates the two cleanly.

Platform-level guides cover things true across all services: how authentication works, how the gateway model works, how versioning and deprecation work, what error conventions to expect. These don’t belong to any single service – they’re the foundation. You read them once, early.

Per-service structure gives each service its own section: a service overview (what it does, when to use it), narrative guides covering the core workflows and patterns, an API reference generated directly from the live OpenAPI spec, and code examples. The narrative guides are hand-authored; the reference is auto-generated. Both are updated when the service changes – the reference automatically, the guides by the team responsible for the service.

The principle that drives this split: if a piece of documentation is explaining why something works the way it does, it’s a guide. If it’s specifying a parameter name and its type, it’s reference. Mixing the two produces something that’s bad at both.

The interactive explorer is worth spending a moment on, because it changes how you work with documentation.

Every service in the docs portal is served via Scalar – a modern API reference UI with a live “try it out” capability. You enter your API key directly into the explorer, choose an endpoint, fill in the parameters, and send the request. The response comes back in the browser. You don’t need to open a terminal, construct a curl command, or paste values between windows. You can explore a new endpoint in thirty seconds.

This sounds like a quality-of-life detail. It isn’t. The gap between “I can read what this endpoint does” and “I have seen this endpoint work against my actual account” is enormous in terms of developer confidence. Reducing that gap to thirty seconds changes how quickly new developers get productive and how much time the support team spends answering questions the docs should have answered already.

Real keys, real requests, real responses, in the browser, without setup. That’s the bar.

The technical implementation reflects the independent service architecture described in Part 8. Each service exposes its own OpenAPI spec at /{service}/{version}/openapi.json. The spec is the authoritative contract for that service, owned by the team responsible for it, published automatically on merge. The documentation portal reads the live spec URL rather than a copy – which means the reference is always in sync with what’s actually deployed. The usual failure mode for API documentation – it describes a version of the API that no longer quite matches what’s running – is eliminated.

Adding a new service to the docs portal is a single entry in the service registry file. No restructuring required.

We’re not writing this post to claim the docs are perfect. We’ve historically been terrible at documentation and our customers have forgiven us more often than we deserved. What we’re committing to is the principle: documentation is a product. It gets investment, it gets maintained, it has ownership. The alternative – reference dumps six months out of date, no narrative guidance at all – isn’t where we’re going.

Developers talk about documentation. Not in formal surveys – in Slack, on community forums, in comments on posts like this one. “The docs are actually good” is a competitive differentiator in the developer tools market, and it’s one that takes sustained commitment rather than a single sprint. We’re sustaining it.

Previous: Part 10 – Deprecation as a feature

Next: Part 12 – Internal documentation that actually gets used

Back to series index

“We’re retiring this endpoint” is a statement that has earned its bad reputation. In practice it usually means: we decided internally to stop supporting something, gave you as little notice as legally necessary, and your integration broke on a date you may or may not have noticed in an email you may or may not have read.

We’ve been on the receiving end of that. It’s rubbish. So when it came to migrating 200 endpoints out of a monolithic API into independent services, we had to decide what “done well” actually looks like – and then commit to it publicly, which is what this post is.

The policy is straightforward. When a v3 capability is re-expressed as an independent service, the corresponding v3 endpoints are deprecated. From the day the successor service is published, there is a minimum 12-month window before those v3 endpoints are retired. During that window, every response from a deprecated endpoint carries two headers:

Sunset: 2027-06-04

Deprecation: true

Link: <https://api.simwood.com/voice/v1>; rel="successor-version"

The Sunset header gives the exact date the endpoint stops working. Deprecation: true makes it machine-detectable – your monitoring can alert on it if you want. The Link header points directly to the successor. Your HTTP client library probably already supports parsing these; many logging and observability tools do too.

The 12-month window is a minimum, not a target. If migration turns out to be complex for a significant portion of customers, we extend it. The point is not to get to the end of the window as fast as possible; it’s to give customers enough runway to migrate without it becoming a crisis.

The v3 decomposition covers twelve target services. In priority order: Conversational AI, WhatsApp, and Messaging first (already thin proxies in front of independent backends, so re-fronting them is lowest risk). Voice, Numbers, and Billing next (higher-change, higher-visibility, larger contracts). Then Porting, Lookup, Account, and the Platform Connect carrier services – BYOC, Operator Connect – as capacity allows.

Conversation Intelligence (/intelligence/v1) is already live as the reference implementation – the first service that went through this whole process, which is why it’s the right model for everything that follows.

I want to say something about the principle here, not just the mechanics.

To be straight about the context: the API deprecation framework described here is relevant to the industry with APIs. Much of the telco industry doesn’t have APIs at all – some carriers we deal with have barely moved beyond fax. We’re not talking about them. We’re talking about what good looks like when you’ve committed to building something developers can rely on, and deprecation policy is one of the clearest tests of that commitment.

The way we think about deprecation is that it’s a statement of care, not abandonment. “We’ve built something better and we’re telling you about it with enough lead time to move” is a fundamentally different message from “we’ve decided to stop doing this, good luck.” The 12-month window, the machine-readable headers, the direct link to the successor – these are details that add up to a developer experience that treats customers as if their time matters.

Practically: the API documentation shows the current status of every service and endpoint. Deprecated endpoints show the Sunset date and the successor link. New integrations should use the independent service APIs rather than v3 for anything where a service equivalent exists.

If you’re currently using v3 endpoints that are in the deprecation queue, you’ll hear from us directly well ahead of the Sunset date. We’re monitoring gateway logs for usage of deprecated endpoints and will reach out proactively to any customer who hasn’t migrated as the window approaches.

The goal is that nobody’s integration breaks unexpectedly. That is a solvable problem if you take it seriously enough to commit to the process. We’re committing.

Previous: Part 9 – Authentication done right

Next: Part 11 – Documentation as a product

Back to series index

Authentication is one of those things where the gap between “works” and “done right” is enormous and mostly invisible until something goes wrong. This post is about what “done right” looks like for a platform serving developers, the browser portal, and native apps simultaneously – and what’s changing for existing customers. Quick note on availability: the new platform and Conversation Intelligence API are currently in beta, available to customers enrolled in the carrier services beta programme. API keys are live now. Portal login via OIDC is the next stage.

The platform is designed around three authentication mechanisms. All three are handled by the ForwardAuth shim described in Part 8. All three produce identical claims headers before the request reaches any service. Downstream services have no idea which mechanism was used.

Bearer API keys are for machine integrations – server-to-server calls, automation, CI pipelines. Keys carry scopes at issuance; a key issued with intelligence:read can read Intelligence API resources and nothing else. Keys are stored hashed – the plaintext key is shown once at issuance and never again. Revocation takes effect within one sync cycle, approximately one minute.

This is what’s live now.

Bearer JWTs via Keycloak are for the portal and native apps. The portal uses OAuth 2.0 Authorization Code flow with PKCE – that’s Proof Key for Code Exchange, not passkeys (a different and newer standard). PKCE is an OAuth 2.0 extension that prevents authorization code interception: rather than relying solely on a client secret, it adds a cryptographic challenge-and-verifier pair generated fresh on each login attempt, so intercepting the authorization code alone isn’t enough to get tokens. The access token lives in memory – not localStorage – and the refresh token lives in an httpOnly cookie. This is current best practice for browser-based apps: it prevents XSS token theft while keeping session management clean. Native apps use the same OIDC flow but store tokens in the device secure enclave (Keychain on iOS, Keystore on Android), with credentials entered in the system browser rather than the app itself.

This is the next stage – rolling out shortly after launch.

Basic Auth remains only for the legacy v3 Wholesale API credentials, as a transitional bridge. It is not a platform authentication mechanism and is not available on any new service endpoint. Once the portal Keycloak migration completes and all customers have issued API keys, the v3 Basic Auth bridge will be retired.

The ForwardAuth shim distinguishes these mechanisms by prefix and delegates accordingly. Both paths inject the same claims headers before the request proceeds – account ID, scopes, tier, key identifier. A service should never need to care how a request was authenticated. Its job is to enforce scope and execute business logic, not understand credential formats. The gateway enforces that separation.

Scopes follow the pattern resource:action. Examples:

intelligence:read   intelligence:write
reporting:read      account:admin

Scopes are stored on the key record at issuance and included in the claims on every validated request. Services check scopes before executing any operation. A request attempting a write without the appropriate write scope gets a 403 with a clear error indicating the missing scope.

The scope taxonomy is defined per-service, with each service introducing its own scope root when it’s added to the platform. Account-level scopes are the baseline every account receives; all other service scopes are product-gated. This is how the platform ensures that a Conversation Intelligence API key can’t accidentally – or deliberately – access Billing data.

The Keycloak portal migration will affect existing users when it rolls out. The portal currently authenticates via a custom login flow with credentials stored in localStorage. That will be going away. The replacement is Keycloak running at auth.simwood.com, handling the login UI, credential validation, and token issuance with Simwood branding. For existing portal users, the migration will involve a bulk import of existing credentials into Keycloak and an invitation to set a new password. Once cutover, the old login flow is gone and Keycloak is the only entry point. We’ll communicate directly with all portal users ahead of the switchover.

The security improvement is real. Credentials in localStorage are vulnerable to XSS. Access tokens in memory are not. httpOnly cookies for refresh tokens are not directly accessible to JavaScript at all. This is not a theoretical improvement.

For developers building against the platform: if you’re currently using Basic Auth against v3, nothing changes immediately. You have a minimum 12-month window from the deprecation notice to move to an API key. Your existing integrations continue working during that window. New integrations against new services use API keys from day one. Basic Auth is not available on new service endpoints. That’s a feature, not a limitation.

Previous: Part 8 – A new API architecture

Next: Part 10 – Deprecation as a feature

Back to series index

The Conversation Intelligence platform didn’t get built on top of our existing API. It got built alongside a replacement for it – and understanding why we replaced the architecture matters if you’re going to build on what we’ve shipped.

The existing Wholesale API at api.simwood.com/v3 has served us well for a long time. It also has approximately 200 endpoints, no independent versioning, monolithic documentation that nobody enjoys reading, and an authentication model that involves passing credentials through a central proxy. Every service on the platform is coupled to every other service through that proxy. Teams cannot ship independently. The API surface has expanded without bound. The documentation is a perpetual backlog.

This is a familiar failure mode for any API that grows organically over years without architectural revision. The solution is also familiar: decompose it. But decomposing a 200-endpoint API that customers are actively using, without breaking them, requires a plan rather than a rewrite.

The new architecture is built around three components.

Traefik is the gateway. It handles routing, TLS termination, and rate-limiting. That’s all it does – it doesn’t know anything about authentication or business logic.

The ForwardAuth shim sits between Traefik and the upstream services. When a request arrives, Traefik calls the auth shim to validate the credentials. The shim validates and injects a set of standard claims headers – account identity, scopes, tier, and key identifier – into the request. Traefik then forwards the enriched request to the upstream service.

Each service reads those headers and trusts them. No service calls a central auth service at runtime. No service re-validates credentials. The gateway handles authentication once; the service handles authorisation locally using the claims it receives.

The result is that services are completely decoupled from each other and from the auth infrastructure. A service doesn’t need to know whether the client authenticated with an API key, a Keycloak JWT, or (for legacy clients) Basic Auth. It receives claims, it checks scopes, it executes the request, it returns a result.

The v3 Wholesale API continues to run unchanged on this infrastructure. It routes through Traefik and ForwardAuth exactly like the new services, gaining all the security improvements without any changes to its own codebase or URL structure. Nothing stops responding overnight. The v3 path stays stable for each capability until that capability’s deprecation window closes.

New capabilities are never added to v3. They’re built as independent services. And existing v3 capabilities are being progressively re-expressed as services: each domain becomes its own versioned service, and the corresponding v3 paths are then deprecated under the standard policy. The v3 decomposition map sets out the full picture – which domains become which services, in what order.

The target is twelve services, each independently versioned, each with its own OpenAPI spec and documentation. Numbers, Voice, Messaging, Billing, Account, Porting, Lookup, BYOC, Operator Connect, WhatsApp, Conversational AI, and Conversation Intelligence. Each one ships when it’s ready. Each one evolves on its own schedule.

Independent versioning is one of the things that sounds obvious in retrospect but is genuinely difficult to retrofit. In a monolithic API, a breaking change to one endpoint requires a version bump for the entire API surface. In the service model, a breaking change to the Voice service requires a new version of the Voice service – nothing else is affected. The Numbers team can ship a v2 of their API without consulting the Billing team. A customer using only Messaging doesn’t need to care about a Voice API change.

The URL carries the version: /intelligence/v1/, /intelligence/v2/. When a breaking change requires a new version, both versions run in parallel until the deprecation window for the old one closes. Part 10 goes into the deprecation policy in detail.

Every service in this architecture follows the same conventions. It reads claims from headers – never re-validating credentials itself. It filters every query by the injected account identity – never trusting account identity from request parameters. It enforces scopes on every operation. It exposes a live OpenAPI spec at /openapi.json. It versions independently on breaking changes only.

Those conventions aren’t suggestions – they’re how the architecture works. A service that trusts account_id from a query parameter rather than the injected claim is a security hole. A service that doesn’t expose an OpenAPI spec can’t be included in the documentation portal. The conventions are what make the system coherent rather than a collection of loosely related services.

The practical benefit for customers is that the API surface becomes manageable. Instead of one enormous reference document covering 200 endpoints, there’s a service index with clear scope, a per-service reference that covers only what that service does, and a documentation portal (covered in Part 11) that lets you explore and try things interactively.

The practical benefit for us is that teams can ship. A team working on the Voice service doesn’t need to coordinate with a team working on Messaging. The gateway handles the plumbing; the services handle the business logic; everyone ships at their own pace.

Previous: Part 7 – Conversation Memory and vCon

Next: Part 9 – Authentication done right

Back to series index

Per-call analysis is useful. Intelligence that compounds across calls is transformative.

A single conversation, however well-instrumented, tells you only what happened in that conversation. But calls don’t exist in isolation. The customer calling about a billing dispute today may have raised the same issue last month and the month before. The number showing elevated fraud signals this morning may have appeared in a suspicious context twice in the past fortnight. The caller who sounds distressed may have a documented history with the service that explains why. None of that context is available without some form of memory – and building it from scratch, per customer, is exactly the kind of problem that doesn’t get solved until someone decides to make it a platform primitive.

Conversation Memory is that platform primitive.

Every completed conversation produces a vCon – a Virtual Conversation record. vCon is an open standard (RFC draft, shepherded by the IETF) that defines a portable, self-contained representation of a conversation. It includes the parties involved, the transcript, references to the media, and all derived analysis: Operator outputs, tags, collected data items, structured results. The vCon is the definitive, complete record of what happened in a conversation, expressed in a format that any compliant system can read.

The choice to use vCon rather than a proprietary format matters. It means the conversation records the platform produces are not locked to Simwood’s infrastructure. They’re portable, queryable by any system that understands the standard, and yours.

vCons are stored in the customer’s own S3-compatible object storage – the same bring-your-own-storage capability the platform already supports for call recordings. The conversation record never leaves the customer’s infrastructure. The Memory service indexes and queries it on the customer’s behalf, but ownership and custody are unambiguous. Simwood does not hold your conversation history; you do.

This is a deliberate design choice, not a concession. Conversation records contain sensitive information – the content of customer calls, fraud signals associated with specific numbers, compliance deviations, health and distress indicators. That data belongs with the customer. They should control it, back it up, and be able to query it independently of the platform if they choose.

The Memory service indexes vCons by participant identity as they accumulate. When a new conversation begins, Memory queries that history and surfaces what’s relevant: prior contacts from this caller, signals detected in previous calls, outcomes reached and issues left unresolved, patterns that only become visible across multiple interactions. That context is available to Agents and Operators before the conversation’s first word is spoken.

The effect is that the platform’s intelligence compounds over time. An Agent handling a returning customer can be aware of their history without the customer needing to repeat themselves. An Operator assessing fraud risk can factor in prior signals from the same number. A webhook payload can note that this is the third unresolved complaint from this caller in six weeks.

In emergency services, this context can be genuinely significant. A caller with a documented history of mental health crises should trigger a different initial response than an unknown first-time caller describing the same symptoms. That distinction requires memory.

Because vCon is an open standard and the records live in the customer’s own storage, the memory the platform builds is fully portable. If a customer migrates off the platform, their conversation history goes with them. They can query it with their own tooling, export it to other systems, or feed it into their own analysis pipelines. The historical record of a conversation estate belongs to the customer – not as a policy position, but as an architectural fact.

This is worth thinking about in comparison to how most analytics platforms work. The standard model is: your data lives in our infrastructure, queryable through our APIs, exportable only in the formats we support, and gone if you leave. Conversation Memory works the other way: your data lives in your infrastructure, the platform indexes it on your behalf, and you could walk away with every vCon intact.

Today, Conversation Memory is scoped to voice. But the record format, the identity model, and the storage structure are deliberately chosen to match what we’ve already defined for async text channels: WhatsApp, SMS, email, and support tickets. A voice call and a WhatsApp thread produce the same kind of record. The turn format is medium-agnostic. The conversation identity doesn’t reference a session; it references the transport-native key, whether that’s a call ID or a message thread. When the async front-end arrives, those conversations land in the same record shape without requiring anything to be redesigned. That’s not an accident.

Part 8 switches from the product to the platform itself – specifically the new API architecture that underlies all of this and makes independent service evolution possible.

Previous: Part 6 – Operators

Next: Part 8 – A new API architecture

Back to series index