About
Subscribe

Data as a service in the agentic age

Blocking bot traffic looks like control, but the smarter move is designing systems that agents can use safely.
Johannesburg, 17 Sep 2026
Dale Slabbert, CEO at TrueMark South Africa. (Image: AI-enhanced)
Dale Slabbert, CEO at TrueMark South Africa. (Image: AI-enhanced)

Most systems running today were built with two audiences in mind. There is the user interface, designed for a person clicking through a screen, and there is the API, which is how one application talks to another. Agentic traffic answers to neither description, and it now arrives in numbers neither was designed for.

“We’ve got this whole new set of eyes on our data,” says Dale Slabbert, TrueMark South Africa CEO. “That’s where data as a service today is a little bit more of a different question.”

We know what the human wants and we know what an application wants, he continues, which is what data as a service has meant until now. What remains unsettled is whether that covers a customer that is neither human nor application.

For Slabbert, the way in starts with understanding what that traffic actually is, because once you know what an AI agent is coming to your systems for, you can manage it.

A new customer

For most organisations, the default response to agentic traffic is to shut it out. It’s a defensible instinct given what bot traffic used to mean – anything automated on the network was usually there to scrape, overload or probe something the system was never designed to handle.

“But if we’re just blocking all of the bot traffic, that limits our ability to interact with it,” says Slabbert. At TrueMark, he put $1 000 behind an API key, gave it to his team and told them to go out and impress him. They came back with facial recognition software and a chatbot that could follow a conversation between a group. “That was the beginning of the realisation that there would be a whole new set of traffic coming through our web,” he says, and the team he built out of that became TrueMark’s internal AI unit.

Anyone who has built an agent (or worked with a pre-built one) will understand that there is a gap between what gets asked for and what comes back, and Slabbert says that the model is rarely the reason.

“The data exists, but either the agency you’re trying to get it from has limited your agent’s ability to interact with it, or the data is structured in a way that’s not good enough for AI consumption,” he explains. 

Making data usable to a model once meant graphing it out by hand so that every relationship was explicit, and MCP servers have since taken most of that work away by letting an agent reference data where it already sits. “We need to look at it bigger than just MCP and really build in a way that allows that new type of customer traffic a better way into our systems,” adds Slabbert.

The right data

But a front door for agents is only worth building if what sits behind it is in order. Most data gets collected because it can be, stored because storage is cheap and then never touched again.

“You’ve got to structure your data correctly, which means you’ve got to ask the right questions and collect the right data,” says Slabbert. “Having data for data’s sake is never useful.”

For Slabbert, most of the effort in building a purpose-designed system goes into discovery, working through what a customer already has, why it was designed that way and what they were trying to get out of it. The banks, he says, have decades of customer data sitting in a database somewhere that could be useful to an AI.

“It’s the financial institution’s responsibility to make that data available in a responsible manner to their customers, whether that be a human or an AI agent,” he says.

A new model of interaction

The trouble is that most businesses only think about access rules once something is already running. Anyone who has done a cloud migration knows the alternative, which is a landing zone that sets the permissions and boundaries before a single workload moves across.

Slabbert believes agents should be handled in the same way: “First principles then become very, very important. Things like a landing zone and being able to put together your system in a way that’s secure from the onset.”

According to Slabbert, it starts by deciding how much trust the AI, the engineer and the customer at the other end each get, because that sets how much of the data they can see. Do it at every layer and nothing leaves that wasn’t meant to. “If you do give the AI access to your database, it will want to read the entire database just because, and then it has that data and will never need to come back to you,” he warns. “So effectively, you just gave everything away for free.”

Slabbert has no doubt that agentic traffic will keep outpacing human traffic as availability, affordability and adoption climb. “Your infrastructure is built for a human to interact with. You’re going to experience something quite different once the agentic world hits its critical mass,” he says. “The fairytale we all have in our head is that this AI agent is going to be our assistant, our full-time everything. That future is only possible if the infrastructure is in place to support it.”

For Slabbert, that means looking at data, the most important part of this whole agentic workflow, in a way that makes that future possible. “You now have a new model of interaction, which comes with its own risk profile. How are you managing that?” he asks. “The internet, as we know it, is going to be very, very different.”

Share