Almost every company in customer support now describes its people in the same terms: agents are "AI-assisted", the model is "human-in-the-loop", and humans are "empowered" by the technology. I have used all of these phrases myself, and I understand why they are popular.

They are comfortable precisely because they are vague. They suggest that the AI does the heavy lifting while the human checks its work, without ever saying how much of the work each side actually does, or what happens to the people involved as that balance shifts.

In this piece I want to set that vocabulary aside, because what AI is actually replacing is the scripted, repetitive part of support work, the part few people ever wanted to do. At Onepilot, our AI platform and a network of more than 2,000 freelancers each handle part of our clients' customer support, and I don't think the freelancers are assisting anything. They are independent professionals doing a different job from the machine, and that job will keep changing as automation grows, which is worth saying openly.

What the AI actually does today

Among the brands that use our AI-native product alongside our freelance network, the AI now takes part in about half of customer conversations. On the five best-performing of these accounts, it resolves close to 70% of conversations entirely on its own, with no human involved.

The curve is fairly predictable. Every new brand starts with immature workflows and a lot of human handling, and as playbooks stabilise and integrations deepen, the automated share climbs account after account. The accounts that have been live the longest give a good idea of where the others are heading.

Customers seem to notice the difference: conversations resolved fully by the AI receive a 96% CSAT. That number needs context: the AI is given the requests where its playbook is mature, not every request that comes in. The fair claim is not that it beats people in general, but that on the work it is given, it holds up, and is anyway often better than a disengaged agent reading a script, because it is fast, consistent and just as patient at 3am as at noon.

Over time, I expect simple, repetitive requests to be handled almost entirely by AI. That shift is already under way, and it is changing what the human side of the work looks like.

It is not happening at the same pace everywhere, though. Mid-market brands tend to move quickly, while larger enterprises are still held back by security, governance and procurement concerns around AI, a gap I wrote about in Why AI-native CX is widening the gap between mid-market and enterprise.

Who the 2,000+ are

The freelancers who work with Onepilot are far from a temporary workforce. Among those active in the last quarter, almost half have been working with us for more than a year and nearly a quarter for more than two, which matters in an industry where call centre attrition tends to be measured in months.

Most of them are based in France, with others across the UK, Germany and the rest of Europe, as well as in the United States and beyond. They are registered as independent businesses, invoice us monthly and choose their own shifts in two-hour blocks opened two weeks ahead. They are paid per resolved ticket, with a quality bonus on top, rather than per hour of presence.

Getting in is selective: more than 140,000 people have applied over the years, and each goes through role plays, attention-to-detail tests and a recorded video before anyone speaks to them. Once they join, they are trained on each brand they work with using our Academy product. Training is automated and self-service, so the knowledge they need for each client stays accessible whenever they need it, and they can work across several clients. Over the last 90 days, they resolved around three million tickets for more than 200 brands and escalated roughly one in a thousand.

A different job, not an assisted one

I think the most accurate way to describe the split is not "AI plus humans" but two different jobs, even when they share the same queues. Today, freelancers still handle a large share of everyday requests alongside the AI. What changes is the direction: account by account, the AI takes on more of the informational and transactional requests support teams usually call levels 1 and 2, and the work left to people shifts with it.

As that happens, more of their time goes to the complaint that is really about something else, the customer who has already been let down twice, or the case that sits between two policies and needs someone to make a decision. It includes VIP requests, legal risks and the edge cases no playbook anticipated. The way freelancers resolve these cases also ends up improving the playbooks the AI runs on, though that is a by-product of their work rather than its purpose.

It is becoming a level 3 job, one that needs judgment, context and the confidence to make a call, and it should be evaluated on outcomes rather than handling time. Calling that person "assisted" doesn't really describe what they do. They are independent professionals taking care of the part of the work that machines are not built for, and the part we most need to get right.

Put simply, the split is moving towards what each side does best: the AI taking on more of the routine work, where speed and consistency matter most, and people spending more of their time where judgment matters more than any script. Their work becomes more skilled, not less important.

What this means for the people doing the work

As automation keeps climbing, we will need fewer humans per ticket than we do today. That follows directly from the numbers, and I don't think anyone running a support operation can honestly claim otherwise while automating at the same time.

What changes is how many people the work needs, not whether people matter. If fewer people are doing harder work, they should be well trained and free to choose when and how much they work. The freelance model makes the transition more transparent than a call centre can: nobody is sold a lifetime job, the terms are explicit from the start, and the work is chosen shift by shift.

The transition will not be easy for everyone in the industry, given how many support jobs around the world exist mostly to answer level 1 and 2 questions. Suggesting that AI will simply "augment" all of them may sound kinder, but in practice it only postpones a conversation the industry needs to have.

Say what each side does

The industry doesn't need another slogan about humans and AI working together. What it needs are operators willing to describe what each side actually does, and to design their organisations around where that split is going.

For us, that means measuring and publishing how much the AI really resolves, treating the human role as a job in its own right with its own skills, pay logic and progression rather than as a fallback, and being clear with the people who work with us about where the work is heading before it gets there.

The call centre job built on repetition is coming to an end. What replaces it is still being shaped, and I believe the operators best placed to shape it are the ones willing to describe it as it really is.

I run a company. I do not live like this.

Some of the others do. Their jobs are different from each other, but they share something I do not: their days are full of people, and they draw something from that. They meet dozens in a normal week, move easily in an ecosystem full of people like them, come back from a conference with a stack of cards and know which three matter. This is not a complaint about them. It is most of what a company needs, and they are good at it in a way I am not going to pretend to match. But it means the life people picture when they hear the word "founder," the one that runs on contact, is a real life, and it belongs to them, not to me.

I am the one who stays in. I am the technical founder, which in practice means my days are spent with systems where theirs are spent with people. That is solitary by design. You cannot debug a system in a crowd. The parts of the job I am best at, the long uninterrupted screen-facing parts, are the parts that happen with the door shut.

A company all-hands in a pub, early 2023. I was demoing something on a laptop. The picture is really about the faces around it, which is about right.

For years I read this as something wrong with me. Everyone around me seemed plugged into a network I had somehow failed to join, and the obvious explanation was that I had failed to build one. But that gets the causality backwards. I am not a badly connected version of the people who thrive on it. The seat I sit in does not put people in front of me the way some of theirs do. Their days are full of contact. Mine is full of systems, and it is no less necessary for that.

"Being needed by people is not the same as being among them"

The world does not make this easy to see, because the world has never been louder about how connected everyone supposedly is. Every feed is a wall of people on stages, at dinners, tagging each other, in the room. Founder culture treats visible connection as proof of health: if you are not constantly meeting people, you are doing it wrong. So the internal founder, the quiet one, looks at all of it and concludes he is the anomaly. He is not. He is just the part of the machine that does not photograph well.

There is another version of this that has nothing to do with being the technical one. Founding a company looks, from the outside, like the most social thing a person can do. It is nothing but people. And the demands are social: you are always talking to someone, always in a meeting, always needed. But being needed by people is not the same as being among them, and the two get confused constantly, most of all by the people watching from outside, who take a full calendar for a full life.

It takes years, not months, and across those years the work is the priority in a way you eventually stop apologising for and the people around you never quite accept. Friends drift, or stay and do not understand. A partner absorbs the cost of it more than anyone. You try to explain what the work means and it does not land, because it cannot land unless someone has done the same thing. So you are a little alone in it even with the people closest to you.

And the people who do understand, the ones inside it with you, are the ones who work for your company. They can be lovely. Some of them become real friends. But there is a line under each of those relationships that never fully dissolves, and you are the one who drew it. That is the strange shape of it: you are surrounded, and you are also alone, and both are true at once and for the same reason.

Here is what I have actually come to think. The isolation is real, and naming it as a property of the role rather than a defect in me did not make it disappear. It made it manageable, which is a different and smaller thing. I am not alone because I am bad at people. I am relatively alone because the work I do is done alone, and because I am someone who needs far less constant contact than the people I built this with. Those are two separate facts, and I spent a long time blaming myself for both at once.

What has helped is small and unglamorous. A few rooms where I am a person and not a function, where nobody needs a decision from me, matter more than the number of rooms. One good conversation with someone who has neither a stake in my company nor a gap in understanding it is worth more than a week of the circuit. And accepting that I will never run the kind of calendar some of them run, that this is not a problem waiting to be fixed, took more effort than any of the rest.

I still catch myself treating a quiet evening in as a failure to make the most of something, and I still have to remind myself that the version of a founder's life I keep measuring against was never mine in the first place. It belongs to people who are better at it than I am, and I am glad they exist, because it means I get to do the other thing. The thing with the door closed. The thing that works.

That said, I won't say no to the occasional champagne dinner.

I know this because we crossed that gap the hard way, from an unusual starting point. Customer support is an old and brutally competitive industry, and we have run it with human agents for years across these brands. But we have been tech-first since day one, in a business that mostly is not, and that is the reason we got anywhere in it. Most companies here are one or the other: legacy operators with little engineering, or AI startups that have never run a real queue. We were both from the start, which is why the AI platform was never a pivot. It is the most natural thing we have built.

Over the last ten months we took that operation from a few hundred AI-handled conversations a month to hundreds of thousands, across a few dozen brands running real commerce stacks: orders, subscriptions, carriers, returns. More than half of the conversations our AI engages now close without a human ever touching them, and the rest still go to people who do this for a living. None of that came from a smarter prompt. It came from a long list of things that broke.

Here are eight of them, and the lesson each one beat into us. They look like unrelated war stories. By the end you will see they are the same story.

1. The one-line outage

One afternoon every single conversation, across every brand, stopped. The AI crashed on each inbound message and handed the ticket to a human. From the outside it looked like a total system failure. The cause was one line.

I had added an import to our central orchestrator, the function every message on every platform flows through. The name I imported happened to collide with a variable assigned later in the same function. Python quietly decided the name was local for the entire function, so a reference earlier in the code blew up before it was ever assigned. Classic, boring, and total.

The part that stung: I had "checked" the change. The file parsed. The code was valid. But valid is not correct, and a parse check cannot see a bug that only exists when the line runs. In an AI system the orchestrator is your single point of failure, and its blast radius is every customer at once. We now gate every deploy on a dataflow check that catches exactly this class, plus an actually-executed path, never just "it imports."

The lesson is unglamorous and it is the foundation of everything else: the reliability of your AI is mostly the reliability of the very normal software wrapped around it.

2. The agent that quietly forgot its instructions

We made what looked like a harmless plumbing change. Instead of placing each workflow's instructions at the very front of the model's context, we moved them to sit after the reconstructed conversation history. Same words, same instructions, slightly different position.

The agent started ignoring its own workflow. Steps it was told to follow got skipped. Required fields in its output silently went missing. And it only happened after the first turn, because on turn one there was no history in front of the instructions yet, so it worked perfectly in every quick test and degraded only once a real conversation got going.

That is the maddening texture of building on language models. A change you would call cosmetic in any normal codebase, the order of two blocks of text, measurably changed behaviour. There was no error, no exception, no log line. The model simply paid less attention to instructions that were buried, the same way a person skims the middle of a long email.

The lesson: with language models, where you put an instruction matters as much as what the instruction says. Non-determinism does not announce itself. It hides in the plumbing you assumed was safe.

3. The over-helpful agent, and the tempting wrong fix

A customer wrote in with two things in one message: my order never arrived, and also, cancel my subscription. This is not an edge case. Across our entire platform those are two of the highest-volume reasons customers contact a brand. They collide constantly.

Our router picked one intent, order tracking, and ran that workflow well. Then the agent reached the second request, found it had no tool to cancel a subscription in the workflow it was running, and escalated the whole ticket to a human. Including the delivery half it had already solved.

The obvious fix is right there and it is a trap: just give the agent all the tools, all the time. Then it could have cancelled the subscription itself.

We did not do that, and refusing to is one of the most important decisions in the product. A subscription cancellation does not live alone. It lives inside a workflow that carries policy: the retention offer, the confirmation step, the rules about what the customer is owed. If you let the model reach the cancel capability from outside that workflow, you have an AI cancelling subscriptions without any of the guardrails that are supposed to govern cancellations. We call that freelancing, and it is precisely how you lose control of a support agent.

The real problem was never a missing tool. It was routing. One message, two intents, and a router that only knew how to pick one. The fix is to run both of the right workflows, each carrying its own policy, not to tear down the walls between them. Over-escalation looked like a capability gap. It was a routing gap. Those are very different bugs, and confusing them is how good teams accidentally build an agent they cannot trust.

4. The failure that poisoned the conversation

Here is one that genuinely surprised me. A tool the agent called, a carrier lookup, threw an error. Transient, the kind of thing that happens a thousand times a day to any system talking to third-party APIs. You would expect the agent to recover, apologise, retry, move on.

Instead the conversation died. Not that message. The conversation. Every subsequent message from that customer hard-errored, permanently.

The reason is specific to stateful AI agents and worth understanding. The framework had already saved a snapshot of the turn the instant the model decided to call the tool, an assistant message that says "I am about to call this tool." Then the tool blew up before any result could be recorded. Now the saved state contains a promise with no answer: a message announcing a tool call that has no matching result. To the model's API that is a malformed conversation, and every future message inherits the broken snapshot and is rejected on arrival. One transient hiccup became a dead conversation that could never heal itself.

The lesson: failures in stateful AI systems are sticky. Corrupted state outlives the error that caused it. In ordinary software a failed call is a bad second; here it can poison everything that comes after. You cannot treat tool failure as an exception you log and forget. It is a first-class path, and you have to engineer the recovery as carefully as you engineer the happy case.

5. What counts as automated

Once the AI was resolving real volume, a question that sounds like a reporting detail turned out to be the hardest one in the product: which conversations count as automated? It matters because the answer is what we put on the invoice, and that is where trust with the customer is won or lost.

The tempting definition is generous to us. The AI replied, the customer went away happy, call it automated. But real conversations are messier. On plenty of tickets the AI did almost all the work and a human then sent a single closing line. On others the AI replied and a human replied too. Is that automated? Half-automated? If we get to decide, every ambiguous case quietly rounds in our favour, and the headline number drifts away from anything the customer would recognise as true.

So we built the accounting to be conservative on purpose. Every conversation is sorted into one of a few segments by who actually replied: the AI alone, the AI plus a human, a human alone, the AI deliberately closing a ticket without replying, or nobody. Only the first one, where the AI handled the whole thing and no human touched it, counts as fully automated, and in the strict billing mode that is the only segment we charge for. A human sending one line is enough to make the ticket free. The human here is not a failure to bill around; on the cases the AI should not close alone, a person finishing the job is the design, not the exception. We would rather undercount and be unarguably fair than inflate the number and let the customer find the seam later.

The lesson: the definition of "automated" is a product decision, not a metric, and drawing the line in the customer's favour is what makes the number worth trusting. It also points our own incentives the right way, because we only get paid when we genuinely removed the human, which is exactly the thing the customer is buying. Honest accounting is a feature, and like everything else here it is a constraint we chose to put on ourselves.

6. The boring economics of depth

When you need shipment tracking, there is an easy path and a hard path. The easy path is a single aggregator that claims to track every carrier through one API. You integrate once and you are done. The hard path is integrating each major carrier directly, one painful API at a time.

We started down the easy path and backed out. The aggregator bills per lookup, it is rate-shared with everyone else using it, and the data it returns is shallow. At the volume of "where is my order," the single most common question in all of e-commerce support, that per-lookup tax adds up and the shallow data means more handovers. So we built native carrier integrations first and kept the aggregator only as a fallback for carriers where no direct API exists. Richer data, not rate-shared, and cheaper.

This is the least exciting work we do and it is most of the moat. Anyone can connect a model to a chat. Very few teams will do the unglamorous work of integrating thirty carrier and commerce APIs deeply enough that the AI can actually resolve the request instead of describing it. The intelligence is a commodity. The depth of real operations behind it is not.

7. Every external string is hostile

Most people picture prompt injection as something a malicious customer types into the chat box. In production the larger surface is everything the agent reads that is not the customer. The agent ingests carrier API responses, order notes, ticket fields, product metadata: text from a dozen third parties, any of which can carry an instruction the model might decide to obey. Your attack surface is not your input box. It is every byte the model reads, and most of those bytes come from systems you do not control.

The customer channel is not just words either. We saw inbound messages padded with thousands of invisible characters, spam crafted to bloat the context and derail the agent. So we strip that padding before it ever reaches the model and treat every external string, not just the obvious user input, as untrusted by default.

The lesson: sanitise at the boundary, and assume the adversary is not only the person typing. In an ordinary backend you validate the form fields. In an LLM system you have to account for the fact that the model will read, and may act on, text that arrived through an API you have never thought of as user input.

8. You cannot wall off a language model

Our first instinct on security was the one every engineer has: lock it down like a normal backend. Validate every input, deny by default, allow only what is explicitly permitted. It is the correct instinct for a CRUD application and it is the wrong instinct here, because the thing that makes the agent valuable is exactly the flexibility that deny-by-default destroys.

What we landed on is two tiers, and the distinction has become one of our core design principles. Tier one is the hard boundaries, the places where the model has no role at all: authentication, secrets, making sure one brand can never see another brand's data. Those are code-enforced, non-negotiable, and the model's opinion is never consulted. Tier two is everything the model mediates: how it interprets a request, which guardrails apply to a sensitive action, how it handles messy third-party content. Those you do not freeze in code on day one. You instrument them, you watch what the model actually does at scale, and you tighten with evidence rather than with fear.

The lesson: an AI-first product needs a security posture that is part code and part instrumentation. Hardening it like a traditional backend either breaks the product or, worse, gives you a false sense of safety while the real risks sit somewhere your validation rules were never looking.

The obvious objection

I can hear the counterargument, because I have made it myself. This all sounds old-fashioned. Routers, workflows, hard boundaries, a model kept on a short leash: it looks like the scripted chatbots of 2018 wearing a newer coat. The industry is sprinting the other way, towards agents you hand a goal and trust to improvise, and every month the models get good enough to make that pitch more believable. So aren't we just building scaffolding that the next model generation tears down? Won't a clever enough agent simply not need the rails?

It is a fair challenge, and part of it is true. Some of our constraints exist purely because today's models are not reliable enough, and those will recede. As the models improve we fully expect to widen the second tier: give the agent more latitude inside each workflow, collapse routing steps it no longer needs, hand it judgement we currently make for it. The frontier moves, and we intend to move the line with it. We would rather be the team that loosens a constraint when the evidence says it is safe than the team that shipped autonomy and learned the hard way in front of a customer.

But the pitch conflates two things that are not the same, and that is where I think it is wrong. Capability is not authority. A more capable model can work out how to cancel a subscription; it still should not get to decide whether it is allowed to, on what terms, with which retention offer, under whose policy. That is not a gap in the model's intelligence. It is the business saying what it will and will not stand behind. A perfect model still has to be told the refund policy, still has to be auditable, still must never let one brand see another's data. Those constraints are not distrust of the model. They are the shape of the product the customer is actually buying. No amount of model progress removes them, because they were never model problems.

So yes, it is unmagical on purpose. The magical demo and the system you trust with a refund are different artefacts, and the distance between them is exactly the boring, deliberate, old-fashioned engineering this whole piece is about. The autonomy that matters here is not the agent's. It is the customer's: the freedom to hand over a queue and stop worrying about it. You earn that with constraint, not in spite of it.

The one thread

Read those eight again. A one-line crash, a misplaced block of instructions, an over-eager router, a poisoned conversation, an honest automation count, a per-lookup tax, a hostile API payload, a security model. They sound unrelated. They are the same lesson wearing eight outfits.

The hard part of production customer support AI is not capability. It is constraint.

Every win we have had came from narrowing what the model can do at any given moment, isolating each capability behind the workflow that owns its policy, and engineering for failure as a normal path rather than a surprise. The industry is busy selling the opposite: agents you point at a problem and trust to improvise. Our data, across seven figures of real conversations, says improvisation is the enemy. The agents we trust are the ones we have most carefully fenced in.

The economics make the point on their own. Millions of AI-generated messages cost us a five-figure model bill: pennies per message, and what we pay the model is a small fraction of what a resolved ticket is worth, a gap that only widens as inference gets cheaper every quarter. The margin was never in the model. It lives in the system around it, the workflows, the routing, the recovery paths, the tiered security, the part that took ten months of things breaking to build and the part that is actually the company. We run thousands of workflows in production, dozens per brand, the most sophisticated past two hundred.

This is what I mean when I say customer care is an infrastructure problem, not a model problem. The engine is brilliant and slightly unreliable, and everyone has the same one. The car you build around it, software and people both, is what customers actually feel, and it is the only thing that is hard to copy. The deepest part of it is the part no prompt can produce: the credibility of a team that was already doing this job, by hand, well. A brand does not hand its refund button to a demo; it hands it to an operation it already trusts, and lets the AI take the volume that operation has earned the right to automate.

Control is not the thing slowing the AI down. Control is the product. It is the entire reason a support leader can hand an agent the refund button and sleep at night.

What I want to write about instead is something I've been noticing on the buyer side, because I haven't seen much honest discussion of it. I also have a particular stake in this. I started Onepilot as its technical co-founder and spent the first couple of years writing the platform, which means I've been on the inside of most of the architectural choices that show up in a security review today. The questions buyers ask aren't abstract to me; they map to lines of code I remember writing and decisions I remember the team making. That's part of why this piece exists.

In the last twelve months, I've watched close to ten enterprise sales processes where the binding constraint on time-to-value wasn't capability, integration, or even budget. It was security and procurement review. Timelines in months, not weeks. Across UK, European, and North American buyers, and across sectors. During the same period, our mid-market customers have been going live in around two weeks, sometimes faster on a native stack.

I don't think this is a complaint about procurement. I think it's a structural mismatch that hasn't been named, and naming it might be useful.

What I'm actually seeing

Mid-market brands tend to absorb AI-native support fast. The buying committee is small, the integration footprint is modest, the security review is rigorous but proportionate to the size of the deployment. Two weeks from contract to value is now routine for us. The economics start working in month one.

Enterprise brands tend to take much longer. The same vendor, with the same architecture, can sit in a security and procurement queue for six to nine months before the first ticket is ever handled. The buying committee includes infosec, legal, data protection, sometimes a model risk function, sometimes an AI governance board that didn't exist a year ago. Every layer is doing its job. Each layer was designed for a different era of vendor.

The result is that two organisations buying the same product, at the same time, in the same market, experience very different timelines to value. I find that worth examining.

Why I think this is structural

The standard procurement and security review process was built for SaaS. Static product, assessed once at signing, with risk that stays roughly stable for the contract duration. The templates ask sensible questions: SOC 2, ISO 27001, data residency, sub-processors, encryption at rest, incident response. Vendors who have those answers ready clear the bar. That model worked well for a decade.

AI-native systems don't sit still in the same way. The system in week 12 is not the system in week 1. The playbooks evolve as the operator learns the business. The set of tools the model can invoke expands as integrations mature. The autonomy thresholds shift, conversation by conversation, as confidence grows. A buyer evaluating an AI-native vendor is being asked to assess a snapshot of something that behaves more like a flow.

The questions worth asking are also different, and I don't have a complete list. Some I'd put on it: which data ends up in prompts, and is any of it retained downstream? Is customer data used to train or fine-tune any model, even indirectly through provider defaults? Where does inference run, and what crosses a border to get there? Are credentials ever passed into the LLM context, or are they injected server-side at execution time? Is the model bound to a fixed catalog of tools per workflow, or is it freelancing against a global registry? How are sensitive actions like refunds or account changes gated, and where does that policy live (in the model, or in code)? Most security review templates I've seen don't have a natural place to put answers to questions like these. So vendors attach them as appendices, reviewers treat them as out-of-scope, and the conversation tends to default to the SaaS questions that don't quite fit the situation.

Our DPO and our engineering team have spent more hours than any of us would have predicted working through how to present this kind of material to security reviewers in a way that lands. Some of what's in this piece comes from those conversations.

A pattern from the ten deals

The shape tends to repeat. A CX leader at a large enterprise meets us, sees the product, runs a pilot in a sandboxed environment, gets convinced. They bring it to procurement. Procurement asks for the security questionnaire. We answer it, often with more material than the questionnaire asks for, because the questions don't quite cover what matters. Security review opens. New questions surface, not because something is wrong, but because the reviewer is encountering an architecture they haven't seen before and reasonably wants to understand it from scratch.

What's interesting is how the questionnaire evolves across rounds. The first pass tends to be SaaS-shaped, and you can feel the legal and security side ticking boxes more than probing anything specific. By round two, the reviewer has read the appendices and starts asking different questions, often sharper ones, about how tool authority is scoped or how the audit trail actually works. By round three, the conversation has shifted to specifics like which fields are surfaced to the model from an integration like Shopify or Zendesk, and how new fields are added (in our case, a code change with code review, not a configuration flip). That arc, from generic to specific, is the reviewer doing the work of building a mental model for a new class of vendor. It's healthy. It also takes time.

The number of people in the loop tends to grow with each round. Legal joins. Data protection joins. An AI governance review is initiated, sometimes by a function that was created in the last six months and is still defining its own remit. Our DPO has observed the same shift across questionnaires this year: not just sharper questions, but more interlocutors on every cycle.

I want to be clear that none of this is bad faith. Every reviewer I've dealt with has been doing the work properly. The cumulative effect is just that the total elapsed time runs to six to nine months. In the same period, three mid-market customers might go live and reach 50% automation.

The CX leader who started the process is often the most frustrated person in the room, partly because they can see the gap and have no individual lever to close it.

What some buyers are doing differently

A small number of the enterprise buyers I've worked with handle this better than the rest, and the things they share might be worth naming, even if I'm not certain they generalise.

They've built an AI-specific review path, parallel to the standard SaaS one, that asks questions calibrated for this kind of vendor. The questions are concrete: show us the audit log for a single conversation end to end. Show us how a sensitive action like a refund is gated. Show us what happens when a tool call returns a 5xx error. Show us how identity verification works when the email on the ticket doesn't match the email on the account. These are not gotchas; they're the right questions, and vendors with real answers can produce them in hours. Vendors with bolted-on AI wrappers tend to get filtered out earlier, which seems healthy.

They've also adjusted for the fact that what they're buying behaves more like a flow than a snapshot. Their contracts include change-notification clauses for material model or playbook updates. Their governance reviews are scheduled more frequently than annually. They've stopped trying to evaluate only the version they signed.

I don't have enough data points to say this is the right answer. These are just the patterns I've seen in buyers who seemed less stuck.

What I'm not sure about

I don't know how this resolves. There's a version of the next two years where industry standards catch up, procurement templates get rewritten, and the gap closes on its own. There's also a version where it widens, because mid-market companies keep absorbing operational savings that enterprise can't match on the same timeline. I genuinely don't know which is more likely, and I'd be cautious of anyone who claims to.

What I'd offer instead is a smaller observation. The cost of long enterprise review cycles for AI vendors doesn't show up cleanly on procurement's spreadsheet, because there's no line item for "agents doing data-movement work while we wait for security to finish." But the cost is real, and it's worth being honest about it on both sides of the table. Vendors who can't articulate their governance story shouldn't expect to move faster. Buyers whose templates were written for a different generation of vendor probably shouldn't expect those templates to keep working unchanged.

I'm interested in hearing from people on the buyer side who've thought about this. Not because I have the answer, but because I suspect the people closest to it haven't been writing about it publicly, and I'd rather learn from them than guess.

Every Business Process Outsourcer (BPO) has a dirty secret, and it is one that nobody wants to voice out loud during a Quarterly Business Review: their business model depends on the exact thing their customers are trying to eliminate.

Repetition.

A BPO sells hours. Hours are billable when an agent is typing. Agents type when customers have questions. And customers have the same questions over and over again: "Where is my order?", "How do I return this?", "Why was I charged twice?". The industry has spent twenty years optimising a machine whose fuel source is the repetition its clients are actively trying to burn down.

You can bolt Artificial Intelligence onto that machine. Most of the industry is doing exactly that: a copilot here, a suggested reply there, a shiny AI-powered slide in the sales deck. It does not change the physics of the situation. The agent still types. The clock still ticks. The incentives stay broken.

At Onepilot we believe the answer is fundamentally different. We are not bolting AI onto a BPO. We are rebuilding the entire structure around a different idea: one where AI is not a feature, but the default execution layer.

This post is about the principles behind that choice.

The Repetition Economy

Look at any support queue in e-commerce, fintech, or marketplaces, and you will see roughly the same shape. The distribution of workload follows a predictable pyramid that defines how resources are currently mismanaged across the globe.

Customer Support Volume Distribution

The top 70% is the part that should never have been a job in the first place. A human reading the order status from one screen and typing it into another is not customer service, it is data movement with a friendly tone. It is a waste of human potential and a source of massive operational inefficiency.

The middle 25% is where most AI for support tools quietly fail. They can draft a reply; they cannot execute. They will tell you to issue a refund, but they will not actually issue it. They cannot read the order, check the warehouse, cross-reference the return policy, decide whether to approve, process it in the ticketing system, and notify the customer, all in one coherent action.

The bottom 5% is the genuinely hard, emotional, and novel cases where humans earn their salary. That is also where a BPO’s best agents are wasted today, because they are spending 80% of their shift drowning in the top 70%.

The whole game is moving work down the pyramid. AI eats the top. Humans keep getting better at the bottom. The Onepilot approach turns the operator into a traffic controller, deciding in real time, conversation by conversation, which work goes where. Everything else in this post is downstream of that idea.

A representative trace of a duplicate-charge ticket at Onepilot. The example is constructed for this post: the pipeline, sequence, and event types are accurate to what runs in production.

AI-Layered vs. AI-Native

The standard playbook right now is what we call AI-layered:

1. Take an existing ticket system.

2. Bolt on a Large Language Model (LLM) wrapper.

3. Add a suggested reply button.

4. Call it AI-powered.

This fails for a specific reason: the surrounding system was built to be driven by humans. The workflows, the state machines, the audit trails, the permission models: they were all designed around the concept of "agent clicks button". Drop an LLM into that environment and it can observe, but it can barely act. And when it does act, nobody trusts it, because there is no coherent layer tracking what it did, why it did it, and what happened next.

AI-native is a different thing entirely. The difference is not which model you use. It is not how clever the prompt is. It is a handful of design principles that, taken together, produce a completely different product.

Here are the five that matter most.

Principle 1: The LLM is the Engine, Not the Decision-Maker

This is the single most important idea, and it is the one most products get wrong.

Text-first is the default mode for LLM products. You give the model a big prompt, some tools, and hope for the best. The model decides when to call what, what to say, when to stop, and what to promise. This is great for demos and absolutely terrible in production, because when the same customer question leads to different actions on Tuesday and Wednesday, you do not have a product. You have a lottery.

An AI-native system inverts the relationship. The operational logic, "if the order shipped more than 14 days ago, offer a refund; otherwise, offer a reroute", lives in structured, versioned playbooks defined by humans who understand the business. The LLM’s job is not to decide what should happen. Its job is to interpret messy user input, navigate the playbook, pick the right tool, and write the reply in the brand’s specific voice.

That shift from LLM as brain to LLM as engine is what makes every other property of the system possible. Determinism, auditability, safety, cost predictability, version control, and testability. None of those are achievable when the model is freelancing.

Principle 2: Actions Over Answers

An AI that drafts a refund reply is a demo. An AI that issues the refund is a product.

Most of the industry is still living on the draft-reply side of that line. Suggested responses, macro helpers, and AI-assisted inboxes are genuinely useful, but they are also a local maximum: they cannot take you past the ceiling where a human is still in the loop for every single ticket.

The path past that ceiling runs through actions. This means:

• Reading the order data directly from the database.

• Cancelling the subscription in the billing platform.

• Issuing the refund via the payment gateway.

• Updating the customer record in the CRM.

• Scheduling the reshipment in the warehouse management system.

• Notifying the carrier and logging the resolution.

Every one of those is an API call into a tool you already own: Shopify, Zendesk, Recharge, Klaviyo, HubSpot, the ERP, or the OMS. An AI-native CX platform is, in a very real sense, a coordination layer across all of them. The intelligence is not in the replies, it is in the orchestration.

Which also means the platform has to stay open. The strongest feedback we hear from enterprise customers is: "Do not be another closed-loop vendor." They already have dedicated tools for Quality Assurance, workforce management, and knowledge bases. Our job is not to replace any of that. It is to orchestrate across it. An AI-native operator that refuses to talk to your existing stack is not AI-native. It is merely a walled garden with a new coat of paint.

Principle 3: Conversations are State Machines, Not Chat Logs

A support conversation is not just a chat. It is a state. Consider this flow:

1. Customer opens a ticket with an order number.

2. AI fetches order status.

3. Customer asks "Can I change the delivery address?"

4. AI checks whether the order has shipped.

5. It has: AI offers a reroute or a return-and-rebuy.

6. Customer picks reroute.

7. AI calls the carrier.

8. Customer says "Oh and also, my other order..."

Anyone who has tried to handle this as a growing prompt with message history knows it falls apart within three turns. The context balloons, the model forgets earlier decisions, the tool calls get redone, and the customer gets asked the same question twice.

An AI-native platform treats every conversation as a durable, replayable state, with full memory of what has been asked, what has been tried, which tools have returned what, and which decisions have already been made. If you restart the service or scale the worker pool, the conversation picks up exactly where it left off.

This is also where the uncomfortable, honest truth about LLMs hides: they are non-deterministic, and they will occasionally make the wrong call. When that happens, you want to be able to replay the exact state that led to the bad decision and see where the system went sideways. You cannot do that if your conversation is just a prompt. You can do it if your conversation is a state.

Principle 4: Measure Process, Not Intelligence

Most AI for support dashboards show metrics like % auto-resolved and call it a day. Those numbers are mostly vanity. They do not tell you why a conversation went off the rails, or which business situation is creating friction, or what to change to make it better.

The Core Metric: We do not measure AI intelligence. We measure process performance.

AI-native measurement starts from a different question: what outcome is the customer actually looking for, and how is the system doing at delivering it?

• Not: "Did the AI answer?"

• But: "Did the refund actually process?"

• Not: "Was the intent identified?"

• But: "Did the customer come back thirty minutes later with the same issue?"

We focus on outcomes, not intents. Quality scores must combine resolution, effort, trust, and experience, not a single AI resolution rate headline.

Furthermore, the platform must be honest about what it cannot resolve. Conversations that do not match any playbook are data, the raw material for the next generation of automation. Clustering them, surfacing emerging themes, and flagging friction in workflows that are technically correct but operationally failing is the real value. The AI that gets smarter over time is not the model itself: it is the system built around the model.

Principle 5: Humans are an Upgrade, Not a Patch

This is the part that differentiates an AI-native operator from a pure-play software tool.

Onepilot has thousands of real, trained agents worldwide. They are not a fallback for when the bot gives up. They are the other half of the same system. For every message, the platform decides between four paths:

1. Autonomous: The AI answers directly and resolves the issue.

2. Augmented: The AI drafts, a human reviews, and a human sends.

3. Collaborative: The AI hands over entirely with a full context briefing.

4. Human-Led: A human owns the ticket end-to-end (e.g., VIPs, crises, legal-sensitive cases).

The ratio shifts over time. A new customer or a new playbook results in a lower confidence score, leading to more human intervention. As the playbook matures and the process stabilises, the system moves towards higher autonomy. The system measures itself and tunes these thresholds conversation by conversation. Our operations team and our AI team are the same team: they ship together, they measure together, and neither can succeed without the other.

This is why our Customer Satisfaction (CSAT) scores do not drop as we automate, they climb. We are not firing humans and hoping the bot is good enough. We are using humans for the work where humans are irreplaceable, and letting the machine handle the rest.

Governance, Traceability, Trust

A lot of what separates production-grade AI from a demo isn't the AI at all. It's the governance layer around it. This is the foundation trust gets built on, and in
enterprise CX, without trust, there is no product.

The first layer is traceability. Every conversation the system handles produces a complete, queryable audit trail: which workflow was chosen and why, which tools were called with which parameters, what each tool returned, how the final reply was composed, which knowledge passages were used to ground it, and what each step cost. Not as a byproduct but as the default. If a reply goes wrong, you can replay the state that produced it. If a refund was issued, you can see the chain of decisions that led there. If a customer asks "why did your AI say X last Tuesday?", you have a real answer, not a shrug.

The second layer is governance. Every tool the AI can invoke is explicit and revocable. Every playbook is versioned, you always know what logic was live for a given conversation, even months later. Sensitive actions can be gated by authority rules ("no refunds over €500 without human approval", "no account changes for unverified customers"), restricted to specific customer segments, or run in shadow mode while they're being validated. The humans responsible for the operation can turn capabilities on and off without shipping code. Nothing the system does is invisible to the team running it.

The third layer is safety. Per-customer data isolation. Identity verification before sensitive actions. Rate limits so a logic loop can't escalate into a financial crisis.
Content filtering. Anti-injection defenses so a crafted user message can't override the system's instructions. Honest escalation when a tool call fails - no pretending a refund went through when the API returned a 500. These aren't features, they're preconditions.

The fourth layer is trust at the contract level. ISO 27001 and ISO 18295 certifications. A public trust center where the controls, sub-processors, and incident-response commitments are laid out, not buried in a sales PDF. Data residency options, so a French insurer can keep everything on European infrastructure, a US retail brand can run on a global model, and a regulated healthcare client can run on a private endpoint: all on the same platform. Customer-owned data, exportable and deletable on request.

None of this is glamorous. All of it matters. The fancy AI research papers are fun to read, but the wins in production come from the unfancy parts, and the systems that take governance seriously are the only ones that survive contact with an enterprise procurement team.

The Paradox of Choice for the Modern Buyer

If you are running Customer Experience (CX) at a fast-growing company today, you likely face one of two problems:

Option A: The Legacy BPO The service is cheap, but quality is uneven. Their AI strategy is a single slide in a pitch deck, and you have zero visibility into why a customer received a nonsensical reply last Tuesday. You are essentially paying for headcount, not results.

Option B: The Shiny AI Tool You bought a software-only solution and spent three months trying to configure it. It can answer "Where is my order?" but breaks the moment a customer asks for a complex exchange involving a promotional code and a change of address. You still have to manage the tool, which becomes a full-time job in itself.

What we offer is neither.

We provide an operator that takes full ownership of the queue, much like a traditional BPO, but built on a platform where AI is the default engine. It is a human layer where the humans are an upgrade, not a patch. It remains open at both ends, your tools remain your tools, and your data remains your data.

Where the Industry Goes Next

The old BPO business model monetised repetition. It thrived on inefficiency because inefficiency was billable. The next generation of CX operators will monetise outcomes.

That shift from billing by the hour to being paid for the resolution changes everything about how a support organisation is designed, measured, and run. Your partner's incentives finally align with your own. AI stops being a cost centre to justify and becomes a lever to pull for performance. The humans in the loop get more meaningful work, not less of it.

At Onepilot, this shift isn't a pivot. It's the model we've been running since day one. We've always billed per ticket resolved, not per hour worked, which means we've always been paid for outcomes, and we've never had a reason to protect repetition. Every minute we save on a ticket is a minute we don't bill for. Every question we can automate is one we, by design, want to automate.

That's why the AI era doesn't force us to reinvent our commercial model. It accelerates it. The incentives that made us good at running human-operated support solve it faster, solve it better, don't pad the hours are the exact same incentives that make us good at running AI-native support.

We know which side of that shift we're building on, because we've been on this side the whole time.

Onepilot runs 24/7 in 35+ languages, serving brands in commerce, fintech, and regulated industries across Europe and the North America. If you are tired of paying for the same questions to be answered for the thousandth time, it might be time to move beyond the traditional BPO model.

For me personally, this is a dream that has been nearly two decades in the making. I’ve wanted to be an entrepreneur since I was 12. While other kids were focused on school and sports, I was in my room in the French countryside, teaching myself to code, building software, and designing video games. From developing multiplayer games at 13 to building dozens of SaaS platforms to solve my own problems, my education happened in the terminal, not the classroom.

After years of deep work as a self-taught creator, seeing Onepilot reach this level of global recognition feels like a full-circle moment. It is proof that if you obsess over a problem long enough, you can eventually build the solution.

Elevating the Ancient Art of Service

Customer support is often dismissed as a back-office function, yet it is arguably the most ancient and crucial pillar of commerce. Since the first trade was ever made, the service following the sale has been the true deciding factor of brand loyalty. In an era of infinite choice, support is the only physical link left between a company and its customers. It is the frontier of brand identity. We believe that when service is executed with precision and elegance, it becomes almost sexy in its own right, not through marketing, but through the beauty of a frictionless resolution! (sexy, right?)

For decades, the legacy BPO industry operated on a flawed logic: if you have more customers, you simply hire more people. This created a linear relationship between growth and overhead, resulting in fragmented quality and black box operations. At Onepilot, we started with a different question: How do we turn the ancient art of service into a scalable science?

We didn’t set out to build another call center but to build a support engine. Today, Onepilot manages millions of monthly interactions for over 250 global brands, including Victoria’s Secret, Dash Water, Decathlon, and SNCF, by treating every ticket as a structured data point in a proprietary lifecycle. This is powered by a strict Human-AI Mix, where our dedicated AI Platform handles the complex, multi-turn workflows that typically cause traditional systems to fail. Whether a resolution requires coordinating between a warehouse, a carrier, and a customer, our platform navigates that logic without human friction.

This engine is supported by nine in-house software products that act as the digital backbone for our 2,000+ native agents. It allows our partners to scale their capacity up or down within 48 hours, providing a flexible utility for the modern retail era. But scaling with global players requires more than just speed, it requires an uncompromising stance on Security and Governance. We’ve built Onepilot to meet the most stringent institutional requirements, from full GDPR compliance and ISO 27001 to AI guardrails that prevent hallucinations and ensure brand-safe interactions. Unlike the black box models of the past, we provide full real-time auditability, giving enterprise leaders the transparency their governance structures demand.

Reaching USD35M ARR and securing USD20.5M in funding were never the ultimate goals, they are simply the metrics of our efficiency. As we expand deeper into Europe and beyond, and continue to refine our Generative AI orchestration, our focus remains unchanged: industrialising the boring parts of business. We want to ensure that high-growth companies can focus on their core mission without the fear of their own success becoming an operational bottleneck.

What's Next?

The Forbes recognition is a nod to the past five years of work at Onepilot, but for the 12-year-old kid who started this journey with a laptop and a dream, it’s a reminder that the roadmap for the next ten is where the real scale begins.

Looking back now, as 2025 ended and 2026 begins, I realise the real thread of the year wasn’t output. It was alignment; between what I build, why I build it, and who I am while building it.

What 2025 Was Really About

2025 wasn’t dramatic. It wasn’t about explosive growth or sharp pivots. It was quieter than that, but far more foundational.

• It was about choosing depth over breadth.

• Experimenting and building at my own pace.

• Getting comfortable with steady, measured progress.

• Trusting my internal compass more than external pressure.

• Being okay with myself, my needs, and my ambitions.

Less noise. More intention.

That orientation matters, because it sets the tone for what comes next. In 2026, I want to keep building from that place, not faster, but calmer. Not more reactive, but more resilient.

Where 2025 Forced Honest Reflection

That doesn’t mean everything went smoothly. The harder moments were the most revealing.

Overcommitment early in the year
Trying to do too many things, especially things misaligned with what truly mattered, drained energy unnecessarily. It taught me that saying yes too often is rarely a sign of ambition. More often, it’s a lack of clarity.

Pressure from outside timelines
There’s a subtle weight in trying to keep up with other people’s pace. This year was partly about learning to let that go. In 2026, I want to make decisions based on readiness and alignment, not urgency or comparison.

Rushing outcomes instead of grounding fundamentals
Fast results feel good. Strong foundations feel sustainable. 2025 reminded me which one actually lasts.

Neglecting health as a silent cost
This year made it very clear that health isn’t something you can defer without consequences. I was ill several times, including one serious episode that put me in hospital for a week. It forced a reset I hadn’t chosen. Energy, focus, and resilience all depend on physical and mental health, and no amount of motivation compensates when that foundation cracks. In 2026, nurturing health isn’t an optimisation goal. It’s a prerequisite.

What 2025 Looked Like for Onepilot

Alignment doesn’t mean the absence of results. It means results that come from clarity rather than chaos.

2025 was a strong year for Onepilot, one I’m proud of, not just because of the numbers, but because of how they were achieved.

We crossed €30M in ARR with a healthy margin structure and strong retention. We welcomed 70 new customers, expanded further beyond Europe, and supported clients in over 20 languages. More than 12 million interactions were handled over the year, with quality scores consistently above 89%.

We also shipped. A lot.
Six major products launched, over 3 million AI-driven interactions delivered, and continued investment in systems designed to scale without breaking.

Behind much of this shipping was a deeper shift. Over several months, I designed and built an entire AI platform for Onepilot in my role as CIO. Not a prototype anymore, but a fully operational system, onboarding clients, running in production, and forming the backbone of what comes next.

I’ll be honest about one thing: I built large parts of it alone. Fast. Deep. In a mode where I thrive. I don’t regret that. It was the right way to get it off the ground.

But it also showed me the limits of isolation. Next time, I want to build more with the team. More shared context, more feedback, more collective ownership. Some of my favourite moments this year weren’t technical at all: they were our leadership days, the moments of alignment where we slowed down, talked honestly, and made sure we were moving in the same direction. That’s something I want to intentionally protect and amplify in 2026.

Externally, the company was recognised more than ever, with seven awards, including client-driven ones, and listings among the fastest-growing startups in Europe. These aren’t goals in themselves, but they are signals. They tell us the work resonates.

Most importantly, none of this came at the cost of the team. We grew to 110 employees across 15 nationalities, with real attention paid to balance, diversity, and sustainability. That matters more to me than any single metric.

Staying Grounded in a Noisy World

2025 didn’t happen in a vacuum.

It unfolded against a backdrop of accelerating AI hype, constant announcements, shifting narratives, and a world that often felt unstable. Technologically, everything seemed possible overnight. Politically and geopolitically, the opposite was true: uncertainty, fragmentation, and short-termism.

In that environment, it became tempting to react. To chase momentum. To build louder instead of better.

I chose the opposite.

Not because I’m distant from AI. Quite the contrary. I spent part of the year working deeply on it, designing systems, shipping them into production, and living with their real-world constraints. I believe AI is genuinely transformative, and I’m excited by what it enables.

But that proximity also makes the noise harder to ignore.

There’s a growing gap between what sounds impressive and what actually works. Between demos and durable systems. Between narrative velocity and operational reality.

Transformation without grounding tends to collapse under its own weight. The more noise there is, the more discipline it takes to stay focused on fundamentals: reliability, usefulness, human impact, and time horizons that extend beyond the next announcement or funding cycle.

So I leaned into pragmatism. Into building things that made sense, solved concrete problems, and could survive contact with reality. Embracing AI fully, while remaining deeply sceptical of hype for its own sake.

Holding both at once felt uncomfortable at times. But it also felt necessary.

A Personal Parallel: Learning to Run (Properly)

On a completely different front, 2025 was also the year I started running.

Before that, I barely exercised. No routine, no structure. Running began almost accidentally and quickly became my thing. I love the solitude, the rhythm, the mental clarity. Time alone, but never empty.

Like many beginners, I overdid it.

Too much volume, too quickly, too little patience, which led to a heel stress fracture and an enforced pause of 4 months. Frustrating at the time, obvious in hindsight. Enthusiasm without balance eventually breaks.

Since then, I’ve approached it differently. I now run between 20 and 40 km per week depending on the phase. I’ve started racing. I’m learning how to train, how to recover, how to listen. Progress is slower, but it’s real. And it lasts.

What surprised me most is how closely this mirrored the rest of the year. Running taught me physically what 2025 taught me professionally:

• Consistency beats intensity.

• Rest is part of progress, not a failure.

• Structure enables freedom.

In 2026, I want to take this further: joining a club, adding a competitive dimension, committing to disciplined training and strength work. Not to chase records obsessively, but to explore potential with patience. To see what happens when effort is sustained, not rushed.

Attention, Energy, and Relationships

One of the quieter lessons of 2025 was about attention.

Between work, screens, and constant background noise, it’s easy to feel busy without feeling present. In 2026, I want to reclaim some of that space: less mindless scrolling, fewer default distractions, more intentional focus. Reading more. Being bored sometimes. Letting ideas breathe. I'll also incorporate meditation and yoga into my routine to stay grounded and support my mental health.

The same applies to relationships. This past year was demanding, and not just professionally. In 2026, I want to create space for quality social time, fewer but deeper connections, and to truly reconnect with the people who matter most, especially my partner. Not drifting. Not postponing conversations. Choosing clarity and honesty, even when it’s uncomfortable.

What I’m Carrying Into 2026

I’m not making resolutions. I’m carrying principles. Principles scale better than habits.

Clarity before speed
Every decision should have a reason. Speed without clarity is just noise.

Energy as a finite resource
Protect it. Nurture it. Spend it deliberately, whether at work, in training, or with people.

Rhythm over extremes
Work hard, rest properly, reflect honestly.

So 2026 won’t be about doing more.
It will be about doing better, with intention, steadiness, and fewer unnecessary distractions.

Closing

When I look back at 2025, the common thread is clear.

Whether it was building Onepilot, writing, learning how to run without breaking myself, or learning when to slow down and involve others, the lesson was the same: alignment creates momentum. Not overnight, but over time.

2026 doesn’t feel like a reset. It feels like a continuation, with better balance, clearer boundaries, deeper collaboration, and a stronger trust in steady progress.

And that feels like exactly the right place to be.

For years, I’ve wanted to write about my experience as an entrepreneur. I wasn’t sure how to frame it or which themes to explore. But now I realise that some things can’t really be separated.

Introduction

I’ve wanted to be an entrepreneur since I was 12. While other kids were focused on school, sports, and friendships, I spent most of my time coding websites, building software, designing video games, and figuring out how to share or even sell what I made. I didn’t feel like school was for me. I wasn’t motivated by grades, I just wanted to create things.

I often felt like an outsider, not just socially, but in how I understood the world. The structure of school and relationships didn’t make much sense to me. People followed unspoken rules, seemed content going through the motions, and I couldn’t relate to any of it. What made sense to me was building something of my own.

Being autistic in that environment was brutal. I struggled with my mental health, severe anxiety, depression, constant emotional ups and downs. Life and school became more about surviving than learning. So I escaped into the things that grounded me, often with other people who felt like outsiders too. If I didn’t fit into the system, I would find a way to exist outside of it.

Looking back, I probably came off as pretentious, maybe even a bit contemptuous. I didn’t come from wealth, my dad’s a handyman, my mum’s a nurse, but I grew up with everything I needed, in the countryside. Still, I told myself I was different, that I didn’t need to follow the same rules as everyone else. I looked at teachers and imagined they would stay stuck in their classrooms forever, while I would go on to do something bigger. Maybe that belief pushed me forward. But it also meant I spent years trying to prove to myself that I wasn’t wrong.

That’s where my journey into entrepreneurship really started.
Spoiler: it didn’t go exactly the way I expected.

Young Projects

When I was 13, I remember developing websites from scratch using HTML, CSS, and JavaScript (like many other people!). That was really fun, especially when it was related to video games. I was also exploring all kinds of tech skills and software, from Photoshop to C++ and Java, 3D modelling, and more.

I spent countless hours working on what became the main driver of my teenage years: a massive multiplayer game based on a fork of the MMORPG Flyff. It became a reference in the French-speaking online video gaming world at the time.

I also worked on so many other projects, building platforms and software, usually with a SaaS approach and most of the time to solve problems I was personally facing. I’m talking about dozens of apps and websites, from trip planning tools and dating websites to educational systems designed to help manage schools or universities.

Much later, I had to decide what to do with my life. To be honest, I didn’t want to stay in school, but my parents made me promise to at least finish and get my A-levels, which I eventually did.

Then I almost got pulled into the system and considered doing undergraduate studies in computer science. I actually started and stuck with it for 3 months before realising I was still surrounded by the same bunch of teenagers, except now, they were paying expensive tuition fees to be there. I had already paid for the year out of my own pocket, so I had to make the most of it. That’s when I decided to study marketing on my own (in a computer science school, yes), iterate on project ideas, do some freelancing to repay my student loan, and try to build a network and understand how things actually work in the real world.

One of my first attempts to pitch a project: a trip planning app

Entering the Matrice

Fast forward to the end of 2020. I’m 23 years old. COVID has exploded, and the world shut down. I’ve spent the past few months feeling more vulnerable than ever, struggling with my mental health, watching my routines collapse, and feeling my mood slip away. I’ve been drifting from hospital to hospital, unsure of what comes next.

But something came. A new project, a new venture, something exciting. Something that would require days and nights of imagining, coding, and doing my best in the shortest time possible. After meeting with two ex-colleagues, who would soon become two of my co-founders, I was convinced to jump into this new adventure, and I would be the CTO.

Our beginnings: the original team of co-founders and first hires (in Ghibli-style, because why not)

The first few months were, and still are, incredibly special to me. I can’t describe how much I value that bootstrapping phase, where everything feels possible simply because everything still needs to be built. I started coding the platform’s modules, pushing a thousand lines of code every 24 hours, creating new features, and rapidly expanding the platform.

I worked closely with my company’s CEO, that ex-colleague I had known for years. It was a delight to imagine the future while building the present. I was developing features almost in real time as we brainstormed them in our meetings, turning ideas into reality as fast as we could think them up. I would wake up in the middle of the night to push lines of code, unable to sleep because new ideas kept racing through my mind.

I had to learn to understand the other founders, which wasn’t easy since we had different personalities, backgrounds, and visions. It was particularly challenging for me, as it always is when I have to meet new people, especially in a context where social harmony is expected, not just casual small talk. Navigating unspoken rules, reading between the lines, and figuring out the right way to communicate without overanalysing every interaction felt exhausting. I remember feeling anxious for a long time, constantly questioning if I was saying the right things or if I was coming across the way I intended. To be honest, it’s still pretty much the same today, it just feels a bit safer.

€2.5M

Hey guys, they loved the demo. Let’s grab some pizzas and talk about something

Only four months after writing the first line of code and signing our first clients, we already had several solid offers from VCs. A month later, after accepting the best ones, we decided to officially launch our company to the public. In April 2021, it was born, and we announced our €2.5M fundraising at the same time. We were officially building something very exciting.

Recruiting

Here comes the unknown! I couldn’t keep developing and maintaining the main platform and new products on my own forever. After all, I couldn’t work 24/7, and at some point, we had to build a tech team to prove we could scale. That meant hiring people, conducting interviews, and, eventually, managing them.

I had my first interview. He was a nice guy, and I thought he could code and understand things easily, like me. I decided to hire him, but it turned out to be a mistake. Instead of easing my workload, it added more weight on my shoulders than if I had just worked alone. I remember not understanding how this could happen: why this nice person just wasn’t good enough? It made me sick, draining all my mental bandwidth. So we hired someone new, then another, and another. With each hire, we gained a better sense of skill levels and what we could realistically expect from a developer. Eventually, we had to terminate some contracts. It was really tough.

Conducting interviews, onboarding people, managing them, it was exhausting. I no longer had the energy to code efficiently.

I remember when we moved into our first office, with sales and operations people joining the team. It was exciting, but I had to face a difficult question: how could I be a CTO if I couldn’t manage my team without burning out and becoming useless to the company? The answer seems obvious now: I simply didn’t have to be the CTO anymore!

Product, Innovation and 🇬🇧

We decided that we would find the new CTO for the company and gradually transition myself into the role of CPO. The goal was to build a proper product organisation to support both the tech team and the broader company vision. It was an interesting period. We were still regularly hiring new engineers, and I was working closely with the future CTO before eventually handing over the team to him.

But what is product, anyway? I had no theoretical understanding of it. It’s not something that was taught in school or online, well, it is now, but even then, there’s no single way of doing “it”. What I did know was how to code and how to make things efficient, so I started from there. I iterated on methods, organisation, roadmaps, communication, boards, design, sprints—everything. Time passed and eventually, we hired a product manager to work with me. Then a product designer.

And… wow, hold on a second. I was building a team again. A team I would have to manage. Hmm. I was definitely having a bit of déjà vu.

I wasn’t just doing “product stuff” (whatever that means). I was still coding a lot, helping the engineers, and working on projects on my own to keep things moving quickly. I’ve always valued flexibility and being hands-on where it matters. And once again, I found myself either being slowed down or getting bored by how my role was evolving. Hey, let’s hire a CPO, no? It worked pretty well the first time.

Oh, I almost forgot: I also moved to the UK in the meantime. That meant I wasn’t physically with my team anymore, at least not as often as before. It didn’t exactly make things easier, but I’m genuinely happy with that decision. I got to discover a new place and be part of the daily life in what became our London office, full of lovely people too.

So here we were again, hiring a CPO (well, a Head of Product at the time) and transitioning slowly, giving me the space to focus on what really matters to me: building, shipping, solving problems. Doing things that actually move the company forward.

At that point, we were kind of running out of C-level titles. What could I be next? Can’t I just be Robin?

All right: Chief Innovation Officer it is.

What I once thought was a BS title actually turned out to be a pretty accurate summary of what I do every day: exploring new ideas, testing things quickly, challenging how we work, and building high-value features on my own, while still staying closely connected with the different teams. We also raised a €15M Series A around this time, investors were confident, we felt the same.

Having a lovely time with the UK team! 🎄

Scaling

If I take a moment to reflect on what we’ve achieved so far, it’s kind of nice, at least, I think it is.

In less than four years, we acquired 2 companies (one outsourcer competitor and one AI startup), grew our ARR (annual recurring revenue) from €0 to €25M, built a team of over 100 permanent employees across three countries, and now counting on more than 2,000 contractors throughout Europe and beyond. Today, we are a profitable business.

It’s easy not to reflect, not to take the time to feel proud or grateful. I’m usually just focused on the work, always thinking about what’s next. It always feels like the beginning to me. Like there’s more to build, more to fix, more to figure out, like it was still day one.

Part of the team at the headquarters in Paris (with our awesome CTO Sacha taking the selfie)

A Different Way of Thinking

I haven't talked about autism as much as you might have expected so far in this article, but it’s everywhere between the lines. It shaped how I saw school and childhood as a system I had to escape. It’s in the anxiety I felt when building new teams, in the exhaustion from trying to read people, in the moments I disappeared into code because that’s where things are a bit calmer.

Being autistic doesn’t mean I have superpowers. It means I experience the world in a way that often clashes with how things are structured — socially, professionally, emotionally. It means I need clarity, consistency, and space to think. It means my habits and routines are essential anchors in a world that often feels unpredictable. It means I can hyperfocus for days, then burn out because I’ve gone too far without noticing. It means new situations, unexpected changes, and social interactions, even the ones that seem basic , can be deeply destabilising. It means I struggle with unspoken expectations, new situations, sensory issues, anxiety and group dynamics, but I thrive in being quiet and building things that solve problems.

What’s hard isn’t always visible. The way I process things, the importance I place on routine, structure, and calm doesn’t always translate. What seems small or trivial to someone else might be something I depend on to feel safe and steady. Masking, overthinking every conversation, trying to function in ways that don’t come naturally: those are quiet battles I fight almost every day. I’ve learned to work around them, sometimes through delegation, sometimes through brute force, and sometimes just by accepting that I’ll never be the most socially comfortable person in the room. But I’ve also learned to own the things that make me different; the obsession with doing things well, the need to question everything, the craving for clarity, efficiency, and usefulness.

It also means I need more rest than most people. Not because I’m lazy, or unmotivated, but because navigating the world, especially the social and chaotic parts of it, takes an enormous amount of energy. After a day of meetings, commutes, conversations, context-switching, or just being around people, I often feel completely drained. Sleep isn’t just rest for me, it’s recovery. I’ve learned to listen to that need rather than fight it. I sleep more than others, and I don’t feel too guilty about it anymore (still a little bit). It’s part of what allows me to function, to focus, to create. Without that space to recharge, I just can’t show up as myself.

Being autistic and a founder can be especially challenging. You're expected to do things you’re not naturally wired to do like talking to a lot of people, going to events, handling constant uncertainty, and showing up with a confident smile even when you’re falling apart inside. And when your sense of balance depends on having a predictable rhythm, that kind of chaos can be overwhelming. And people don’t always understand. You keep your head up, you keep adapting, and most of the time, it works. But it can also be lonely, even with your own associates.

That said, I’m fully aware you don’t have to be a founder to feel this way. Most jobs require you to act “normal,” to communicate smoothly, to perform socially, and that’s exhausting. Many workplaces (and society in general, even more so than the workplace itself) aren't designed for autistic people, and functioning in them every day takes an unseen toll.

I’ve been lucky. I’m mostly surrounded by people who understand me. They give me the space I need, they trust me, they know how I work. For that, I’m genuinely grateful.

I don’t know what comes next, but I know I’ll keep building. That’s the one thing that’s never changed.

And maybe that’s the most autistic part of me.