Agentic AI starts with your data: lessons from Techorama 2026

In short

• Most AI pilots stall because they're too small: small scale, small benefits, and nobody takes accountability to bring them to production.

• Developers already have the toolkit for agent-ready data. CQRS, for one, tells you to treat what an agent reads separately from what it writes.

• An agent's hardest job is knowing what your data means. An inventory, classification, and a semantic layer give it that context.

• With AI answering questions on demand, conferences need to offer more than talks.

Why the model is only one part of the system

Most conversations at our booth came back to AI. What struck me is that conversations are increasingly moving beyond the model itself. We talk a lot about what a large language model can do, but the practical work is often in the software harness around it: the data it can access, the tools it can use, the permissions it has, and the processes that govern it.

That's also why AI works so well in software development. Software data is relatively structured: code lives in repositories, has consistent syntax, and is organised in ways tools can work with. In a lot of other business contexts, the data isn't nearly as ready. I often find that before we can do something useful with AI, we need to improve the data quality, the processes around it, or both.

An enterprise system needs more than a working demo. Validation, structured outputs, error handling, permissions, audit logging, and security boundaries all matter. Luise Freese's POC Prison, which I absolutely loved, addressed a familiar problem: an organisation wants to "do something with AI", people start experimenting, and then nothing really happens.

I've seen this with at least three different customers. They try out something AI-related on a very small scale: agent-assisted software engineering on single files, RAG (Retrieval-Augmented Generation) on a small database, and a fraud-detection agent for high-risk tickets. Because the scale is so small, the benefits are relatively small. And because the benefits are small, nobody takes accountability for bringing them to production. Someone has to introduce maturity and better processes before the work can move forward. The good news: organisations are discovering what it takes to make AI work in reality. AI adoption is maturing.

Developers already speak the language of data

Development and data engineering are more alike than people sometimes think. In my view, agentic AI makes the data fundamentals more important. So I wanted to connect agentic systems to concepts that software and data engineers already understand. No new, magical architecture required.

Domain-Driven Design, bounded contexts, anti-corruption layers, CQRS, materialised views and polyglot persistence: developers know these concepts. They are just different names for ideas that matter in data optimisation. Take CQRS. You need to treat agentic data writes (commands) separately from agentic data retrieval (queries). They are different concerns, and they should influence how you store data and when data pipelines or even duplication are needed. Concepts that cross over like this let developers join the discussion on how data should be organised, represented, and exposed for different purposes.

One distinction helps here. Storage is designed to organise data for systems. Retrieval is about organising information so that intelligence can use it. Those goals overlap, but they aren't identical.

Looking up is different from taking action

In my talk, I used a fictional company, NICEDA Inc., short for "Nothing Is Certain Except Data and Access". Its customer-success team gets an agent that helps them understand customers, identify risks, and carry out approved actions. The agent needs access to SharePoint, Cosmos DB, several SQL databases, and a custom CMS. Across these systems, concepts have different names and different properties, so it's a challenge for an agent to know what the data means.

The agent then creates risk reports and tickets targeted at specific customer representatives. The developer of such an agent needs to know in which system these reports and tickets should be created and which business rules apply.

Looking up a customer's information, summarising it and flagging a risk is one kind of work. Creating or changing a risk report is another. The data access patterns, security requirements, and consequences differ. We need to make that distinction explicit rather than giving an agent broad access and hoping it behaves.

That's also why an agent shouldn't decide its own authorisation. The system determines what the agent may see and do. As we build more agentic systems, sound identity and authorisation mechanisms become essential. OAuth 2.1 feels long overdue.

Five steps to make your data agent-ready

You don't need to begin by rebuilding everything around AI. Start by understanding the data you already have and what you want an agent to do with it.

1. Build an inventory of your data. Know what exists and where it lives, and identify the use cases the agent needs to support.

2. Classify data when it enters the system. Classification and useful metadata give the agent context.

3. Separate retrieval from action. Distinguish queries from commands, each with its own access patterns and security requirements.

4. Automate deletion, archiving, and cleanup. Design deletion into the system from the start, so it never becomes an afterthought.

5. Expose data through a semantic layer where that makes sense. It makes business concepts and relationships usable for an agent.

The other practices from my talk build on these: chunking data by semantic meaning, testing deterministically where possible, and closing the feedback loop, so the system improves based on what happens in practice.

Semantic chunking, for those not familiar, divides text into smaller sections based on their meaning and context. The default is to split text by a fixed number of words or characters. Each semantic chunk contains related information, which makes it easier for AI systems to understand, retrieve, and process relevant content. Semantic chunking is commonly used in RAG to improve the accuracy and relevance of search results.

At Techorama, Arnoud Boere showed how Achmea uses a semantic layer to make data useful for AI. What Achmea is doing looks promising. It's exactly the kind of work I'd like to contribute to from Betabit.

Accountability takes knowledge

Of course, my demo decided to join the show. Just before my talk, I changed my demo repository so the agent's responses would display as Markdown. While I did that, GitHub Copilot installed packages that had vulnerabilities. The build treats warnings as errors, so it stopped. I updated the packages, which triggered an Aspire update, and suddenly I had a last-minute scramble on my hands.

The safeguards did their job: the build refused to ship something unsafe. It was stressful, but because I still understood what was in my repo, it wasn't a crisis. If anything, it got me all psyched up for my session. Accountability is extremely hard without at least some knowledge. Agentic orchestration can be more intense than traditional software engineering. You're not necessarily doing less thinking just because an agent is doing some of the work.

Do developer conferences still have a future?

Building that knowledge takes more than a quick answer from an AI. That brings me to one of my more controversial opinions: traditional conferences like Techorama might not be sustainable in the long term. There's so much information available online now, and AI makes it easier than ever to get answers tailored to your particular situation. A talk can't always compete with that.

What stays valuable is what you can't search for. Workshops, where you learn by doing and get feedback. And conversations between people, which aren't always a direct answer to a question you had, and for that reason help expose blind spots and bias.

I hope Techorama survives and grows, because I love it, and I'd happily go again. I just think conferences need to keep asking what makes them valuable. The answer can't simply be "we have lots of talks".

AI is moving into engineering again

If I had to sum up Techorama in one thought: AI is moving beyond the model into engineering again, and our engineering practices need to keep up. Paul Smit's closing keynote, basically a stand-up performance about psychology, had a fitting message: don't trust your human brain, and don't trust AI, but distrust them for different reasons. We shouldn't assume that either is automatically reliable.

So the key question becomes: what would this system need to be useful and safe? The model matters, of course, but it's only one part of the system. And that system starts with your data.

Want to know how agent-ready your data is? Let's talk about where your organisation stands, and which steps get your agents from the lab into production.