AI People Interview: Toby Jonker on Why AI Agents for Small Businesses Need Human Approval, Not Full Autonomy

Toby Jonker, Founder of NerveCore, spent seven months building an AI agent that runs on a business owner's own machine instead of a metered cloud, with a hard rule baked into the architecture: it cannot send anything to a customer without a human tapping approve. He talks about why he built it that way, what selling AI to non-technical owners in South Africa actually looks like, and the mistake that taught him approval alone isn't enough.

Toby Jonker is the Founder of NerveCore, an AI agent built for small business owners who do their own admin rather than technical teams. NerveCore runs locally on the owner's own machine using their own AI keys at cost, and every action that reaches a customer, spends money, or goes public is gated behind human approval. Based in South Africa, Toby built the product to solve his own problem while running a medicinal mushroom company, and has since shaped it around a market where the alternative to AI isn't a competitor's faster tool, it's an employee the owner can't afford to hire.

In this AI People interview, Toby explains why full autonomy is the wrong goal for small business AI, what changed after copy quoting retired pricing accidentally went out under his own company's name, and why he thinks founders selling AI to non-technical owners need to stop talking about how good the AI is.

His Path to NerveCore

Ravi Prajapati: Take us back. What were you doing before NerveCore, and what got you into building AI products in the first place?

Toby Jonker: I was running a medicinal mushroom company, and running all of it: the growing and producing, plus the marketing, the admin, the sales. That's the reality of a small business. You're the operator and the marketing department and the person chasing invoices, and there's no version of the day where all three get done properly.

So I went looking for automation to buy myself time. I'd done a bit before, some Facebook automation, built a couple of websites, I'm comfortable on a laptop. But what I found was either confusing or it didn't do what I'd pictured. Tools that demanded I think like a developer, or that did a fraction of the job and left the rest to me.

I started working with ChatGPT, then Manus, then Claude, and Claude is what the whole thing is built around now. Somewhere in that I stopped evaluating other people's systems and thought: I actually understand this well enough to build the one I keep looking for.

That's how it started. Not a business plan. Me trying to solve my own problem, and gradually realizing the thing I was building for myself was better than what I'd been trying to buy.

Ravi Prajapati: What was the moment you decided small business owners, not technical teams, were the right customer to build for?

Toby Jonker: There wasn't a market-research moment. I was my own first customer.

I built it for my mushroom company because I needed it. By the end, that business was running with a front desk that answered WhatsApp in my tone, took calls, made calls. I wasn't reading every message anymore. I was checking approvals.

And the thing that convinced me wasn't a feature, it was watching it hold context. The agent on my desktop, the one in the cloud, and Claude all share the same vault. The same brain, the same memory. So it wasn't starting from nothing every morning, it knew my business, and it kept knowing it.

That's when it stopped being a tool I'd made and started being something I thought other owners should have. Because the person who needs this most is not a technical team, they've got engineers. It's the owner doing their own admin at nine at night, who can't afford to hire, and who is the bottleneck in their own business.

I've been that person. I didn't have to imagine what they need.

Ravi Prajapati: Why South Africa, and more broadly an emerging market, as the base to build and launch NerveCore from? Does that shape the product differently than if you'd started in Silicon Valley?

Toby Jonker: I'm here. This is home, and these are the businesses I know.

But yes, it shapes it, and mostly around money. The tools are priced in dollars and the business earns in rands. A twenty-dollar subscription is a rounding error in San Francisco and a real monthly decision here, and if there are five of them, that's a proper conversation with your accountant.

So you cannot ship a product whose price grows the more useful it becomes. Someone will do the sum, decide they can't predict it, and never start. Not because they can't afford it, but because they can't forecast it, and an owner who can't forecast a cost treats it as a risk. That pushed me to a single price that doesn't move, and it's a decision I don't think I'd have reached as quickly somewhere the subscription just gets absorbed into a budget.

The other thing is that you cannot assume a technical person anywhere in the building. There's no IT department to call, no one who'll have a look at it on Friday. Whatever the software needs doing, it has to do itself, because the alternative isn't a slower rollout, it's the thing sitting unused. That constraint made the product considerably better than a friendlier market would have.

Ravi Prajapati: Seven months in, what's been the hardest part of the build so far, technically or otherwise?

Toby Jonker: Not the code. The code is the easy part, you can test it, and when it's wrong it usually tells you.

The hard part has been everything around it. The software works and the path to it keeps breaking, in ways that never show up as an error.

During testing, someone went through the signup exactly as a customer would and the billing page tried to charge them the full price instead of putting them on the trial. Two different pages could start a checkout and only one of them had been told the trial existed. Nothing was broken in the part I'd been working on.

Around the same time the agent quietly lost its connection to the good model and fell back to a small local one. It kept answering. Every answer just got a bit worse, for days, with no error anywhere. I only found it because someone told me it felt stupid.

That's the pattern, and it's what I'd warn any founder about. The failures that nearly cost you a customer are almost never the ones you're watching. They're silent, they look like success, and they usually live in the gap between two things that each work perfectly on their own. A file that exists but holds a dead session. A page that says "not found" when it means "not allowed." A note in my own task list claiming something was broken that had actually been fixed weeks earlier, I nearly weakened a true claim about my own product because I trusted the note instead of going and looking.

I've stopped believing anything I haven't just checked myself. That's been the real lesson, and it cost me more time than any bug.

The Build: Local, Owner-Keyed, Approval-Gated

Ravi Prajapati: Walk us through the core architecture. Why run on the business owner's own machine instead of a metered cloud?

Toby Jonker: Because they already own the computer, and it's doing nothing at 3am.

The scheduled work, sorting leads, drafting the follow-ups, preparing the day's posts, runs right there, on hardware they've already paid for. It costs them nothing extra to use it more, which is the opposite of how this normally works.

There's an honest trade-off and I don't hide it: when their machine is off, the work that runs on it waits. Anything that genuinely has to be always-on lives in the cloud instead. But I'd rather explain that trade-off once than send someone a bill that doubled because their business had a good month.

The deeper reason is ownership. It runs on their machine, under their login, with their accounts. What it learns about their business is a folder of plain text files they can open, on their own desk, not a record I hold and rent back to them. If they stop paying me tomorrow, that folder is still theirs and still readable.

I've seen too many small businesses locked out of their own operations by a lapsed subscription. Someone else's server holds their customer history, their conversations, their years of context, and one failed payment puts a wall between them and it. I didn't want to build another one of those.

Ravi Prajapati: What does it mean in practice for someone to use their own AI keys at cost? Why was that important to you?

Toby Jonker: It means they open an account with the AI provider, in their name, and pay them directly. I don't resell it, I don't mark it up, and I don't meter it.

I started with credits, the way everyone does. It was wrong, and it took a while to admit it. Two things break with credits: the owner never knows what a month will cost, and credits run out mid-month, which means the system stops working at exactly the moment it was being useful. That isn't a pricing problem, it's a trust problem. You've made the tool unreliable in a way that's your fault and looks like theirs.

Charging one flat price and letting them own their own AI account fixes both. The bill doesn't move. Nothing runs out. And when they leave, people do leave, the account and everything in it is still theirs, because it was never mine.

Ravi Prajapati: You've built a hard approval gate so the agent structurally cannot send anything to a customer without a human tapping approve. How did you design that gate, and what were you protecting against?

Toby Jonker: The design principle is that it's safe by default. An action the system doesn't clearly recognize as harmless is treated as though it could do damage, and it waits for a person. That's backwards from how most software is built, normally you allow unless you've thought to forbid, and it's deliberate. I'd rather it asks about something innocuous than sends something it shouldn't.

That matters most for the things nobody anticipated. It's easy to gate the actions you thought of. The gate earns its keep on the one you didn't.

The second design decision was about timing, and it's the one I got wrong first. Content has to be checked at the moment it's sent, not when it was written. Something can be composed on Monday, sit in a queue, and go out on Thursday after the facts have changed. Approval happens at one moment and sending happens at another, and treating those as the same thing is how a correct copy becomes a wrong copy without anyone touching it. So the final check runs at the last possible instant, regardless of who approved it or how long ago.

What I'm protecting against isn't a malicious AI. It's a confidently wrong one that doesn't know it's wrong. A person who isn't sure hedges, or asks someone. A model that's wrong reads exactly like a model that's right, same tone, same certainty. You cannot tell by looking, which is precisely why the check has to be structural rather than a judgement the system makes about itself.

Ravi Prajapati: Were there moments during the build where you were tempted to loosen that gate for the sake of a smoother demo or a faster workflow? What stopped you?

Toby Jonker: Constantly. The gate is friction, and friction is what you notice in a demo.

What stopped me was seeing what a loosened gate actually costs. We published copy quoting pricing we'd retired months earlier, publicly, in our own name. I'll come back to that one. We found it ourselves rather than hearing about it from a customer, which was the only good part of it.

But I did loosen the gate in one place, on purpose, and I think that's the more interesting answer. We were gating the creation of unsent drafts, and ended up with dozens of "approve this draft" cards nobody ever looked at. A queue full of things that don't matter is worse than no queue, because the owner stops reading it, and then the one card that did matter goes unread too. You haven't made anything safer. You've just moved the failure somewhere you can't see it.

So writing a draft runs freely now. Sending it doesn't. The gate belongs on the outward action, not on every write.

That's the nuance I'd want other founders to take: erring toward caution isn't automatically safe. Gate too much and you train the owner to click through without reading, which is worse than not asking them at all.

Human Approval vs. Full Autonomy

Ravi Prajapati: Why do you think AI agents for small businesses need human approval rather than full autonomy? What's the risk you're actually guarding against?

Toby Jonker: The risk isn't that the AI turns malicious. It's that it's confidently wrong, in public, in your name, to your customer, and it doesn't know it's wrong. That's the whole problem. A person who isn't sure hedges, or asks. A model that's wrong sounds exactly like a model that's right.

It matters more for a small business than for a big one, and I think that gets missed. If a large company sends one bad message, it's an incident someone handles. If a small business does it, that's the owner. They are the brand. There's no communications department between them and the damage, and in a town where everyone knows everyone, one badly judged message to the wrong customer costs them more than the software will ever save.

So the trade is easy. Full autonomy buys you a few seconds. What it risks is the relationship the whole business runs on. I'd rather the owner taps approve.

Ravi Prajapati: Where do you draw the line between what the agent should be allowed to do on its own and what always needs a human to sign off?

Toby Jonker: The line is whether it leaves the building.

Reading your inbox, sorting your pipeline, pulling a list together, preparing something for you to look at, all of that happens on its own, because none of it can reach anybody. If it gets any of it wrong, you see it and fix it, and nobody outside your business ever knew.

Anything that reaches a customer, spends money, or goes public stops and waits for a person.

I like that line because an owner can hold it in their head without me explaining it. They don't need to know which actions are classified how. They need one sentence that tells them what the thing will never do behind their back, and "it doesn't talk to anyone without you" is a sentence they can actually rely on.

It also survives the product growing. Every time I add something new, the question answers itself, does this leave the building? I don't have to relitigate the policy each time, and the owner doesn't have to relearn it. A rule you have to think about is a rule that eventually gets applied inconsistently, and inconsistency is how the one thing you should have caught slips through.

Ravi Prajapati: Some founders are racing toward fully autonomous agents as the end goal. Do you see approval gates as a permanent design choice, or a training-wheels phase business owners will eventually want removed?

Toby Jonker: Neither, quite. My honest view is that AI is only as good as the common sense of the person running it.

I don't think you ever go to no approval on something that leaves the building and can cause damage. That doesn't get safer with a better model. But a well-trained agent, one that knows your business, that you've fed properly and kept current, can absolutely be trusted with more over time. Certain things should stop needing your tap. That's earned, and it should be.

What can never move is accountability. Humans make mistakes and so does AI, constantly, and someone has to own the output. Your agent should be accountable to you, but that only means something if you actually take up the role and check. That's the part people want to skip. They want the agent accountable to them in the sense that they can blame it, without doing the reading.

So the gate is a mechanism, not the principle. The gate can move. The responsibility doesn't. Anyone selling you full autonomy is really selling you someone else to blame, and it won't work, because when it goes wrong it'll be your name on it.

Ravi Prajapati: What's a real example, even a small one, where the approval gate caught something the agent got wrong?

Toby Jonker: I'll give you a more useful one, the time it didn't, because that's why the last wall exists.

We had copy go out to LinkedIn and Instagram quoting pricing we'd retired months earlier. Numbers that no longer existed, a product name we'd stopped using, publicly, in our own name. Nobody was malicious and nobody was careless. The text had been written when it was true, sat in a queue, and gone out after the facts had changed. Everything in the chain worked. It was just checked at the wrong moment.

That taught me something I hadn't understood: approving isn't enough on its own, because approval happens at one moment and sending happens at another. So now there's a check at the last possible instant, right before something leaves, and it applies regardless of who approved it or how long ago.

It's caught things since. But the honest answer to your question is that the gate we had didn't catch that one, and finding out the hard way is what made the design right.

Selling AI to Non-Technical Owners in an Emerging Market

Ravi Prajapati: What have you learned trying to sell AI to non-technical business owners? What convinces them, and what makes them walk away?

Toby Jonker: What convinces them is seeing it do their work. Not a demo of a generic company, their actual enquiries, their actual customers, their words. The moment it stops being a clever thing and becomes their Tuesday, the conversation changes completely.

What makes them walk away is anything that asks them to configure something. The instant there's a settings page, a field they don't understand, a decision they don't feel qualified to make, they stop. Not because they're incapable, but because they've got a business to run and this has just become another job. I've learned that if it needs someone technical to set it up, it doesn't get used. That constraint shaped the whole product.

The other thing that loses them is the word "AI" itself. They've heard it constantly for two years and mostly from people selling them something that didn't work. So I don't lead with it. I lead with what they'd stop doing.

And the thing I got wrong for a long time: I was explaining how good it was. They don't care how good it is. They want to know what happens when it gets something wrong, because they've already imagined it emailing a customer something stupid. Answer that first and you've got their attention. Dodge it and you've lost them, and you probably don't find out why.

Ravi Prajapati: How does selling AI in an emerging market differ from the pitch you'd expect to hear in a US or European market?

Toby Jonker: The alternative is different, and that changes everything.

In a bigger market the pitch is usually move faster, scale, get ahead of your competitors. Here, the honest alternative to an AI agent isn't a better tool, it's an employee the owner can't afford, or the work simply not getting done. Nobody's asking me to help them scale. They're asking me to help them get out from under it.

So the pitch isn't ambition, it's relief. Not "grow faster," it's "the follow-ups actually happened this week, and you didn't do them."

The money conversation is different too. Every rand is counted, and nobody absorbs a subscription without thinking about it.

And there's a scepticism you have to earn through, which I think is entirely healthy. Most owners here have already paid someone monthly for marketing and got a folder of reports instead of customers. So they don't want to be told it's working, they've been told that before, by someone charging them for the privilege. They want to see what it actually did.

That pushed me somewhere I might not have gone otherwise: showing everything. Every message in full, in the customer's own words. Every decision the agent made and every one it referred back. Not a dashboard summarizing that things went well. In a more trusting market I suspect I'd have got away with a nicer dashboard and a worse product.

Ravi Prajapati: What's the biggest misconception small business owners have about what AI agents can or can't do for them?

Toby Jonker: That it's about replacing people. Almost none of them have anyone to replace. The work I'm actually automating isn't work a person is doing, it's work that currently doesn't happen at all. The follow-up nobody sent. The enquiry that came in at 8pm and got answered on Thursday. The post that didn't go up because it was a busy week. That's the real gap, and it's invisible because nobody's failing at it. It just quietly isn't done.

The other misconception is subtler and it costs people more. They expect to set it up, like software, install it, tick some boxes, done. But an agent isn't configured, it's told. It needs to know your business the way a new employee would: what you sell, how you talk, what you'd never say, what always comes to you first. Owners who treat it as a settings screen get a generic assistant and conclude AI is overrated. Owners who treat it as somebody new who needs briefing get something that sounds like them.

That's why the setup is a conversation rather than a form. Not a design flourish, it's the only way the thing ends up useful, and expecting a busy owner to work that out on their own was one of my early mistakes.

Ravi Prajapati: How do you talk about cost, trust, and control with an owner who's never used anything like this before?

Toby Jonker: Cost: one number that doesn't move. They own their AI account and pay for that at cost, I take nothing on it. So I'm not the meter, and a good month doesn't produce a worse bill. That last part matters more than anything else I say about price.

Trust: I don't ask for it. I show them. Every conversation in full, in the customer's own words, not a report about it. If they want to know what happened today, they look, rather than asking me and getting my version, later.

Control: the approval queue answers it before they've finished asking. Nothing reaches a customer without their tap. And it runs on their own machine, under their own logins, so what it knows about their business sits on their desk rather than mine.

The one that comes up more than anything else is privacy, who else can see this. One prospect pushed hard enough on it that I changed the product: a feature that used to mirror conversations now refuses to run rather than risk showing something it shouldn't. She was right and I was wrong. The product is better for it.

That's the honest shape of these conversations. The good questions come from the sceptical ones, and the objection you can't answer is usually pointing at something you should go and fix.

Looking Ahead

Ravi Prajapati: Where do you want NerveCore to be a year from now, and what would have to be true for you to loosen the approval gate further?

Toby Jonker: A thousand businesses running on it, and partners on more than one continent.

That's the number I'm building toward, and the shape matters as much as the size. Not a thousand logins, a thousand businesses where the agent is genuinely doing the work: answering customers, moving the pipeline, publishing, chasing what nobody had time to chase. That's a much harder bar than signups and I hold myself to it.

The route there is partners, not headcount. People who know an industry cold, someone who understands what actually sells cars, or fills a restaurant, or books out a workshop, setting NerveCore up for businesses in that industry. They bring the expertise I'll never have, and the software stops being what limits anyone. That model works in Cape Town and it works in Manchester or Manila, because the problem is identical everywhere. I'm already building that side out.

And the product keeps growing, more of the business inside one system, a memory that sharpens the longer you use it, an agent that knows your business better in month twelve than in month one. That compounding is what I care about most. Most software is as good on day one as it will ever be. This should be the opposite.

On the gate: what earns more autonomy is a track record on that specific business. Not a better model, those are different things and people conflate them constantly. An agent that has drafted two hundred replies for your company and got the ordinary ones right two hundred times has earned something real. A newer model, on day one, in a business it has never seen, has earned nothing.

And it's the owner's call, category by category, never a switch I flip for everybody in a release. I don't get to decide how much risk somebody else's name can carry.

Ravi Prajapati: What's your honest advice for another founder building AI tools for small business owners rather than technical teams?

Toby Jonker: Build for someone who will not configure anything. The moment there's a settings page, a field they don't understand, a decision they don't feel qualified to make, you've lost them, and you won't find out why. They don't complain. They just quietly stop, and you conclude the market wasn't ready. Make that a hard constraint and it forces the software to do the work instead of the customer, which is what you should have been building anyway.

Stop selling AI. They've heard about AI for two years, mostly from people who took their money. Sell them the thing they'd stop doing. Nobody wants an agent, they want their evenings back.

And understand that the boring path is the product. The signup, the install, the sentence that explains what's about to happen, for these customers, that is the software. A developer routes around a rough edge without noticing it's there. A business owner hits it and stops. So watch real people use the thing, all the way through, without helping them. It's the only honest feedback you will ever get, and it will humble you every time.

Last one, and it's the one I'd argue hardest for: be the face of it. In this market people don't buy software, they buy the person behind it. I'm not hiding behind a logo, my name is on this, people know who I am and what I stand for, and if it goes wrong they know exactly whose door to knock on. That accountability isn't a marketing position. It's the same principle the whole product is built on, pointed back at myself.

About Toby Jonker

Toby Jonker is the Founder of NerveCore, an AI agent built for small business owners rather than technical teams. NerveCore runs locally on the owner's own machine using their own AI keys at cost, with every action that reaches a customer, spends money, or goes public gated behind human approval. Based in South Africa, Toby built the product to solve his own problem while running a medicinal mushroom company, before turning it into a tool for other owners doing their own admin.

• Website: nervecorehq.com

• Instagram: @nerve_core_hq

• LinkedIn: linkedin.com/in/toby-jonker-954a4341b

This interview is part of ReadInBrief's AI People series, where we talk to AI founders and experts building at the edge of the industry. Have someone you'd like us to feature? hello@readinbrief.com or drop a message to Ravi Prajapati.