Part 1 of 12 – Conversation Intelligence Platform series
We’ve shipped a lot of things over the years. We were virtualising infrastructure before most of our competitors had heard the word, and containerising before most of them had virtualised. We built a genuinely API-first carrier – our first API dates to 1996, back when they were called “web services” and were largely a theoretical future vision Microsoft was writing whitepapers about. Some of our competitors still don’t have usable APIs. Each of those decisions felt significant at the time.
This is bigger.
Today we’re launching Simwood Conversation Intelligence: a carrier-grade AI platform that makes any voice passing through our network intelligible in real time. Intelligible, structured, and actionable. I’ll explain exactly what that means in the articles that follow. We’re launching in beta via the carrier services beta programme – if you’re not already enrolled and want early access, get in touch. But first there’s something I want to say and it matters more to me than the product description.
I’ve had bugger all to do with it.
That’s not entirely true. The original vision was mine, articulated to Charles Chance, our CTO, in a handful of sentences. He ran with it. The difference between “Simon had an idea” and “Simwood has a platform” is Charles and his team, and I want to be unambiguous about that
If you use Ro.am for team communications, you’ll know the small red throb that appears over someone’s name when they have Claude Code running. There has been an enormous amount of throbbing over Charles’ name these past months. The whole platform – the architecture, the services, the auth model, the API design, the documentation – emerged from him and his team pushing that capability as far as it would go.
What’s remarkable (and this is what Part 2 of this series covers properly) is not just that AI wrote code. The entire platform was designed and documented before a line of product code was written. Architecture briefs. Decisions recorded as Architecture Decision Records. Every service modelled, every interface defined, every migration mapped. The AI didn’t just write to a spec – it helped reason about the spec itself. And then it drafted these blog posts from those same documents and from what we’ve learned about our own voice and tone over the years. I was, I’ll admit, slightly alarmed to be told the tone was going to be “Full Simon.” Even the robots abuse me.
I can barely contain my excitement about this. There was a time – more than a decade ago now, though it doesn’t always feel it – when I’d ship things at weekends, blog on Monday, and fix them on Tuesday. Those days are long behind us, but this is the single biggest leap forward we’ve ever made and the single biggest thing we’ve ever shipped. I’ve been building things at Simwood for a very long time. I know how this normally goes: you build fast, you document later, and “later” becomes never. Charles, when he joined with the acquisition of Sipcentric in late 2019, insisted on doing things properly – properly documented, properly reasoned, properly tested. It slowed us down and, if I’m honest, I didn’t always like being slow. But he was right. What we have now is the best of both worlds: we’re going faster than we ever have, further than we ever have, and it’s better documented than anything we’ve shipped before. Something I could not have built at all under any previous model with the team size we have.
That deserves to be said plainly, loudly, and with genuine gratitude. Well done, Charles. Well done, team.
The platform rests on an insight that I think is more significant than it first appears. We’re a carrier. Every call on our network passes through infrastructure we operate at a level no third-party analytics vendor can match. And it’s not just phone calls – via the Simwood Potato, any voice passing through our platform is in scope: Teams calls, WhatsApp Calling, any channel we carry. That matters because the world has already moved well beyond the PSTN, and building an intelligence layer that only understands telephone calls would be building for the past.
The carrier position means we can do things that others structurally cannot. The media tap is passive, at the carrier layer, with zero impact on the call being observed. The analysis happens in real time, not on recordings after the fact. And because we’re the carrier, the Agents conducting conversations and the Operators observing them work on the same infrastructure, neither knowing what the other is doing, both working from the same signal.
The transcript is the transcript. The conversation is the conversation. It doesn’t matter whether it’s a human handler or an AI Agent on the line – the analytical layer is identical either way. That’s not an obvious design choice; it’s a principled one, and it opens up use cases that nobody else can offer.
There’s also something here for customers whose traffic is locked with carriers who’ve invested in nothing for decades. Via BYoC, Conversation Intelligence is available to anyone who can route their media through Simwood – you don’t need to port numbers or change your primary carrier to benefit from carrier-grade intelligence in the call path.
There’s also a platform story that’s easy to miss when looking at the AI features. We’ve rebuilt our API architecture at the same time: independent, versioned service APIs, proper authentication, documentation treated as a product rather than an afterthought, a 200-endpoint API being migrated without breaking customers. None of that is glamorous. All of it matters.
This series runs to twelve parts. The order is deliberate:
- Part 2: The AI-accelerated build – how this platform was actually designed, documented, and shipped
- Part 3: Simwood has always shipped early – the lineage that leads here
- Part 4: Introducing Conversation Intelligence – the carrier advantage nobody else has
- Part 5: The media tap – how real-time carrier-layer intelligence actually works
- Part 6: Operators – turning a call into signals your systems can act on
- Part 7: Conversation Memory and vCon – the intelligence that compounds over time
- Part 8: A new API architecture – independent services, one gateway, zero coupling
- Part 9: Authentication done right – API keys, OIDC, and the end of Basic Auth
- Part 10: Deprecation as a feature – how you migrate 200 endpoints without breaking customers
- Part 11: Documentation as a product – narrative guides, live OpenAPI, and Scalar
- Part 12: Internal documentation that actually gets used – ADRs, MCP servers, and AI-accessible knowledge
Start wherever makes sense for what you’re trying to do. If you’re building on our platform, Parts 4-7. If you’re an engineer trying to understand the architecture, Parts 8-10. If you want to understand what this means for the industry, Parts 2 and 3.
We’ll be adding video to some of these – Parts 4, 5 and 6 especially, because watching a fraud signal fire a webhook mid-call while a whisper delivers an alert into the handler’s ear is more visceral than any amount of prose.
The carrier AI platform that nobody has built yet? We just built it.
