Until recently, most of my AI work has been pretty much turn-by-turn.

Each message kicked off another model call, which might use some files, search the web, write a little script, or use other tools. Then I would look at the result and decide what to ask for next.

Today, I increasingly just describe the outcome I’m looking for and let AI figure it out.

Let me give you an example.

40 gigabytes and 90 minutes

I’ve been using AI to help me with accounting tasks now for years:

• A workflow that detects invoices in incoming emails.

• A prompt template for generating internal vouchers.

• Accounting software that extracts fields and suggests expense categories.

A few weeks ago, I was missing a bunch of receipts. Instead of searching manually, I gave my local AI setup (2 NVIDIA DGX Spark) access to roughly 40 GB of Apple Mail exports, plus PDF statements from my banks and credit cards.

I launched OpenCode, intending to explain exactly which receipts were missing. But I was lazy, so I typed something along the lines of:

“Match all available receipts, put them in a list and give me the documents.”

About 90 minutes and zero interventions later, I had the receipts it could find, plus pointers to where I could get the remaining ones.

The shift is from “help me with that” to “do the work for me”.

Everyone is shipping a "work" mode

Want to Chat or Work?

You can see the same shift in what the big providers are shipping:

• OpenAI launched ChatGPT Work 

• Microsoft shipped Copilot Cowork (what a name)

• Anthropic got there first with Claude Cowork

Interestingly, all of them seem to have a hard time explaining what these things actually do.

I'll be honest: I find it hard to explain, too.

But here's my best attempt.

Give AI somewhere to work

In a normal AI chat, every message basically triggers another LLM run. That model can search the web, read files, execute code, call APIs, or use other tools. But the conversation remains the main interaction loop: you send a message, the model does something, gives you a response, and waits for the next message.

And even that line isn’t perfectly clean, because Chat can already use tools and take actions. But the center of gravity is the conversation. Work mode changes that center of gravity by changing where the model operates.

Your message still goes to an LLM, but that LLM is now sitting inside a larger system: a room with files, tools, a shell, context, and potentially other agents. Instead of only using those things to produce the next response, the agent can interact with the room: create files, modify them, run code, fix mistakes, and keep going.

That room might be a folder on your computer, a Git repository, or a hosted environment connected to business systems.

If I had to boil it down, I’d put it like this:

In Chat, the model uses tools primarily to produce the next response. In Work, the model operates inside an environment it can repeatedly interact with and change to achieve an outcome.

The software layer coordinating the model, context, tools, and potentially sub-agents is often called the agent harness.

OpenAI just went one step further and released its Agents API – giving developers managed access to the same harness and infrastructure that powers Codex through an API.

So instead of specifying every step, you can increasingly say: “Here’s the goal. Here are the files. Here are the tools you can use. Figure it out.”

The chat becomes more of a control interface for what happens inside a given environment. You can even assign multiple tasks simultaneously through multiple chat interfaces.

That doesn't make every task suitable for autonomous execution. But it does change what’s worth trying.

What changes

There’s an interesting consequence to this: in Chat, I can usually edit an earlier message and simply generate a different conversation from that point. In Work, that’s not necessarily possible. The agent might already have modified files or changed the environment. Reverting the conversation doesn’t automatically revert the work.

That’s why things like checkpoints, permissions, version control, and recoverability suddenly become much more relevant.

When you move from “AI giving you answers” to “AI doing the work for you”, it also changes the way you interact with the AI:

1. Prompt for outcomes, not answers

When you chat, you primarily expect something useful back. That might already involve search, files, code, or other tools.

When you work with an agent, you increasingly describe the result you want – and what “done” looks like (ideally unambiguously).

That's why dumb prompting works so well with today's models: strip out the step-by-step instructions, but stay very explicit about the goal.

It works best where the result can be checked. A spreadsheet that reconciles. Code that runs. Numbers that add up.

"Make our marketing better" is still a bad task for an agent.

"Here are last quarter's campaign exports – build me a table of cost per lead by channel and flag anything that doesn't add up" is a great one.

2. The room matters more than the prompt

An AI agent can only work with what's in its room.

If the files are a mess, your data is ambiguous, and the tools aren’t available, even the smartest AI will struggle to get some decent results.

Conversely, even “less powerful” models can deliver surprisingly good results when the room and harness are well-designed.

Which is why everything I wrote about data that wants to be chatted with matters even more once your AI stops chatting and starts working.

3. Budget for usage, not just seats

I used to almost never hit my ChatGPT usage limits. Now, when I work intensively, I run out every couple of days – even on the Business Plan.

The reason for that is that in an agentic workflow, even a very short instruction can now potentially trigger a huge amount of computation behind the scenes. So seat economics increasingly become task economics.

For organizations, it’s no longer enough to ask “How many licenses do we need?” You also need to ask: “How much AI usage is this piece of work worth?”

My rule of thumb is simple: if the usage cost becomes material relative to the value created, it’s probably not a good task for an agent.

A note for organizations

Everything above is easiest when you’re using these tools for your own work. I can give an agent access to a folder on my computer, let it change files, watch what happens, and decide whether I trust the result.

Doing the same thing inside an organization is a completely different story.

The moment that “room” touches real business systems, customer data, production databases, or actions with real-world consequences – you need to think about who owns the outcome, how you trace what happened, and how you recover when something goes wrong.

That’s why I still think the technology for AI agents is increasingly ready, while most organizations aren’t.

What to do next

For your personal work: be more ambitious.

Hand a state-of-the-art agentic system like ChatGPT Work or Claude Cowork a complete piece of work rather than just one step. Give it what it needs to do the job. Define what you want, what “done” means, and where its autonomy ends.

That’s the shift I mean by the end of the chatbot era.

The chat box isn’t disappearing. I use chat-based conversation more than ever. But increasingly, I’m not just exploring ideas or getting my questions answered.

I expect finished work.

See you next Saturday,
Tobias

A joint edition by Tobias Zwingmann and
Karl Ivo Sokolov (Reasonable Intelligence).

You’ve probably noticed it, too.

A few people in your organization are already doing surprisingly advanced things with AI. But compared to the vast majority, there’s often a huge gap.

So what do you do?

We don't think the answer is simply more training sessions or courses. While they provide an important foundation, they’re not enough to “lift the boat”.

What’s missing is a way to build broader AI capabilities while people are actually doing their work.

Let’s dive in.

Forget the average

Almost every organization has a handful of “AI champions” who are incredibly skilled with tools like Claude, ChatGPT, or Copilot. Often because they’ve taught themselves in their free time.

But having a few incredible AI users does not make you an AI-capable organization.

In fact, even having a lot of them doesn’t necessarily mean the organization itself has become more capable. There’s a ceiling to individual productivity gains from AI.

Having highly skilled people is, of course, helpful.

People who know how to use AI typically know how to experiment quickly, figure out what works, and discover use cases nobody else has yet thought of.

But they can also create a misleading picture of how far the organization has actually moved.

A handful of people might have started automating their workflows or building a personal AI agent, but the vast majority probably still uses AI only occasionally for tasks like summarizing emails (and often, the just blindly trust the results).

If you look at the average, those power users pull the number up.

The more interesting question is the median:

What actual leverage does AI give to the typical person in your organization?

That’s the capability you need to move.

It’s not (only) a training job

The obvious response is to train the rest of the organization until they catch up.

That assumes everyone has the same (or a similar) problem. But there are usually very different groups inside the same organization:

• A few people already use AI every day and don’t need another introductory course.

• Others understand AI well, but still struggle to apply it to their actual work.

• Many simply don’t care (quite a lot, you might be surprised).

These are very different problems.

That’s why an organization can spend a lot on licenses, courses, champions, hackathons, and adoption programs while its ability to produce actual AI-powered business outcomes barely changes.

And with AI, access to information is increasingly not the bottleneck. Everyone can ask almost anything, at any time. The bottleneck is being able to apply what you’ve learned to real work, inside your organization.

And that is more than a training job.

From training to execution

This is where we think the biggest shift needs to happen.

Traditional training typically starts with the question:

What should people learn?

But in the age of AI, the more important question is:

What should people be able to accomplish?

That sounds like a small difference, but it changes the whole setup.

Instead of:

Learn → test → forget

you get:

Business problem → attempt → limitation → learning → iteration → outcome

Real projects force people to deal with things that classroom training usually leaves out: the jagged AI frontier, messy business context, ugly data, legacy workflows, stakeholder constraints, and individual judgment.

Having people learn that “AI can hallucinate” is not enough.

They need to run into a mistake in their own process, figure out why it happened, fix it in a reasonable way, and carry that learning into the next project.

That’s a much stronger learning loop.

And it creates two outputs at the same time:

1. A business result

2. Someone who is more capable of producing the next one

That second output is what eventually lifts the boat, especially if you run this loop repeatedly.

Because unlike the output of a single project, that capability can transfer across problems, roles, and functions.

Karl calls this Executional Learning – a tightly scoped project that is:

1. domain-based

2. executive-endorsed

3. coach-supported

4. outcome-driven

The important part is that the learning happens while the work is being done, not before it.

What this looks like in practice

Think of it as the opposite of a weekend hackathon.

Hackathons can be great for experimentation, but they naturally attract the enthusiasts and power users. By Sunday evening, they have a great showcase.

The problematic part is what happens afterwards:

How do you bring this back into the organization?

Very often, you assign a sponsor, form a project group, and expect people to deliver results “on top” of their existing work.

And very often, that doesn’t work.

A better approach is to start by defining a relevant business outcome, then form a small team of people who actually matter for that outcome. Give them direct executive support, enough time to focus on the problem, and access to someone who understands modern AI and is able to coach them through the tricky parts.

Then let them work toward that outcome for a boxed period of time, which might be anything from a few weeks to a few months.

Karl has seen firsthand what this can look like in banking.

In a recent case, a small team took on a legacy RWA calculation engine that different departments had worked around for years. The legacy solution also came with significant external vendor costs.

The team took a targeted approach to the core business problem at hand. They focused on understanding the logic from first principles, considered what could be achieved with modern AI, and rebuilt the critical parts on a modern platform while ensuring the end goal would be to retry the legacy system.

That work took weeks, not years, and it’s now saving the organization six figures every year.

But there was a second – probably even more valuable – outcome: a group of people inside the organization who now deeply understood how to tackle the next problem.

And the next.

That is the whole point.

Filling the ownership gap

To make this kind of Executional Learning work, you need executive support from day one.

Because many of the problems the team will run into are not technical. They are organizational decisions around access, priorities, ownership, process changes, or incentives.

And those decisions often can only be made at the top – someone steps into the no-man’s land between shared IT, business, and HR responsibilities.

Ideally, that’s the CEO – or someone with their full support.

Your job as a business leader

So if you want to “lift the boat,” you can’t delegate this to HR. You have to create the conditions under which more people can become capable.

Concretely, that means:

• prioritize the right problems and business outcomes

• form teams with the required time, tools, and access

• combine domain expertise with AI expertise

• remove organizational blockers

• count both the business outcome and the transferable capability you created

Build the ecosystem in wich gardeners can thrive.

This is also where execution-based learning gets slightly uncomfortable organizationally.

HR typically owns training. IT owns platforms, tools, and access. Business owns the outcome.

An execution-based learning project cuts across all three.

That means someone senior needs to own the outcome and make sure the initiative does not disappear between budgets, responsibilities, and priorities.

And it also changes what you should measure.

Instead of asking: “How many people completed AI training?” or “How many employees are using Copilot?”

ask:

What can the typical person now accomplish with AI that they could not do six months ago?

More AI usage is not the goal.

The goal is higher overall AI capability.

Conclusion

The first phase of enterprise AI was largely about giving people access, running trainings, and finding the enthusiasts.

That was useful, and many organizations have already made substantial progress on this phase.

The next phase is about making exceptional AI capability less exceptional.

To achieve that, training still matters and won’t go anywhere. But if you want to truly lift the boat, you need to create the environment for your teams to build capability while solving real business problems.

You make the organization more capable by making AI capability less dependent on a small group of “champions.”

And you know you’re lifting the boat when that capability has simply become the new normal.

See you next Saturday,
Karl & Tobias

Today, I wanted to share some observations from my recent work around AI for data analytics.

I’ve been knee-deep in this topic since 2022, and what’s clear is that the tools we have today are dramatically better than what we had back then. Today’s AI can write much better code, recover from its own mistakes and work for hours through complex analysis. (Seems like an eternity, but it’s crazy it’s only been a few years!)

Interestingly, many of the problems that made “chat with your data” unreliable back then are still the same problems we’re dealing with today.

What has changed, however, is the approach you can take to solve them.

I really think it comes down to three things you need to have in place – and picking the right starting point.

Let’s jump in!

NEW WORKSHOP

See this live instead of reading?

In my upcoming workshop “Dump Your Dashboard – or Not?”, we’ll connect ChatGPT to a live cloud data warehouse and see what happens when you actually start asking business questions.

→ Where does it work surprisingly well?
→ Where does it fail?
→ How can you fix it?
→ And when is a dashboard still the better tool?

Join the workshop (live Q&A + recording included →

---

It’s not just the model (anymore)

A lot of the problems with AI for data analytics used to be model-related.

The AI was simply too “dumb” to reliably understand that:

• there might be different definitions of the entity “customer”

• it should probably check the code before presenting the result as final

• pretending to be a calculator is generally a terrible idea

They also regularly got lost halfway through an even mildly complex data analysis.

A lot of that has improved.

Upload a complex dataset to ChatGPT today (or connect it to a data warehouse), and it will generally be much better at interpreting what it sees, writing and checking code, and performing tedious analytical work for you.

All of that is really cool.

But it only solves one part of a much bigger problem.

Because a model can:

• write perfectly valid SQL code and still query the wrong column

• calculate a metric correctly and still use the wrong definition

• find a 20% drop in sales and give you a perfectly plausible explanation without knowing that Marketing changed the revenue definition last Monday

We have to stop wondering whether AI can analyze and interpret our data.

It can.

The more important question is whether we can give it the right context at the right time so it can find the answer that we are interested in and that matches our interpretation – or be candid when that answer might not be provided in the given dataset.

So it all boils down to data and context.

(Which is… drumroll… also data.)

And this is where, in my experience, relatively small changes can make a surprisingly big difference.

I call this data that wants to be chatted with.

Let’s take a look.

Traits of “Data that wants to be chatted with”

I found that there are three traits that make a particularly big difference when you run a “chat with your data” use case.

Your data should be (1) easy to query, (2) unambiguous, and (3) governed.

1. Easy to query

The first requirement is pretty simple:

The AI needs to be able to get to the right data without reverse-engineering everything else first.

In practice, data that is not easy to query is typically a nicely formatted Excel spreadsheet with multiple header rows, empty cells for “readability”, or sub-totals in random cells (ideally with wrong formulas).

✅ Easy for humans ❌ Hard for machines

What you want instead is a dataset that comes as a tidy, well-structured table – meaning boring things like:

• one column per variable

• one row per observation or transaction

• one value per cell

Same data, but “tidy”

Good news: if you’re querying data from a data warehouse, it’s typically already stored in a machine-friendly shape.

Even turning your Excel spreadsheet into a flat, “tidy” CSV first – under your supervision – makes a big difference.

For example, in my trainings I regularly upload an Excel spreadsheet that contains British Pound as a currency. In 8/10 cases, even Claude and ChatGPT with high thinking effort are not able to catch that info because it’s stored in the formatting and often gets ignored during import. 4/10 times they hallucinate a currency based on the user’s locale.

If you convert it to a flat table first, you could encode the currency directly in the column header, such as lifetime_revenue_gbp – or provide that additional context separately in the prompt.

Which brings me to part 2.

2. Unambiguous

Being able to query data is one thing.

Giving the AI enough context to interpret what it’s looking at is another.

Imagine your warehouse contains columns called:

• revenue

• net_revenue

• booked_revenue

• recognized_revenue

Which one should the AI use when someone asks:

“How much revenue did we make last month?”

A data analyst working on these kinds of requests every week knows the answer immediately.

“Of course it’s revenue – that’s why we put it there as a separate column!”

AI doesn’t know any of that.

This is where things like clear column names, descriptions, and schema definitions finally start getting useful. (All those things that got deprioritized for years by data teams because they looked more like a documentation exercise.)

At some point, encoding all relevant context in column headers hits a limit, of course.

That’s where things like Semantic Layers, data catalogs, data dictionaries, or knowledge graphs come in. They all solve slightly different problems, but the important part is that your AI has some place to look up what the different fields actually mean. And that those definitions don’t contradict each other.

Typically, building that context layer is the hardest part because it requires the organization to externalize knowledge that was previously sitting in the heads of a few people.

Very often, some of those people have already left.

But the earlier you get to a shared definition of meaning and context, the better in the long run.

3. Governed

You could write this off as another piece of context, but “Governed” in this case means something else. “Governed” clearly defines the guardrails of what the AI is allowed to do with this data and what not.

For example:

• Which metrics are allowed to be calculated? How?

• Which conclusions can be drawn from this dataset? Which ones cannot?

• When should AI stop and tell you that the available data is not enough?

The more you look into this the more you will realize that this is less about telling the AI what is allowed, and more about defining the limitations of it.

A marketing data set might contain a “revenue” field, but it’s probably a good rule to say this revenue field must not be used for financial reporting. Because the number Marketing calls ‘revenue’ might not be one your CFO agreed to report.

These boundaries become especially important once you move beyond simple descriptive questions.

Calculating “revenue last month” is one thing, but explaining why revenue dropped is another. The correct answer might simply be:

“I don’t know.”

This is particularly important because in practice, people transition from descriptive analytics to diagnostic analytics pretty fast.

The first question is what, the second usually why.

And it might be a good hand-off to bring a professional data analyst in.

The key is that these rules shouldn’t live only inside a prompt – or worse, inside somebody’s head.

You can’t teach this at scale using training!

Some rules can live in the system instructions or Skills of your data analysis agents. Others should probably be encoded more deterministically in metric definitions, SQL, semantic layers, or code. The more you can define, the less the AI has to interpret (or hallucinate) during runtime.

Cheap Codification to the rescue, because historically the effort required to externalize and maintain all of these rules was often simply too high.

Which brings me to our practical steps.

Next Steps

Here are two things to help you get started:

1. Make AI context generation the default

Don’t start another data documentation project where people chase after other people to get their definitions updated. You want AI involved in creating and maintaining the context layer from day 1 – and automate more of that process over time.

Practically, if a new metric definition gets added, the system should be able to figure out:

• Where else does this definition show up?

• What needs to change?

• Does anything contradict it?

Aim for building a context layer that can increasingly maintain itself – under human supervision.

This sounds harder than it is. But you have to start small.

2. Start with one useful outcome

To get to that AI-powered context layer, don’t start with:

“Let’s make our entire data warehouse chat-ready.”

You’ll overwhelm your organization before anybody gets value from it.

Instead, start with one useful outcome.

Choose a recurring, high-value question or analytical workflow.

Work backwards from there:

• Which data is needed?

• Is it easy to query?

• Is it unambiguous?

• Is it governed?

Make it exist first, then make it better.

Develop your roadmap from there.

If you want to chat with your data, build data that wants to be chatted with.

See you next Saturday,
Tobias

Fair warning: this article goes a little bit back to the roots.

Back in 2022, I wrote my first book, AI-Powered Business Intelligence, about how AI could make analytics faster, easier, and overall more capable.

A few months later, ChatGPT gave us the viral version of what I previously described as “using natural language to get faster insights from your data.”

Four years later, we’re not just chatting with smarter models. Today’s AI can run entire analytical workflows all by itself – that’s Agentic Analytics.

The question is whether you should let it do that – and what needs to be in place for you to actually take advantage of it.

Let’s find out.

The “chat with your data” use case

Imagine you work with a software delivery team and want to predict the next release date.

You export several months of data from Jira, including issues, their current status, sprint dates, and project descriptions.

You upload the files to ChatGPT or Claude and ask:

“Will our next major release land within the next 5 weeks?”

Within minutes, the AI inspects the files, identifies the remaining work, calculates the team’s velocity, and estimates the remaining timeline – perhaps even with a nice visualization:

Holy smoke, that’s genuinely impressive!

But as with everything that seems to be “too good to be true”, there’s a downside you need to understand.

Answers can be right AND wrong

Let’s say the AI concludes:

“No – the release probably won’t finish”.

That answer might be correct.

Or it could be completely wrong.

The result depends on definitions and assumptions the AI may have chosen without asking you:

For example:

• What does “finished” actually mean?

• Which tickets belong to the release?

• Which status counts as completed?

• Should tickets with no activity in the past six months still count as open?

• Should the forecast use issue count or story points?

For a quick ballpark estimate, these “details” might not matter so much.

But if you need to make a 6-figure budget decision based on this estimate, you want to know exactly what you’re dealing with.

That’s why professional analytics needs more than a plausible conclusion. It needs a transparent and reproducible process that tells you the exact conditions under which the answer is valid.

Chat with your data works best when your data “wants to be chatted with”: highly curated, governed, documented, relatively unambiguous, and easy to verify.

In theory, you could specify all of that inside the chat. (We kind of tried it two years ago.)

But then you’re essentially rebuilding an analytical system inside a chat interface.

It can work, but let me put it like this: You’ll hit a ceiling pretty fast.

The Agentic Analytics shift

Agentic Analytics gives AI a working environment for performing analytics.

The chat remains as a communication channel. But it is no longer the place where the analysis itself lives.

Instead of asking AI to produce an answer however it chooses, you give it a governed analytical workflow. The chat merely triggers that workflow.

For our release forecast, the agent might need to:

1. Understand the business question and gather missing information.

2. Connect to the approved data sources and prepare the data.

3. Apply the correct definitions and forecasting method.

4. Validate, communicate, and preserve the result.

The agent can adapt its approach to the situation.

But it should only adapt within defined boundaries.

If it can silently redefine business terms, use unapproved tools, or skip quality gates, the analysis becomes much less useful.

The Analytical Contract

Reliable Agentic Analytics still depends on solid data foundations, including data design patterns that have been established over the last 30 years.

But data foundations alone are not enough. Three additional components are especially important:

1. A semantic layer: This defines what the data means.

2. Skills: These encode how the analysis should be performed.

3. Artifacts: These preserve the evidence needed to inspect and verify the results (think of notebooks, code, intermediate outputs, and run logs).

Together, these components form what I call an analytical contract – the boundaries within which the agent can adapt without improvising the rules.

It doesn’t guarantee one universal truth. Conclusions still depend on the data, assumptions, and context.

But it makes the process inspectable and repeatable: you can see how an answer was produced and rerun the same governed process under defined conditions.

How Anthropic automated 95% of their analytics

Anthropic recently described a similar architecture for their internal analytics system.

They report automating 95% of their business analytics queries through Claude. Of course, these are self-reported results and shouldn’t be treated as benchmarks. But it seems that adding Skills alone made a huge impact:

So the architecture points to the larger truth: Giving an AI access to your warehouse is not enough. It’s just the starting point.

The business impact

I believe the main users of Agentic Analytics will be data analysts, data scientists, analytics engineers, and data teams more generally.

Not every business employee.

Most business users will continue interacting with data through spreadsheets, dashboards, and, increasingly, chat interfaces.

Which is totally fine.

What changes is the machinery behind those interfaces.

Today, data professionals still assemble many analytical workflows by hand.

“Can you tell me which campaign performed best last month and give me the data?” regularly leads into endless business-asks-data-team-tries-to-answer rabbit holes.

Which reporting period exactly? What do you mean by “best”? Which campaigns are comparable? Do obvious bot clicks count?

Calculating metrics is easy. Landing on metric definitions is the real work.

Agentic Analytics allows teams to encode more of that process once – with the help of AI – and reuse it repeatedly, at scale, without ending up in a backlog of unmaintainable business definitions.

Chat interfaces broaden access to analytics.

Agentic Analytics increases the production capacity of analytics teams.

How autonomous should these workflows become?

We are still figuring that out.

My current view is that most near-term use cases will involve governed execution: a human starts the workflow, the agent performs the approved process, and a human reviews the result.

Narrow and thoroughly tested workflows may eventually run autonomously and escalate exceptions.

But the goal is not to replace in-house analysts, turn every employee into an analyst, or let unrestricted agents loose on the data warehouse.

The immediate opportunity is to help data professionals perform recurring analytical work at a much greater scale.

What to do next

Don’t start by funding a general-purpose “chat with all our data” initiative or building a semantic layer for the entire organization.

Instead, fund one governed analytical workflow built around an explicit analytical contract and tied to one useful outcome.

Choose something valuable, recurring, and currently assembled manually. Campaign performance reporting could be one example; risk monitoring another.

The exact question, reporting period, or slice of data may change. But the underlying data sources, business definitions, approved methods, and validation checks should not have to be rebuilt from scratch every time.

The opportunity is to industrialize recurring analytical work without industrializing the conclusions.

That means more questions handled, faster turnaround, and greater confidence in insights generated with AI support – without lowering your analytical standards.

If you’d like to see how this works hands-on – I’m showing an end-to-end example in my live O’Reilly training, Agentic Analytics with Claude Code. (You can join for free with a trial.)

See you next Saturday,
Tobias

P.S. If you’re a business professional trying to wrap your head around “chat with your data”, my ChatGPT for Data Analytics Bootcamp is a better starting point.

I first published the Integration-Automation AI Framework back in 2023.

Since then, it has become a central piece of my work. I’ve frequently used it in keynotes and dedicated a section in my book.

Today, I still use it a lot because it gives decision makers a simple way to think about a very confusing AI landscape.

(Almost 3 years is a lifetime in AI, so I guess it can't be that bad!)

But the technology has evolved significantly. Agents are no longer experimental toys, and AI is now embedded across mainstream business software.

So I decided it was time for an update.

Here's the Integration-Automation AI Framework for 2026.

The core idea

The basics haven’t changed at all.

I still find it useful to classify business AI use cases along two independent dimensions:

• Integration: How deeply is the AI embedded into the systems and workflows where the work happens?

• Automation: How much of the work can the AI perform without a human being involved in each step?

Those two dimensions give us four basic types:

Assistants: “I need answers when I ask.” Copilots: “Help me in the tool I already use.” Autopilots: “Do this for me automatically.” Agents: “Figure out how and do it for me.”

Ignore what the vendors call it

Don’t obsess over these terms too much. Everyone uses them differently.

Microsoft, for example, bundles much of its AI products under the Copilot brand. But they also give you “Copilot agents,” which shows how quickly the terminology starts to blur.

Other vendors just call everything – even simple chatbots – AI Agents because it’s simply the zeitgeist.

So don't get too hung up on the labels.

Instead, look at what the solution actually does – and what you need it to do.

That usually tells you much more.

Let’s go through the 4 types.

1. Assistants

Assistants are AI solutions with relatively low integration and low automation.

Tools like ChatGPT or Claude, as they come out of the box in basic chat mode, are the best example.

By default, they’re not connected to your internal systems and they don’t do anything without your prompt. You have to log in, provide relevant context, prompt them, take the result and then decide what to do with it.

Typical use cases are:

• uploading a spreadsheet and asking for an analysis

• dropping in a document to get a summary

• pasting an email and asking for a rewrite

To be clear, you can turn these tools into much more powerful platforms than that. You can connect them to your internal files, run tasks automatically on a schedule, or use them to code apps.

But they don’t do this by default.

You have to actively set this up.

That’s why I still classify the basic chat experience as an Assistant: it waits for your command, helps you with the task, and leaves the execution with you.

= “I need answers when I ask.”

2. Copilots

Copilots are similar to Assistants, but they’re more integrated into the tools you use every day.

The AI can typically access relevant context without you having to manually move that context into a separate tool.

For example:

• Microsoft Copilot in Outlook can use your inbox context and help draft emails in your preferred style.

• Notion AI can answer questions based on information in your workspace.

• The =AI() function in Google Sheets lets you send spreadsheet data directly to Gemini.

Instead of opening a separate AI application and bringing your work to the AI, the AI comes to where you already work.

Usually, Copilots come as vendor solutions sold with the software you already use, sometimes as an add-on.

A Copilot may suggest, draft, summarize, or surface relevant context – but a person still owns the work by reviewing, changing, or acting on the AI output.

= “Help me in the tool I already use.”

3. Autopilots

As we move to the right side of the framework, something changes fundamentally.

We’re moving from helping to perform the task to performing the task.

An Autopilot performs a defined job automatically, but inside a relatively narrow lane.

Imagine an AI-powered support system that automatically answers common customer questions based on your documentation.

It may handle hundreds of conversations without anyone approving each response.

That’s a high degree of automation.

But if the customer asks for a refund, the system can’t do it. If someone wants to update an order, there’s no connection to the ERP. No CRM access.

The system is designed to do one well-defined job automatically, not more.

Other Autopilot examples include AI systems that automatically:

• classify incoming emails

• extract structured information from documents

• route service requests

• block content that violates rules

All without a human approving each individual action.

= “Do this automatically for me.”

4. Agents

Agents are where most of the attention is right now.

Unlike Autopilots, they don't just execute one narrow task in a predefined way.

Instead, you give them a goal, access to tools and some boundaries, and they decide how to get there.

For example:

• “Resolve this customer's support issue.”

An Agent might inspect the customer history, query a knowledge base, check the status of an order, decide whether a refund is appropriate, update the CRM and send a response.

The important part is that you didn't prescribe every step.

The Agent decides how to reach the goal.

“Figure out how and do it for me.”

For this, it needs high integration – access to the systems around it – and high automation – the ability to perform the necessary steps without much handholding.

This might sound complex to you, but in fact, AI Agents are no longer particularly hard to build. Any reasonably technical person can put together an impressive Agent demo over lunch.

The difficult part is operating AI Agents inside a real organization.

Because giving an AI autonomy plus access to your systems doesn't remove the need for human responsibility. It increases the need.

AI Agents are dogs, as I call it.

And while the technology is increasingly ready, organizations typically aren't.

Productivity AI vs. Engineered AI

The framework also separates two very different economic games.

The left side – Assistants and Copilots – is Productivity AI.

AI helps a human work faster or better, but a human still produces the outcome.

The right side – Autopilots and Agents – is Engineered AI.

The system executes the work itself. The outcome is produced by the system, which now needs to be owned, monitored and operated.

The expensive trap

The problem starts when companies pay for Engineered AI but only capture Productivity AI benefits.

Like building a “Company Second Brain” with a complex RAG setup and ongoing maintenance. If the main outcome is simply “Our employees spend less time doing research” you might be funding an Engineered AI architecture for only marginal productivity gains.

Whether that investment is justified depends heavily on how important that research task is for your company.

This is where I use this framework as an economic tool as well:

Profitable AI determines how much architecture your business case deserves.

The goal isn't to move every use case toward the most sophisticated architecture.

Build only as much system as the anticipated outcome justifies.

So where should you start?

I still believe that Assistants are usually the best place to start.

You can learn quickly:

• How does AI behave on your work?

• Where does it perform well?

• Where does it fail?

Get proof before you plumb.

From there, only add what the use case actually needs.

If using AI outside the workflow creates too much friction, increasing integration and moving toward a Copilot-type solution makes sense.

If the task is repetitive and predictable enough to run without constant human involvement, increasing automation makes sense.

If the system needs to interact with multiple tools and figure out its own route, you may need an Agent.

The goal isn’t necessarily to reach the top-right corner. The goal is the simplest architecture that solves the problem – and that your organization is ready to operate.

Going in reverse gets expensive fast. Once you start plumbing an Agent into the organization, building integrations, permissions and processes before proving the use case, you’ll likely end up burning a lot of money and trust.

So, next time someone says:

“We need an AI Agent.”

Ask three questions:

1. How automated does this really need to be?

2. Where does more integration actually drive value?

3. Does the business outcome justify the architecture required to deliver it?

Then keep calling it an Agent – and build an Autopilot anyway.

That’s the Integration-Automation Framework.

Let’s see if it survives another three years.

See you next Saturday,
Tobias

Today, I wanted to share an observation I’m seeing increasingly as organizations are building more with AI:

In a lot of cases, AI creates the most value by letting you build a solution that ultimately doesn’t need AI at all.

Let me explain.

The All-in-One Prompt

The thing I’ve realized is that once people discover the power of AI, they often use this “magic” for something that is actually quite straightforward.

Usually, the prompt looks like this:

• You’re an expert for X

• If this happens, do Y.

• Unless that happens, then do Z.

• But if this text says “A”, please do the following.

• Make no mistakes.

If this looks like a decision tree to you, it’s because it is.

Most of these rules actually aren’t ambiguous and don’t require much interpretation

It’s simply that nobody wanted to spend the time (or had the necessary tool or skill) to translate those rules into a proper automation based on explicit logic.

The thing is…

The LLM prompt really shouldn’t be the solution.

It should be the instruction for building the solution.

Cheap Codification

One of the most powerful things AI can do today is to write code.

Most people have experienced this through something like “vibe coding” (or at least seen it on social media). “Describe what you want and let AI build it for you.”

Sometimes it works.

But most people will also hit a wall quickly because building an app that works “kind of” and building an app that works reliably in production are two very different beasts.

And that’s not a rabbit hole worth going into for most business users anyway.

I think the more interesting implication is broader than building apps.

Because code is really just one way of codifying rules.

And businesses are full of rules:

• how something gets classified

• which checks need to happen

• what an exception looks like

• how something gets calculated

• what should happen next

• etc.

For a long time, many of these processes stayed manual not because the rules were impossible to define, but it was just too much effort to turn “here’s how this should be done” into “here is the exact logic a system can do every single time.”

Traditionally, this was a classic consultant job and it would cost a company 4 figures and a purchase order just to get started. For many smaller automations, that made the economics unattractive.

But with AI, the economics of that translation have changed dramatically.

You can literally describe how a process should work in plain language, and any modern AI model can help turn that into whatever deterministic system makes sense – like code, workflow logic, formulas, or decision tables.

All of these are just different forms of codification.

Turning something that’s done by you today into something that runs without you – and can be tried and tested.

And once it works, you may not need AI anywhere in the actual execution.

That’s what I mean by cheap codification.

AI can write the system without having to be the system.

Where AI Fits In

This leaves us with a fairly simple question:

Where should AI actually sit in the system?

I usually see 3 cases:

1. The rules are clear

If the process can be easily described upfront in a handful of steps without many branches or exceptions, just build a normal workflow.

Drag and drop a few nodes together in n8n, Zapier, Power Automate, or whatever workflow automation tool you’re using and call it a day.

You might still use AI for individual steps like extracting information from a document, classifying text, or summarizing something.

I call these AI Workflows.

The process itself remains largely deterministic. The workflow decides what happens next, while individual AI steps introduce some uncertainty where it’s actually useful.

For example, you might use AI to classify an incoming email and then use deterministic rules to route it based on that classification.

Run the same email through the classifier a thousand times and you might get a few different classifications.

But the routing logic itself doesn’t change.

2. The rules are genuinely ambiguous or unknown

Sometimes it’s simply impossible to reasonably define every possible path in advance.

The system genuinely needs to interpret context, decide what to do next, use tools, or react to situations you didn’t explicitly anticipate.

For example, you want to automatically draft a reply to an incoming email.

Depending on what comes in, the system might need to open (or unzip) an attachment, look up internal information, review a style guide, or check whether it needs input from someone else.

Even if you had all the time and money in the world, you couldn’t really map all of those paths upfront.

Here, the ambiguity is part of the problem you’re trying to solve.

That’s typical AI Agent territory.

3. The rules exist, but writing them down is tedious

This is the case I think we’ll see much more often.

The process itself doesn’t really require an agent. Sometimes it doesn’t even require AI at all at runtime!

It’s just painful to translate all the rules into something a computer can reliably process.

Let’s stick to the email example.

Some companies have tried solving this with Rules in Microsoft Outlook on a shared inbox:

• When an email contains X, put it into this folder.

• If the email is for Y, flag it in orange.

• When the sender domain is Z, forward it.

The problem is that these rules often start simple but grow more complex before you can say “email automation.”

At some point, the person who set this up just leaves, and nobody understands the logic anymore. The whole thing gets abandoned over time.

This is where you can use AI to do the tedious part for you.

Describe how the process should work and let AI help you build the underlying logic. When something changes, use AI to update it. Then test the result and deploy it.

The system itself can still be 100% deterministic – no AI involved at runtime. Run the same input through it a thousand times and get the same output every time.

The distinction matters because these are very different architectures.

Just because AI is the easiest way to build the system doesn’t mean AI should be the thing running it.

---

A real-world example

If you want to see this kind of thinking applied in a very different domain, we recently published a D2A2 report on AI-powered engineering drawing generation.

It’s a good example of why reliable AI systems often need more than just an LLM – and how deterministic logic, classical methods, and human validation can be used effectively together.

Download the report for free →

---

The Economic Decision

At first, the three cases might sound like a nerdy discussion for AI architects. You just pick whichever architecture you prefer, right?

But that’s not the case.

There’s an economic reason I care about this.

Every time you put an LLM into the execution path, you introduce another variable that adds:

• cost

• latency

• variability

• more effort to test and monitor

Sometimes that trade-off is absolutely worth it – for example, when the task genuinely benefits from AI interpretation or judgment.

But if the underlying logic can be codified, then paying a model to reinterpret the same rules every single time is simply unnecessary and creates more problems to solve.

This is where cheap codification becomes interesting.

AI can help you build the boring, reliable automation that should have existed all along. It dramatically lowers the cost of building the deterministic system.

You still get the speed advantage of AI.

But you don’t necessarily inherit all of its uncertainty at runtime.

Conclusion

This is why I think “vibe coding” is only the most visible part of what’s happening.

The bigger opportunity is that AI is lowering the cost of turning business knowledge into something explicit and executable.

Not every automation needs AI at runtime.

Sometimes the best use of AI is simply to help you codify what you already know – faster, cheaper, and with less effort than ever before.

That opens up a whole category of automations that previously weren’t worth building.

Which is why, when you look at a process, I’d like you to ask:

Does this really need AI to run – or do I just need AI to help me build it?

See you next Saturday,
Tobias

Earlier this week I sent out a short “Local AI FAQ” in my daily Profitable AI Notes.

I got so much feedback that I decided to expand the format into a full newsletter.

So this one covers the 10 most common questions I get from people I work for or with when it comes to Local AI and open-source / open-weight AI models. (The difference between these terms is one of the top questions.)

The goal of this article is to serve as a practical guide for people trying to understand where Local AI fits into their business – not a technical setup tutorial.

Obviously, this FAQ could go on and on, but I’ve tried to keep each answer short and the whole thing easy to skim.

If you have a question I didn’t answer here, feel free to use the comments under this post and I’ll get back to you this way.

With that said, let’s jump right in!

Why Local AI, Now?

I’ve written about the importance of Sovereign AI, and running local AI workloads in your business before.

But these days, something interesting is happening around open-weight AI.

When Nvidia CEO Jensen Huang shared Nvidia’s open letter around open weight AI, it quickly got 60M views and counting. In just about 6 days, the open letter that was also officially distributed by Microsoft was signed by over 230 organizations.

Jensen Huang via X

For context, the letter contains lines like this:

The core argument here is that open-weight AI has left hobbyist territory and earned its place as strategic (enterprise) infrastructure.

Open models give businesses an exit.

With a proprietary model, the provider can:

• change the price

• change the model

• remove the model

• limit the usage policy

Leaving you empty-handed.

Relying completely on proprietary artificial intelligence is a bit like running a business completely on an army of contractors. It works, but the underlying capability never becomes yours.

That’s why I believe at some point you have to call your AI workers back to the office.

Open-weight models allow you to build and own your own AI which you can download, fine-tune, and use as long as you want.

If this reads like rocket science to you, it isn’t.

I recently met a CTO of an entirely non-tech (some people would even call it “legacy”) company with around 200 people who runs 90% of the company’s AI needs on hardware that cost less than a company car would cost for himself. Claude APIs come in just for some edge cases that require frontier intelligence.

I regularly advise clients on the options of local AI once they have a high-volume AI workflow into production.

I’m not saying you should cancel all your AI subscription and go open-source though. That would not make any sense (see the FAQ below).

But if you’re running business-critical workflows with AI, exploring what the world of open AI models has to offer you, is definitely a smart move.

In fact, if you want to try out Local AI, it literally takes about 1 hour and nothing more than a laptop that is less than ~5 years old. Everything else is covered in this LinkedIn Learning course by me which you can take for free of charge using the link in this post.

Watch my LinkedIn Learning Course for free!

Local AI with Ollama and n8n – run your first local AI workflow in less than 60 minutes (no coding required).

LinkedIn Learning

Anyway, we’re already getting deeper into the matter.

So here are the Top 10 FAQs.

Heads-up: This will be a longer email but since this is a list of FAQs it’s not intended to be read end-to-end (you could though). If you’re in a hurry, feel free to pick the questions that resonate most and skip / skim as you like.

Top 10 Local AI FAQ

So here are the questions I get asked most by customers my usual responses.

1. What is Local AI?

In short: running an AI model on hardware or infrastructure you control.

“Local” could mean:

• a laptop

• a workstation

• an internal server

• private infrastructure in a data center

The important distinction is control over where inference happens.

2. Is Local AI the same as open-source AI?

In short – no.

Open-source describes a model whose code, weights, and license meet open-source criteria. In the most narrow sense, that would also include details about the training process and data (which hardly an “open source” model provides).

That’s why most open-source models area really just open-weight means the model weights are available, but the exact details about how they were trained and not fully disclosed.

Local AI describes where the model runs.

You can:

• run an open-weight model locally

• run an open-weight model in the cloud

• even run proprietary models on your own infrastructure (if the vendor allows it)

In practice, most Local AI setups use open-weight) models – but the two terms are not interchangeable.

3. Is Local AI really free?

Let's put it this way.

There are no per-prompt API charges or monthly subscriptions like with cloud models.

However, you still pay for hardware, electricity, and maintenance.

Think of it like owning a car versus taking an Uber.

Once you've bought the car, every trip is cheap. But owning the car isn't free.

Local AI replaces variable usage costs with more fixed infrastructure costs.

What you’re really getting with Local AI isn’t necessarily an AI service that is cheaper, but one that has a more predictable cost structure.

4. Will a Chinese model send my data to China?

Not if you're actually running it locally.

Once the model is downloaded onto your own machine – regardless of who developed it – it performs inference on your hardware.

Nothing has to leave your computer.

If you're paranoid, you could even unplug your machine from all network connections the model would continue working just fine.

5. Can I run Local AI on my laptop?

Yes.

Assuming your laptop isn't more than 3-4 years old and has at least ~8 GB RAM.

(In practice, available RAM is usually a much bigger limitation than CPU performance.)

That said, this won’t run GPT-5 class models for you.

But you can absolutely run Small Language Models (SLMs) that are excellent for well-scoped tasks like document extraction, classification, summarization, and many automation workflows.

The rough “class” of a model is measured by its parameter count. It is an imperfect proxy for capability (think of the days when we measured a CPU’s performance by looking at its GHz), but it still helps estimate hardware requirements. SLMs become useful at around 1 billion parameters, whereas frontier models such as GPT-5 supposedly have over 1 trillion parameters.

For example, I can run Google’s Gemma-3 SLM (4 billion parameters) easily on my 2023 MacBook Air with 8 GB RAM. A modern Macbook Pro with 16GB RAM would run Gemma-4 (12 billion parameters). For more advanced models, you would need more bespoke hardware, see below:

6. What is the best Local AI model right now?

There’s not one universal winner.

If you’re looking at benchmarks, you can find a pretty comprehensive comparison of the general “intelligence” of open source models (that you could run locally or anywhere in the cloud) on Artificial Analysis, a research group that tracks model performance across multiple tests.

The “best” model here changes every couple weeks, but most recently models developed in China are leading the pack here.

That said, you shouldn’t look for the best model in a hypothetical benchmark, but the best model that works for your requirements. Which is typically a combination of the following questions:

1. Is it good at your use case?

2. Can it run on your hardware?

3. Is it fast enough?

4. Does the license allow your intended use?

As a rule of thumb, here are some heuristics I use

If I need to mimic the style of ChatGPT or re-use prompts I’ve written there, I use OpenAI’s gpt-oss models because they “feel” very similar to what many users are used to.

If I need to analyze image or audio files, I typically look at Google’s Gemma models because the family includes multimodality across the board.

If I need agentic use (calling tools, running in loops) on Nvidia hardware I give Nvidia’s Nemotron models a try first, because they are are designed in particular for efficient agentic reasoning and tool use on Nvidia hardware.

I generally do not use the latest and greatest open-weight models like Kimi-K3 or GLM-5.2 (or any other LLMs that lead the benchmarks) because there’s typically no way for me to run them locally.

(See next point)

7. How do you personally use Local AI?

Personally, I use Local AI less as a private ChatGPT replacement, but more as a private automation engine.

For example, when I build AI solutions for clients I’m running the evaluations for those solutions locally by testing the solution with local LLM judges on my Nvidia Spark.

I have also workflows running for extracting insights from private transcripts, or helping me manage multiple email inboxes.

My Private Insightizer Workflow

And the last use case is data analysis where I use local AI models to analyze thousands of records, for example generating insights from surveys or other unstructured datasets.

I never use Local AI as an interface to chat. I use it to make workflows run quietly in the background (mostly using a local installation of n8n as the automation engine.)

8. What are the best Local AI use cases?

I don't think there is one. There are thousands.

Here are some of my favorite use case categories:

Document processing

Every business has documents. Contracts, invoices, purchase orders, forms, spreadsheets. And every business at some point needs to organize these documents (like routing the right invoice to the right department, or checking whether a contract contains any red flags.)

If you’re consistently processing a few hundreds of documents every week – Local AI might be a great fit, because the data stays on your infrastructure, you have stable costs, and the workflow can run 24/7.

Internal knowledge search

Do your employees regularly need to search through company policies, technical documentation or operating procedures?

A local AI model combined with Retrieval-Augmented Generation (RAG) can easily answer questions without sending confidential company data to an external provider.

Data harmonization and extraction

Need to pull names, addresses, invoice numbers or product information from PDFs, emails or scanned documents? Or match naming schemas?

Small local models are surprisingly good at structured extraction tasks.

And because they're inexpensive to run, you can process thousands of documents without worrying about API costs.

Classification on Text Data in General

• Is this email a sales enquiry or a support request?

• Is this invoice approved or missing information?

• Which department should this document go to?

These are simple AI decisions that happen thousands of times every day.

Good candidates for Local AI!

Batch workflows

Many AI tasks don't need an answer in two seconds. They can simply run overnight!

Examples:

• Report generation

• Survey analysis

• Complex document summaries

Nobody is waiting for the result in real time, so speed isn't the limiting factor. Cost and reliability are.

The common thread through all of these is that they don't require frontier-level intelligence.They require an AI model that's good enough, affordable to run, and close to your data.

That's the happy place for Local AI.

9. Why shouldn’t I just cancel my subscription and build a Local ChatGPT clone?

There’s a huge difference between running a well-scoped AI workflow across thousands of records overnight and serving a responsive chat interface to hundreds or thousands of users.

At that point, you are operating a platform rather than merely running a model.

Background automation tasks, on the other hand, hardly need any interface or “user management” at all.

If you do want a local ChatGPT clone, I recommend checking out OpenWebUI which is one of the best “ChatGPT clones” out there.

10. Should every company use Local AI?

No.

Local AI is a great choice when you need control, privacy, predictable economics, independence, offline operation, or high-volume processing.

That said, if you’re not sure whether you’ll need any of these, starting with pay-as-you go models in the cloud is often the better choice.

There are rare cases when no data at any circumstance must leave your computer (like in investment due diligence or legal cases), but generally you’re faster prototyping a solution in a secure vendor ecosystem like Microsoft Azure / Copilot or any other trusted provider.

But starting in a vendor ecosystem shouldn’t mean you’re locked in there forever.

You can still choose.

And that’s the whole point.

Conclusion

We’re already 2,000 words in and I feel I’m just getting started.

So let’s wrap this up with one key takeaway for you.

Local AI is not another movement you need to join.

Use cloud AI (and typically proprietary AI models) when you need:

• frontier intelligence

• rapid access to new capabilities

• highly scalable interactive applications

• minimal infrastructure work

• polished user experiences

Think of Local AI as another capability you should understand at a high level.

You may decide not to use it today. But knowing what can run privately, cheaply, and independently will help you design better AI systems.

What matters is the mix that works for your business – and whether you chose it intentionally from an economic perspective.

See you next Saturday,

Tobias

PS: If you want to get hands-on and run a Local AI model on your computer in less than an hour, check out my LinkedIn Learning course Run Local AI Workflows with Ollama and n8n – you can watch it for free using the link in this post.

AI makes it incredibly easy to add things.

A new use case here, another pilot there. A training program. A governance committee! Before you can say "acceleration" you're stuck in planning and alignment meetings.

The thing is that each addition seems reasonable on its own.

But taken together, they will turn your AI transformation into a sprawling collection of pending decisions.

And that’s why every good AI strategy now more than ever needs to tackle the "art of saying no" by not just articulating what the organization wants to do with AI.

But giving an explicit answer on what it will deliberately ignore for now.

Want to find out how?

Let's dive in!

AI creates an abundance problem

A few years ago, finding possible AI use cases was genuinely difficult.

You needed people who understood the technology, people who understood the business, and enough imagination to connect the two.

Today, you can ask ChatGPT to generate 100 AI use cases for an insurance company, manufacturer, retailer, or trade-show organizer before your first coffee gets cold.

I saw this firsthand in a recent engagement: one week of opportunity-mapping workshops at a 500-person company surfaced around 350 problems – and 270 of them looked like a good fit for AI.

This is not a strategy.

Because each of these 270 items will raise questions like:

• Who owns it?

• Who pays for it?

• Is it more important than something else?

• Build or buy?

• How feasible is it?

• Who maintains it after launch?

The cost of producing an idea has literally collapsed to zero.

The cost of evaluating, coordinating, funding, and operating it has not.

That organizational cost is now the real bottleneck.

270 use cases are rarely 270 opportunities

No management team can meaningfully commit to 270 initiatives. It's just too much.

But the list didn't need 270 decisions. It also did not need deleting 260 use cases and keeping the best top 10.

What was needed was merging and deduplication. So we looked for artificial fragmentation: different departments asking for different variations of the same thing.

Take document extraction for example. For some teams, this might come in the form of contract Q&A. Others might use it for internal decision preparation. They look different because they originate from different teams, processes, and organizational boxes.

Strategically, though, they were often the same request: better knowledge access arriving through different doors.

We also filtered the list through the $10K Threshold (about 110 ideas survived) and deduplicated what remained by underlying problem instead of org chart.

The result was 7 opportunity clusters worth more than $1M per year in untapped potential. The individual use cases still exist underneath.

But the organization now has 7 things to focus on instead of 270.

Every initiative creates another management problem

I'm seeing the same pattern in another engagement right now. The list is smaller (50 use cases instead of 270) but the number of themes that can actually hold management attention is the same. (In this case, we're aiming for four to five.)

Most business cases account for licences, implementation costs and expected savings. Very few account for management attention.

Someone must champion it. Someone must coordinate stakeholders. Someone must review the output. Someone must answer questions when it fails. That cost rarely appears in the proposal.

But attention is the scarcest resource in the building.

This is why saying no is not the opposite of ambition.

Saying no allows you to turn ambition into action.

Two ways of saying ‘No’

I found two ways of saying no to be helpful:

1. Say ‘No’ to fragmented initiatives

Look for use cases that appear different but depend on the same capability, data, workflow, or business outcome.

Instead of funding them separately, cluster them around a central opportunity themes – like the five knowledge-access requests above.

This matters most for Engineered AI: every disconnected initiative drags its own infrastructure, integration, and maintenance along with it.

My rule of thumb: deduplicate by underlying problem, not by org chart.

2. Say ‘No’ to low-value commitments

This is what the $10K Threshold is for.

If a use case can’t generate at least ~$10K per year in recurring impact, it does not deserve engineering, integration, governance, or management attention.

It's the filter that cut our list from 270 ideas to 110 in a single pass.

Not because the ideas were bad. Because they were too small to matter.

"Not now" is a valid strategic decision.

It is in fact often better than leaving an initiative in a permanent state of vague importance.

One way of saying ‘Yes’

One warning, because I learned this the hard way.

Present seven themes that span multiple departments for funding and the organization will end up debating the portfolio instead of building the first profitable thing. That is exactly what happened with the $1M AI roadmap I mentioned above.

So treat "Saying No" and ownership as two halves of the same move:

"Saying No" takes you from 270 use cases to seven themes.

Saying Yes to Ownership takes you from five themes to the one opportunity you start with – valuable enough to matter, narrow enough to ship, with a named sponsor. That sponsor needs enough authority to protect the initiative across departmental boundaries and resolve the trade-offs it creates. Spoiler: In many cases, that's the CEO.

To be clear, the goal is not less AI.

“Saying No” is not an argument against ambitious AI investment — broad Productivity AI adoption should absolutely continue.

But to overcome the impact plateau and unlock the real opportunities, you have to say no to a lot of things and assign clear ownership to the right things.

The “Saying No” test

Before adding another initiative to your AI roadmap, ask these 5 questions:

1. Is this disconnected from what we have in our focus?

2. What recurring value justifies the organizational effort?

3. What will receive less attention if we pursue it?

4. Who owns the outcome – and who sponsors it?

5. What evidence would make us stop or defer it?

Can’t answer these clearly? You’re adding more possibilities to the pile, but not making your actual AI strategy stronger.

Conclusion

AI has made it easier than ever to create.

Attention concentrated on a handful of themes cannot simultaneously support hundreds of ideas.

A good AI strategy makes those trade-offs explicit instead of hiding them behind a long roadmap.

It combines fragmented use cases into coherent opportunity themes and explicitly answers what the organization will not pursue (for now).

Because merely adding AI will not automatically simplify your organization.

It will simply give your organization more things to manage.

See you next Saturday,
Tobias

Everyone responsible for AI adoption is searching for the big use cases.

Not the ones that help employees write emails 10% faster. But the ones that transform an important process, create a new revenue stream, or save the company hundreds of thousands of dollars (or euros).

Those opportunities exist. But finding them requires a better definition of what a good AI opportunity looks like.

Because the best opportunities I’ve found didn’t simply have a large upside.

They had a controlled downside above all.

Let’s find out why this mattered so much.

Asymmetric Bets

Many promising AI ideas will fail.

That uncertainty can never be fully eliminated before testing.

The goal is therefore not to find projects that are as safe as possible, but to to find projects where failure is survivable and success is relevant.

That is the core idea of an asymmetric bet, also called optionality. Visually, this is how it looks like:

Imagine your AI project is a marble rolling on this curve above. When your initial hypothesis does not work out, the marble will move to the left and create a business loss. But that loss is limited. If it does work out, however, the marble will move to the right and the gains it can generate are literally unlimited. Your upside is open.

This principle matters because higher risk does not automatically produce higher returns. An AI project can be expensive, technically complex, and operationally dangerous while creating almost no business value.

The opportunity must be worth pursuing first.

Then the downside must be controlled.

Two Types of AI Risk

The downside looks different depending on how AI is used.

Productivity AI: Controlling Work Slop

To explain downside control in the context of Productivity AI, let me tell you a little story:

For our wedding, we hired a professional photographer.

She took around 5,000 photos of the event. In the end, however, we got about 300.

Getting rid of the 4,700 made the service actually more valuable.

Imagine we had received all 5,000 pictures. That would have transferred the work of screening, selecting, and deleting back to us. More output would have created less value.

Productivity AI creates the same risk inside organizations, and it is happening right now:

Human Written Words vs. AI Written Words, Source: Brett Winton

When AI makes creation cheap and review expensive, companies generate tons of mediocre work which costs millions and erodes trust between coworkers.

A document may take five minutes to generate and fifty minutes for someone else to verify, correct, and understand. At that point, AI is not removing work. It is creating actually more work downstream.

The controls for productivity AI are therefore editorial and organizational:

• Who owns the final result?

• What quality standard must it meet?

• Does the output need to exist?

• Who must review it?

• Is AI reducing total effort or merely moving it?

Employees should not treat AI-generated output as a deliverable.

They should treat it like a photographer treats a raw image: something to inspect, improve, select, or discard.

High AI adoption does not mean to maximizing AI output.

The goal is to deliver meaningful outcomes in the most efficient way.

Engineered AI: Controlling Action and Cost

The risk profile change when AI is embedded in a system.

An employee using ChatGPT to draft a presentation is unlikely to create a major infrastructure bill overnight.

An autonomous system can.

Agents may run for hours, call models and tools repeatedly, process large volumes of data, retry failed actions, and continue operating without supervision. Every token, request, document, tool call, and retry can increase the cost.

But financial exposure is only one part of the downside.

An engineered AI system may also send incorrect messages, alter records, expose confidential information, make unauthorized decisions, or generally. take actions that are difficult to reverse.

These systems require explicit financial and operational limits.

Before allowing one to run, define:

• the maximum budget per run period,

• the actions it may take,

• the data it may access,

• the conditions that stop the process,

• the points that trigger human review,

• and the actions that always require approval.

This is the Cost Cap model and AI Governance in action.

Together, these controls prevent a small technical failure from becoming a larger financial or operational problem.

They also make experimentation easier. Because when the worst-case outcome is known and contained, teams can test more ambitious ideas with greater confidence.

Preserve the Upside

You could understand downside control as an argument for only launching smaller, more cautious projects.

This couldn’t be more wrong.

Ultimately, downside control is what makes ambitious projects possible.

The goal is not to make AI projects smaller. The goal is to design them in a way that preserves most of the upside while keeping the downside under control.

I’ll give you two examples.

In Productivity AI, you could limit the downside by giving AI to only a small group of people. That certainly reduces the risk of poor AI-generated work spreading through the organization. But it also removes most of the potential impact.

A better approach would be to make AI generally available with clear expectations for how AI output is being used. AI-generated work is always a draft, not a deliverable. Hold the person submitting the work accountable for its quality. Make it explicit that responsibility for quality can’t be delegated – not to AI or to anyone else.

For Engineered AI, suppose you want to automate customer support. You could start with an AI that drafts replies for human agents. That feels safe, but it also limits much of the potential value.

Instead, I would recommend building the self-service experience you actually want, but limit where it operates. Give the AI broader capability within a narrow category of customer requests, rather than limited capability across every request. Restrict the actions it can take, monitor the results, and expand the scope only after it has proven reliable.

Conclusion

Instead of asking:

How can we guarantee this will work?

ask:

How can we test this opportunity in a way that keeps the downside small while preserving most of the upside?

You’ll never be able to completely remove uncertainty from AI projects.

But you can make it affordable enough to keep experimenting.

Which is what downside control really is all about.

See you next Saturday,
Tobias

At the end of one of my recent talks, someone in the audience asked me if I had any advice on effective AI upskilling within an organisation.

I gave my usual answer – teach the basics with on-demand courses, offer tool-specific training, and organize exchange around real use cases.

I still believe all of that, but I realized it's not the whole picture anymore. Because this explanation assumes organizations have one AI training problem.

When in fact, they have three.

Here’s what they are (and what to do about them).

From Pyramid to Pendulum

Two years ago, I wrote that every knowledge worker – not just technical teams – needs AI training.

Back then I described AI learning as a pyramid inspired by Bloom's Taxonomy: build the foundations first, then gradually move toward application.

How I saw the AI training world in 2024

That made sense in a world where knowledge was relatively stable and learning followed a predictable sequence.

Modern AI doesn't work that way.

Trying AI costs almost nothing these days. Feedback arrives in seconds. You don't need weeks of preparation before experimenting – you can discover what you don't know simply by using the tools.

When trying becomes cheaper than studying, the learning order changes.

People learn what a context window is because a conversation starts forgetting earlier messages. They learn about hallucinations after seeing one. They learn prompt design because their first attempt produces mediocre results. Not because they saw it in a training video on slide 14.

So theory becomes just-in-time instead of just-in-case.

AI learning isn't a pyramid you climb once.

It's a pendulum that constantly swings between understanding and application. You try something, hit a limitation, learn why it happened, then apply that knowledge to the next round.

How I see the AI training world now

The problem is that not everyone gets stuck at the same point in that cycle.

3 Different Confidence Problems

Across organizations, I keep seeing three groups of people.

1. The Practitioners

These people already use AI every day.

They summarize documents, prepare meetings, analyze spreadsheets, write code, draft proposals, or automate parts of their work. Many of them – estimates range from 50% to 80% – have never received formal AI training at all.

They're not waiting for permission – they're already building habits.

The question is whether those habits are any good.

The problem here isn’t that AI makes mistakes (it always will), but that people stop noticing them.

A well-known BCG field experiment with 758 consultants found that AI significantly improved performance on tasks within the limits of what the AI was capable of doing. But when participants tackled problems just outside that frontier, those using AI were substantially more likely to produce wrong answers.

We've already seen this in the real world. KPMG pulled back an AI report after AI-hallucinated case studies were exposed, and Deloitte Australia agreed to a refund after a government report turned out to contain AI slop.

A Microsoft and Carnegie Mellon study found the mechanism behind it: the more people trusted AI, the less critically they evaluated its output.

Today, this matters more than ever. Modern AI tools got extremely more powerful – evolving from simple chatbots to agentic systems that "stay with a project for hours if needed," and turn a goal into finished work – as you can see for example by the latest ChatGPT Work announcement from OpenAI.

These employees don't need another AI introductory course.

They need better judgment.

Teach them where AI performs reliably, where it struggles, and how to verify outputs before acting on them. For example, don't ask an LLM to "find every risk in this contract." Ask, "Is there a change-of-control clause? Quote the relevant section," because specific claims are much easier to verify than completeness.

The goal here is essentially to avoid the Dunning-Kruger effect – not by reducing their confidence when working with AI, but making sure their confidence matches reality.

In short, the best way to get practitioners to the next level is to make sure they don’t fall three levels back.

2. The Learners

The second group has the opposite problem.

They know a surprising amount about AI.

They attend workshops, read newsletters, follow every product launch, and can explain hallucinations, context windows, and the basics of prompt engineering. But when you ask what they actually used AI for this week, the answer is often: not much.

Their pendulum is stuck on stuck on the Understand side. Mostly because they’re aware of all the problems that this technology brings. A little too aware.

The problem is that more understanding does not automatically create more confidence. More theory can make the problem worse, because it gives them a more sophisticated reason to wait.

These employees don't need more "inputs".

They need opportunities to experiment safely.

Give them learning labs with real tasks from their daily work – not generic exercises.

Let them summarize customer interviews, draft proposals, analyze meeting notes, or prepare presentations. Then have them compare the AI output with reality. Provide guidance or coaching from Practitioners if the work context fits. Actually, these two groups can highly benefit from each other.

Confidence doesn't grow from hearing that AI works. It grows from seeing where it works – and where it doesn't.

When someone discovers that AI produces an excellent first draft but still needs human judgment on pricing, positioning, or risk, they've learned something much more valuable than another list of prompting tips.

Their pendulum needs to swing toward application.

3. The Disengaged

The third group simply hasn't engaged.

I don’t have a quotable figure, but in practice the number of people here appears to be still quite large.

They don't sign up for AI training. They’re not interested in AI developments. They may have tried ChatGPT once or twice but never integrated it into their work.

Their pendulum simply does not move.

And that is an entirely different training problem. Because if someone’s not interested in something it’s very hard to “convince” them using classical training paths or by telling them that AI is IMPORTANT! (They’ve already heard that a thousand times.)

What this group needs is a practical impulse.

What usually works is seeing someone they trust solve a real problem they can relate to.

An internal use case demonstrated by a colleague is often more persuasive than the most polished vendor demo. The use case itself doesn't even have to be spectacular. It just has to feel relevant.

Once it clicks, people can start experimenting or watch training materials. Either path is fine.

The important part is that their pendulum got moving.

Designing Better AI Training

Before launching another organization-wide AI upskilling initiative, ask 3 questions.

Who is already using AI every day?
Give them better judgment, verification habits, and a deeper understanding of AI's strengths and limitations.

Who keeps learning without applying?
Offer structured opportunities to safely experiment on real work in sandboxed environments.

Who hasn't meaningfully started?
Show relatable examples from colleagues doing work they recognize.

Don’t assume these groups need the same intervention. They don't.

The Goal Isn't AI Literacy

AI upskilling isn't about moving everyone through Bloom's Taxonomy anymore.

The goal is to create good judgment.

You want a workforce that is motivated to use AI where it makes sense, knows when to trust its output, and recognizes when verification is needed.

In other words: confident enough to use AI, but skeptical enough to check.

That's confidence calibration.

And the next time someone asks me what modern AI upskilling should look like, that's the answer I'll give.

See you next Saturday,
Tobias

Earlier this week, I gave my regular Quarterly AI Briefing for clients. This time, we covered 8 topics in ~45 minutes – the things that happened that I found newsworthy enough to matter for your business.

As usual, there was a lot of noise. But this quarter, there was also (unusually) a lot of signal. We saw the first major frontier model get banned. The first real budget bursts. And clear signs that “agentic AI” is moving from conference slides into core business systems.

Today, I’d like to pull a few highlights from that briefing – the three things I’d pay closest attention to if you run AI in a business.

Let’s dive in!

Q2 in 1 Minute

Here are the eight topics that made it into the briefing

1. The Mythos Ban: the US government switched off the world's most capable AI model on a Friday afternoon

2. The Anthropic Quarter: now past OpenAI, and the industry's new talent magnet

3. The Agent Quarter: every big tech conference converged on one single message

4. The Agentic Ecosystem: Big names are opening up for agentic AI

5. The ROI Reality: bills arrived, but value didn’t (shocker)

6. The Governance Gap: agents run in production, but the cockpit’s still missing

7. The Layoff Illusion: "We replaced people with AI" stopped impressing the stock market

8. Outlook: GPT-5.6 is ready, and guess who decides whether it ships

Let’s zoom in on three of these:

1. The Mythos Ban

Back in April, Anthropic announced Project Glasswing. Their unreleased Mythos model scanned critical software for security flaws, available only to a handful of partners. It found over 10,000 high or critical vulnerabilities in the world's most important software.

So Anthropic decided to hold the model back (“Too dangerous to release”). Keep it private, work with trusted partners, and ship a safer version later.

That safer version eventually became Fable 5, released in June.

And this is where things started to get kafkaesque.

On June 10, Dario Amodei published an essay “Policy on the AI Exponential” where he literally wrote:

Two days later, on a Friday afternoon, the US Commerce Department issued export controls on Mythos and Fable 5. Anthropic’s best AI model effectively became unavailable worldwide across all platforms within a few hours. 

Be careful what you wish for.

The interesting nuance here is that the US government didn’t ban Anthropic’s model per se. It just restricted access to non-US citizens (which effectively led to Anthropic taking the model down because how would you ever control who is a US citizen or not?)

To be clear, this was a precedent situation which many have kind of predicted, but no one saw it coming that fast.

A few days ago, the export controls were lifted and Fable 5 came back globally on July 1.

Except it didn't.

The developer platform BridgeMind re-ran their coding benchmark on the restored model. Debugging performance dropped by almost 70%. Refactoring by nearly 50%. The new safety classifiers reroute anything that smells like security work to the older Opus model, and they trigger on routine tasks.

Image source: Wes Roth via X

If this quarter has shown one thing then it’s that Sovereign AI stopped being a buzzword and became a hard requirement for enterprises running critical workflows with AI.

I believe the consequence is not that every company should now go out and buy their own GPU racks. But you should be able to answer the following question:

For chat and productivity tools, switching is annoying but doable. For the workflows embedded deep in your operations, swappable models or version-fixed open source models are now table stakes. I've written about the how in Build AI Fast, Then Own It Smart.

2. The Agent Quarter

Q2 was also conference season. We saw Anthropic’s Code with Claude, Google I/O, Microsoft Build, and NVIDIA GTC Taiwan. Hundreds of announcements that condense into one sentence, and I think Satya Nadella said it most clearly:

The receipts:

• Google made AI Mode the default search experience worldwide and put Gemini Spark to work as a 24/7 agent inside Gmail.

• Microsoft shipped Agent Framework 1.0, a native runtime for agents on Windows, and repositioned Copilot from pair programmer to peer programmer.

• Anthropic introduced Managed Agents: you define the outcome, their servers run the agents, even overnight. They call it “decoupling the brain from the hands.”

• And NVIDIA expects $1 trillion in compute demand through 2027, already sold out on GPUs.

Microsoft finally embracing the term “Autopilots” as well.

What this gave us is consumer, enterprise, and infrastructure all betting on the same thesis: we’re moving full-steam into the era of agentic AI.

Now here's the slide none of the keynotes showed: what happens when AI agents actually run the real world for a longer period of time.

Two interesting experiments from this quarter:

1. Researchers put Google's Gemini in charge of a real café in Stockholm. The first days looked great, but then it lost $6,000 by handing out 99% discounts and hosting lavish events.

2. Another group of researchers set up five virtual societies of ten AI agents each and let them run for 15 days – no governance or oversight. Results: Grok's society went extinct in 4 days. Gemini committed 683 crimes. GPT-5 agents failed to take basic survival actions. And Claude sat down and wrote constitutions, until bad actors convinced it to go rogue. This one hit a nerve. The LinkedIn post quickly accumulated 100,000+ views and many comments of people sharing similar experiences in non-simulated environments:

Researchers had AI models simulate a society and run it for days.

Result:
- In Grok’s world everyone died after ~4 days
- Gemini committed 683 crimes
- Claude spent its time writing constitutions (until it met bad actors that convinced it to go rogue)
Read more…

LinkedIn - Tobias Zwingmann

What I wanted to show with this post is AI benchmarks typically evaluate one-off tasks: “Do this job, I'll check the result." But production is different. Deployed agents make repeated decisions, react to feedback, face manipulation, and pursue a goal over a long horizon. That's where small mistakes compound into drift nobody designed for.

So yes, the direction is set, whether we like it or not. But there's a whole staircase between an assistant and an autonomous agent, and I still prefer the middle step: when the workflow is known, an Autopilot built in n8n beats a fancy AI agent. And where agents do go live, governance belongs in the design from day one, with performance watched all the time. Not just the first week after go-live.

3. The ROI Reality

One story made the rounds this quarter: a company that reportedly spent $500 million in a single month on Claude tokens. Because nobody set usage limits.

I couldn't verify it because there’s no named company, and no source. But it fits what I see in consulting work: companies spend first and measure second.

The verified stories are telling enough:

• Microsoft canceled internal Claude Code licenses over costs.

• Uber burned through its entire 2026 token budget in four months.

• ServiceNow reported the same.

And what’s actually worse than spending is that none of them can actually draw a clear line from spend to gains. More tokens does not mean more productivity. (Picture employees using AI to check the weather every day.)

This is nothing new: Automating a task is not the same as creating value. What typically gets automated is the work people dislike, not the work that matters. The agent layer is cheap to buy and expensive to run, and the vendors above are making the buying part easier every quarter. The value part stays your job.

Which brings back the two questions I ask before any engineered AI use case:

1. What's the minimum value this needs to deliver?

2. What's the maximum I'll spend to find out?

If a use case can't answer both, it's a use case without a case. Kill it, no bonus points for running the most agents.

Surging AI costs are a control problem more than a cost problem. You can switch a workflow off. If you designed it so you can. (See my Cost Cap Model)

Looking Ahead

OpenAI just announced GPT-5.6 a few days ago – and guess who they asked first before they shipped it? Right. We’re still waiting on general approval. Until then, only a “selected group of partners” have access.

I guess the old times where frontier AI labs can’t ship new models fast enough are over. We’ll see.

I’ll report back in Q3.

Until then…

See you next Saturday!
Tobias

8 Topics

1. The Mythos Launch and Ban

2. The Anthropic Quarter

3. The Agent Quarter

4. The Agentic Ecosystem

5. The ROI Reality

6. The Governance Gap

7. The Layoff Illusion

8. The Outlook

"Finding good AI opportunities" used to be treated as quarter-long projects.

I've been there too: innovation workshops, planning meetings, prep sessions. A quarter later you're sitting on a pile of "opportunities," unclear what to do next. So you build a matrix, score everything, and another quarter later still nothing has been decided.

Guess what – that whole timeline just collapsed.

Last week I ran a live workshop to demo something I couldn't have done a year ago: sitting down with a specialized AI Copilot I trained on my own methodology, and walking it through a real business to surface at least one profitable AI opportunity – live, on the call, in under an hour.

By the end, the Copilot and I had found a $30,000-a-year opportunity. In about 40 minutes.

Want to see how we got there?

Let's dive in!

Context

The company I picked was from an industry I know too well – trade shows, exhibitions, and events (yes, that's a whole industry!). An exhibition organizer, ~500 employees, running about 20 trade shows a year. I put myself in the shoes of the Director of Exhibitor Support.

We started with two basic assumptions:

1. Every opportunity we find must be at least worth $10K per year (that’s the lowest 10K Threshold – below that you’re in productivity land looking for prompts, not building AI systems)

2. We’d look for opportunities in our area of responsibility. So the main bucket became “AI in Customer Service”. A quick check revealed that with 5 people on the support team, this would easily clear our value threshold 5-10x. More than enough room to work with.

Now, most workshops would have started here with a process mapping.

But we didn’t.

And I’ll be brief, because I wrote about the reason why last week in Outcome-Driven AI Discovery.

Stop mapping how the work is done

The instinct here is to document the current process. How do support emails get handled today? Map the steps, then sprinkle AI on each one.

This works — and that's the problem. You get a dozen tidy "quick wins" that each save a few percent and quietly anchor every idea to the way you already operate. But your current operating model is often the very thing holding AI back.

So instead of asking what happens here, we asked what is this part of the business supposed to produce?

The answer wasn't a process, but an outcome: Exhibitor request resolved.

Here's where the Copilot came into play. I handed it that one outcome, and it broke it down into 5–8 sub-outcomes for us to review – the kind of decomposition that normally takes a room full of people and a whiteboard:

Filter by "what would I pay for this", not "what can AI do"

With that map of outcomes, the Copilot extracted the current and future problems tied to each outcome from us – a.k.a. the pain points and bottlenecks. Not all of them are AI-shaped, so it also mapped my AI Skills framework against each problem, flagging which ones are actually a good fit for AI and how.

And that reveals the real issue: these days, AI can seemingly do everything. That abundance is exactly what paralyzes people. So we need a filter – the $10K Threshold from up top.

It’s one step where the Copilot can’t help us because this one relies on our own judgement.

For each AI solution in front of us, we ask:

There could be 4 possible answers:

• No, I’d never pay $10K for this

• Hmm, maybe $10K, it depends

• Sure, $10K for this sounds like a good deal

• “Shut up and take my money where do I need to sign!”

This tells us whether a solution cleared the Threshold.

Set the cost before you know the solution

A few clustering steps later (again, the Copilot did the grunt work) we ended up with a handful of ideas, each one a collection of similar AI capabilities aimed at related, prioritized problems.

And this is where most discovery sessions go painfully wrong.

Say you land on something like the Email Reply Copilot – an AI that drafts source-backed replies inside people's inboxes.

The wrong question is: how much does this cost? Because the same solution could run anywhere from $50 a month to $15,000+, depending on how you build it and what you want it to do exactly.

So the better move is to ask two different questions:

1. If I had this solution, what value would I expect from it?

2. How much would I be willing to spend to get that value?

This is the shift most leaders have never been shown — and it's the one that matters most. You declare the value first, and let that define the ceiling.

An Email Reply Copilot might save the team ~1,000 working hours a year, call it a rough €50,000 in value. If that's your top estimate, you'd be insane to spend anywhere near it. The cost has to be a fraction. So you cap it at, say, $10,000 a year – and that becomes the basis for scoping the idea.

For our case, the Copilot followed exactly this logic and produced two fundable bets:

The Exhibitor Reply Copilot — source-backed replies in people’s inbox.

• Worth at least $30K a year

• So: running costs capped at $12K/year, and a build budget of $9K.

The Policy Knowledge Copilot – relevant document or previous case suggestions for complex requests

• Worth around $20K a year

• So: costs capped at $8K/year, build budget $6K.

In AI, following this discipline isn’t optional. Unlike classical IT projects, AI costs don't spike at the beginning and stay relatively flat over time – AI costs climb as the system scales and also forces recurring quality checks and validations. If you can't name the recurring value on day one, you won’t have a case for keeping the project alive.

Now, none of this is new. But having AI guide you through this process is just 10x faster (and also more fun). It allows you to cut through the hype and surface ideas that really matter.

Result

So in about half an hour, a vague "let's do AI in support" became two specific bets, each with a number, a clear ceiling, and a clear value hypothesis.

But of course, this is still an idea, not a solution.

The worst move now is to run off and build it. At this stage the idea still has a real chance of being wrong. (Maybe a Copilot-type solution isn't even the right fit here, and the cost cap might not be even realistic.) We need another step to find out.

From AI idea to production

I call this next step a “Solution Concept” – a short document that spells out exactly:

• What problem we’re trying to solve

• How value is generated, who benefits

• What kind of solution we're targeting

• Technical and data requirements

• A first business-case estimate

• The recommended next phase (e.g., prototype or roadmap)

And guess what — there's a Copilot for that one too.

But that's a story for another day.

If you'd like to take (or find) an AI idea for your business and take it through the exact same process using the Copilot helpers above, check out my Profitable AI Pass which is open until July 5.

You'll get the Opportunity Scan and Solution-Concept session, both AI Copilots, a personal review of your concept, and a recommended build sequence (I'll record a 20-minute walkthrough). Plus, access to my full workshop library and every upcoming live event until the end of this year.

More details here.

See you next Saturday,
Tobias

Bring the idea you found in the Profitable AI Workshop.

We’ll turn it into something concrete enough to evaluate, discuss, and build.

I’ll walk you through the same AI Solution Concept template I use in my consulting practice to turn AI ideas into clear solution concepts.

Not a giant strategy deck and no tech specs (yet).

Just a simple working document that helps you say:

“This is the problem, this is how we plan solve it, that’s the value, and here’s what needs to be done next.”

Agenda

Part 1: What is an AI Solution Concept – and why do you need one?

• Why AI ideas often fall apart after the first brainstorm

• The difference between an AI idea and an AI solution concept

• Key dimensions that need to be addressed

• where this fits in the roadmap

Part 2: Walkthrough of my AI Solution Concept Template — 45 min

This is the main part of the workshop.

Bring your AI idea from the Profitable AI Workshop, and follow along as I walk you through the template section by section.

• what problem the solution solves exactly

• who the solution is for

• how value will be generated

• what the desired outcome should be

• what role AI should play

• what type of solution this is

• what data and inputs are required

• whether this is ready to build

• or whether it should be split into smaller steps first

By the end, you’ll have a much clearer view of what your AI idea actually is – and what’s needed to make it real.

You’ll leave with:

1. Your own AI Solution Concept started or completed

2. The template I use to shape AI projects in my consulting work

3. An AI helper that supports you while filling it out

4. A clearer answer to what should be built, what should wait, and what needs to be broken down first

This is for you if:

• You joined the Profitable AI Workshop and want to take your idea further

• You have an AI idea but don’t know what it should look like as a solution

• You want a simple way to decide whether an AI idea is worth building

• You want to move from AI inspiration to something more concrete

Resources

• Profitable AI Scan Miro Board | Profitable AI Scan Copilot
  (To use the board, create a free Miro account and select Board → Duplicate)

Special Offer:

• Save €500 on the Profitable AI Pass to turn your AI idea into a validated solution concept and get a practical implementation roadmap.
  Valid until Thursday)

I changed my way of finding AI opportunities.

It used to be a "document how things are done, identify problems, map AI solutions" kind of way.

The problem with this approach is that it works.

It will consistently generate a list of AI opportunities that you can implement immediately as "quick wins." You will find so many of them that you can stay busy chasing quick wins forever. And by doing that, you’ll lose track of the bigger opportunity.

If your ambition level is higher than "let’s squeeze out 10%," this approach becomes too limiting, because it anchors the problem space in today’s operating model.

And very often, that operating model is the biggest bottleneck for AI.

So I started to map AI opportunities using a system that is less step-based and more outcome-based.

Today, I’d like to share what this system is, how it works, and what benefits it brings.

Let's dive in.

Step-Based Mapping

Before we get into outcome-driven thinking, let’s revisit the “old” way to help us understand what this shift is really about.

Imagine someone comes to you and says:

(Guess I’ve seen this before)

A typical way to approach this would be to create a process map. You would start by asking:

“How does customer support work for you today?”

And then you map it out.

The process map might look similar to this:

Customer emails land in a shared inbox → someone assigns them → categorizes them → replies if possible → escalates if needed → gathers context → internal back and forth → issue resolution.

Once you map this, the AI ideas are obvious:

• classify emails

• flag urgent issues

• suggest escalation contacts,

• remind people to follow up

• draft responses

• etc.

To be clear, none of this is bad. Many of them will result in relatively straightforward use cases, especially with features that already exist in tools like Outlook, Gmail, Zendesk, or whatever system the team is using.

The catch is that these improvements are incremental. (About 15% in the case of customer support). They won’t create the kind of AI impact that makes people say: “This completely changed how we serve our customers.”

So how could we think about this differently?

As Michael Hammer used to say: Obliterate, don’t automate.

Let’s take a look at the outcome-based approach.

Outcome-Based Mapping

The key shift is to stop looking at the system only from the bottom up, and start looking at it from the top down.

We don’t ask:

We ask:

And the answer to that question is usually not a process.

It is an outcome.

In the customer support example, the top-level outcome could be something like:

"Happy customers."

Or, more technically:

Resolved customer issues that lead to improved customer satisfaction and higher customer retention.

Of course, no single AI system simply creates happy customers. But the point is that “happy customers” gives us the direction. It helps us understand what this part of the business is actually supposed to produce.

And then we can break it down into several smaller sub-outcomes such as:

• Multi-touchpoint intake

• Customer intent recognition

• Required context gathering

• Priority and urgency definition

• Support level determination

• Response formulation

• Customer reply

Now, just by describing it this way, you can hopefully see how the thinking starts to shift.

We are no longer just looking at the existing steps. We are looking at the outcomes that need to be produced.

Benefits

I’ve found that there are a couple of major benefits to this approach:

Bigger opportunities: Outcomes allow you to ask much larger questions. You’re faster in “Engineered AI” territory with clear ROI impact.

Better measurement: Quantifying the value of an outcome is easier than the value of a single task, because you can ask: “What are we paying for this outcome today, and what are we willing to pay for it tomorrow?”

Better prioritization: You can optimize for the gap between “What is this outcome worth?” and “What are we paying to achieve this outcome today?”

Clearer ownership: Outcomes usually already have an owner in the organization which makes it easier to assign the core accountability for the AI initiative.

Better cross-functional thinking: Delivering high-level outcomes often cut across teams. That helps reveal opportunities that would be easy to miss in department-level process maps, because most potential often sits between functions, not in one team.

Outcomes vs. Outputs

Not everything that looks like an outcome is actually an outcome. Many things are just outputs. The main difference is value capture.

Take a spreadsheet with names and contact data, for example:

Is this an output or an outcome?

Without any context, the list doesn’t tell you much, other than that some process probably generated it. No one would pay for this. But if this list contains everyone who downloaded a specific white paper, then the situation changes. Because suddenly that “list of names and contact data” becomes a “lead list.” The valuable thing is not the list itself, but the fact that it is the artifact of a process that grabbed people’s attention, filtered by interest, and made them complete a certain action – a.k.a. a lead generation process.

AI can produce a ton of outputs without creating a single outcome.

So make sure you don’t mix up the two.

Here is how outputs and outcomes compare:

The easiest way to separate outputs from outcomes is to simply ask:

If the answer is "not much," you are probably looking at an output.

If the answer closer to “take my money”, you are probably closer to an outcome.

How This Works in Practice

The steps for Outcome-Driven AI Mapping are actually very similar to the traditional approach I described in my book.

It’s just a different lens you’re looking through:

1. Set your minimal value gate: the 10K Threshold

2. Define a relevant part of your business to look at

3. Identify the main outcome or outcomes of this part

4. Write down the sub-outcomes needed to achieve them

5. Collect pain points and bottlenecks around these sub-outcomes

6. Map AI capabilities to the sub-outcomes, pain points, and bottlenecks

7. Filter by the 10K Threshold

8. Consolidate your AI ideas

So that’s how I currently think about it.

Outcome-based mapping is not a completely different process.

It is the same discipline, but with – in my opinion – a better starting point: not “How can AI improve what we do?”, but “How can AI help us achieve outcomes better, faster, or cheaper?”

Sometimes the best AI opportunity is to accelerate a step.

But sometimes the best AI opportunity is to remove steps entirely, combine several steps into one, or reorganize the work around the outcome you actually want to create.

This little distinction makes all the difference.

See you next Saturday,
Tobias

A few weeks ago I wrapped up another sprint with a company in the ~500+ employees range (can’t disclose details due to NDA).

What I can share though is the big lesson I learned.

I realized that 1 concrete AI opportunity can beat a map of 7 clusters worth $1M.

Finding AI ideas is no longer the hard part.

Figuring out the right starting point is.

But let’s start at the beginning.

How it started

I came in with the goal to get an AI opportunity map for the organization. See where the AI profit pockets are. It’s a classic deliverable for me, so four weeks later, they had it.

We ran a week of AI Opportunity Mapping workshop where the goal was not to see "where can we use AI", but "where does this business have real pain points or bottlenecks," and then, "which of these are actually solvable with AI."

That surfaced around 350 problems out of which 270 looked like a good fit for AI support.

What people often get wrong about these kinds of workshops is that they are less about brainstorming and more of a selection exercise.

Example AI Opportunity Map

Having a long list of AI ideas isn't an asset any more (has it ever been?). Anyone can produce 270 "AI use cases" in an afternoon with ChatGPT. But figuring out which ones are actually worth doing is the hard part.

Do the test yourself: Of all the AI ideas floating around your team right now, how many have an actual number attached? Which one is clearly the best?

More options aren’t always better. On the contrary, more opportunities cost you more. More attention. More alignment. More overhead.

In short: more work.

So we consolidated the 270 by doing three things:

• Filter by value. Which ones survive the $10K threshold? This exercise alone brought us down to ~110.

• Skip the org chart. Most ideas are really just repeated expressions of the same phenomenon or underlying problem. "We need better insights for marketing" and "our onboarding funnel leaks users" aren’t two use cases. They’re essentially the same ask for actionable insights.

• Stop calling it "use cases". At least on a high-level. What you want to leave with is a portfolio of opportunities. Sometimes I call these "case packages", sometimes "opportunity clusters", sometimes just "projects". What matters is that discussions stay focused on outcomes, not "what LLM works best for this" at this point.

In our case, we ended up with 7 clusters that together had $1M+ a year in untapped potential.

A clean map with a real number.

And that's where it got hard.

The problem with a good map

A good map shows you the opportunity but it does not automatically create ownership.

These 7 clusters we identified weren't "put an FAQ chatbot on the website" types.

They were things nobody walked in asking for. One of them: use AI coding to accelerate in-house development capabilities. This opportunity alone touches so many things. That sounds fine until someone has to fund it. Seven clusters means (at least) seven business cases, seven owners, and seven budget discussions. Who owns a cluster that spans three departments?

My usual instinct in those cases is to bundle the opportunity portfolio, bring it to the executive team, and ask for sponsorship from the top.

Sometimes, this is exactly what’s needed. But it also creates a risk: The discussion becomes bigger. The stakes become bigger. And the timeline becomes longer.

The company can end up debating the roadmap instead of building the first profitable thing.

Last time I checked, the budget discussion was still going on.

The first step

Having a good map is never wrong. But the way you present it matters even more.

Instead of asking:

“Here are 7 major AI opportunities. Which ones do we want to fund?”

I should have said:

“Here is the full opportunity map. And here is the one opportunity we should start with.”

That distinction matters a lot because a map creates confidence, but it does note give you momentum. Working on a First AI project does.

A roadmap tells you the staircase is there. A first opportunity gets your foot on the first step.

And in AI, that first opportunity should meet a few conditions:

1. It should be valuable enough to matter. Don’t necessarily chase the biggest opportunity on the map, but big enough that success gets actually noticed.

2. It should be narrow enough to ship. If the first iteration requires three VPs, ten approvals, and a 6-month data platform evaluation project, it is probably not the first step.

3. It should have a clear owner. Someone must be able to say: “This is mine and I’m standing up for it.” Not “this is strategically relevant to our function.” Someone with budget authority.

4. It should be close to production. The goal is not to impress people in a demo but to improve the way work gets done. If you can’t see an implementation roadmap clearly for whatever reason, it is a bad first step.

5. It should compound. A good first AI opportunity is not just a “quick win”. Quick wins give you something once. But a compounding step gives you a new asset – a capability, workflow, or operating muscle that makes the next step easier.

A well-executed opportunity that hits these criteria beats a roadmap slide every time.

What’s next

The bottom line is this:

You don’t always need to see the whole staircase before you take the first step. You just need to know the staircase is there.

That is what the map is for. It shows you whether there is something worth climbing toward. But once you know the staircase is real, staring at the whole thing for too long can become its own problem. It can make the opportunity feel too big, too political, and too hard to start. That’s how companies get paralyzed. “Let’s align everyone first and revisit next quarter.”

In staircase terms:

“Let’s wait until someone builds an elevator.”

(Which likely never happens.)

So pick a single opportunity that offers more than an isolated quick win, let it become the step into the next. Repeat.

Often, you don't need more options. You need fewer.

Because one profitable AI solution you actually ship beats a $1M roadmap you never touch.

Now go find yours.

See you next Saturday,
Tobias

Earlier this year, I met a CTO of a large firm during a conference. She told me:

"I’m building again – for the first time in years!"

For decades, her job was to delegate. And if you followed the classical script, the AI opportunity for her would be to delegate even more. But instead, AI pulled her back into the work.

Is that the future? Nobody knows. Everyone's still trying to figure it out. There's no proven "AI transformation blueprint" yet. But one thing is getting clear: the organization of tomorrow is not the organization of today with AI sprinkled on top.

I'm not going to argue that AI makes people more productive. It does, to a degree – but that's the boring part.

I'm going to argue that true AI transformation means changing the unit of organization itself.

Let’s start with what almost everyone gets wrong.

Speed is a local maximum

The default reaction to AI adoption in an organization is to accelerate what's already there. Give me faster emails, faster decks, faster code, faster reports.

But the org chart stays the same. The meetings stay the same. The workflows stay the same. People produce the same artifacts – just faster.

That's useful. But it's a local maximum. You made the horse faster, but you never built the teleporter.

It doesn’t have to be that way. I recently shared how I use AI to manage 50,000+ emails per year – not by writing emails faster, but by rethinking how I approach email in the first place.

To see why that changes the org, and not just your to-do list, it helps to borrow a 60-year-old idea.

Drucker, and why the layers thin

A lot of what’s considered “good management and business practice” goes back to Peter Drucker, who (among many other things) argued that "every knowledge worker is an executive" – judged on effectiveness (doing the right things), not efficiency (doing things right).

And to separate one from the other, we hired workers to do the job and managers to coordinate them and keep them pointed at the right things.

But here’s what AI changes about that equation.

For many forms of cognitive work, execution is becoming less of a labor problem. AI does not do the thing for free. But more of the cost moves from payroll to compute, and from fixed headcount to a variable bill you pay per outcome.

Coordination costs likely also compress. Coordination exists because work is split across people and functions. If AI allows more of that loop to collapse into one owner or one small pod, then less coordination is required per unit of output.

That price tag is the whole point. When more units of execution can be bought with compute, the question shifts from “can we do this?” to “is this outcome worth running?”

And that’s a judgment problem.

That’s why in a world where execution is abundant and coordination is cheap, judgment becomes the scarce resource.

• What should you be doing at all?

• Which outcomes are worth achieving?

This doesn’t mean workers and managers vanish. It means the execution and management required per unit of output collapse in many domains. What survives aren’t the tasks and structures – what survives are the outcomes.

If outcomes are the thing worth owning, then the basic building block of the company changes.

And that's the real shift.

The new building block

The building block moves from workers executing tasks to individuals or small teams owning outcomes.

What does this mean concretely?

Here’s where I believe most people go wrong: they picture one person supervising a swarm of agents. But you don't manage agents. You own an outcome and use AI where it fits as a tool to achieve it.

And there’s far more to this than that. You still need human teams. AI-mature organizations are already working today in small pods – teams of 2–4 people that share one loop, one outcome, without any handoff.

The deeper shift is not that one person replaces everyone else. It is that AI expands the span of ownership a person or small pod can economically sustain.

Historically, one person wrote the spec, another built the prototype, another analyzed the data, another created the deck, another coordinated adoption. AI does not remove expertise from that system, but it can let one accountable owner internalize more of the work that previously required coordination across specialists.

When execution becomes cheaper and judgment becomes more important, that judgment shows up in three faces:

1. Builders — who decide what to create in the first place and are able to get a scrappy first version into the world. Their goal is to figure out what’s worth making, fast.

2. Operators — who make things safe, scalable, and reliable. They define what’s good enough to trust at scale.

3. Communicators — who create alignment, direction, and above all trust, so whatever builders and operators pump out actually gets adopted by the organization. You could call them politicians, in the most literal sense of the word.

Importantly, these are lenses, not roles or titles. Today's Builder is tomorrow's Communicator. Every pod needs all three to ship an outcome. One shared loop.

How to make this happen

Practically, what does this mean for you? I see four big levers:

1. Stop assigning tasks and start assigning outcomes. For each outcome, define what "done" looks like. Leave the how to the owner, but have them document it rigorously.

2. Keep pods small. 2–4 people, one shared loop, no unnecessary handoffs.

3. Staff for the three faces, not for departments. Make sure every outcome has a Builder, an Operator, and a Communicator covered, and let people flow between them.

4. Couple them loosely. A pod that owns a whole outcome has nothing to stitch inside it. Between pods, coordinate through clean interfaces, not meetings. The way Amazon runs thousands of two-pizza teams. The more independent your outcomes, the flatter coordination stays as pods multiply.

Do this, and the execution and management required per unit of output collapse. Judgment is the key job now.

Here’s how this could look in practice:

Imagine a music streaming app.

A classical functional organization might look like this:

Music App
├── Backend Team
├── Frontend Team
├── Mobile Team
├── Data Team
└── QA Team

An outcome-based model could look like this:

Music App
├── Activate users
├── Retain users
├── Grow artists
└── Grow ad revenue

Each team owns a business result — and decides how to get there.

Naturally, this model will not apply everywhere equally. It is strongest in digital work with fast feedback loops.

But also more classical industries like finance, manufacturing, and other operationally complex businesses may evolve differently under that premise. Even here, AI can still expand ownership, while making sure the coordination around safety, compliance, capital, and physical execution will stay intact.

In the end, the same principle applies to every industry:

AI allows smaller groups to own larger outcomes end to end.

The question is:

How will your organization leverage this best?

The early signals

Again, we’re far away from claiming any “best practices”. But there are some early signals that point to the direction above.

Palantir

Palantir may be the closest to this operating model. CEO Alex Karp said he avoids a rigid org chart and runs unusually flat, with 13 people reporting to him directly, on what the company calls a "mission-driven culture" – aka outcomes.

Source: The Information

Anthropic & OpenAI

The big AI labs use a "Member of Technical Staff" title across the technical org – which is quite unusual, since the corporate tech ladder normally means climbing through tech leads, staff engineers, and so on.

The point isn't "no hierarchy." It's less emphasis on managing people, more on owning outcomes, and grouping pods around them as necessary.

This seems to resonate with top talent as well. AI superstar Andrej Karpathy joined Anthropic's pre-training team in May 2026 to "get back to R&D". Six Silicon-Valley CTOs joined Anthropic as Members of Technical Staff to start shipping again.

Image source: Levels.fyi

So what

The AI-native company isn't where everyone uses ChatGPT.

It's one rebuilt around a new assumption: execution is abundant, coordination is cheap, and judgment is scarce.

And when judgment is the bottleneck, you organize around the people who supply it – owners of outcomes, not doers of tasks.

The CTO building again wasn't a nerdy detour. She was getting back to the only thing that stayed scarce — her judgment to own an outcome end to end, and her ability to pick the most efficient way to make it happen.

See you next Saturday,
Tobias

I get between 80 and 150 emails a day.

These emails live in six different inboxes across business, personal, and partnership accounts. Most messages don't really matter. Some matter a lot. Like a client request, an inbound lead, or just a notification about a failed payment because the credit card expired.

And the effort to keep on top of everything keeps climbing.

Because it's one thing to separate important from unimportant (I've been doing this automatically for a while). But really keeping track, are items pending, done, do I need to follow up, is a whole different challenge.

And for the longest time, building and maintaining an AI system for this simply wasn't worth the effort (because in the end, it's still a productivity use case for me). Until now. Because a) the tech got better and b) I changed the way I think about this use case.

Today, I want to share this with you.

Let's dive in!

How I thought about it

The obvious move for solving my email overload was Gemini for Google Workspace, because my main account lives on Gmail. But two problems quickly disqualified this idea:

First, Gemini only covered one of my six inboxes.

And second, on that one inbox it was pretty underwhelming, because I couldn't really customize it to how I work.

Ok, I thought. Fine. I'll build it myself. I'd built dozens of email classification systems before, so why not just extend what I have and plug different workflows together.

But the "stitching a few workflows together" part quickly turned out to be harder than I thought.

Solving my email problems wasn't just about "is this important." I needed to know whether a message had been answered. Whether I'd replied, or pinged someone else, or I was still waiting on a reply I'd asked for. Tracking who owes whom across a thread with five people in it.

I wasn't looking at a pure classification problem anymore. I was looking at a management problem.

The obvious version for tackling this is "reasoning over my inbox". Hand an AI agent my IMAP logins and let it run the whole thing. Read, sort, reply, send, delete.

It's also the last thing I would ever do.

Because when the agent fires off a bad reply to a client, the damage is done. Or when it deletes the wrong thread, I wouldn't notice. Email is far too important for me to just hand it off to a black-box AI system I don't supervise.

So I was stuck with two things that didn't fit. The problem screamed agentic AI. And I refused to let an agent loose on my live inboxes.

What changed

Two things flipped this for me.

First, the technical capabilities. Out-of-the-box ChatGPT and Claude were simple chatbots 6 months ago. Today, they're extremely capable agentic systems (or at least can be used like this if you know how). Especially Claude Code feels less like a simple chatbot these days and more like an orchestrator, where the LLM really just controls a bunch of non-AI tools, such as using a grep-search to find relevant information across my files. (There's a good breakdown here on what Claude does behind the scenes – a lot isn’t actually AI.)

What an agentic system like Claude is actually doing under the hood
(adapted from VILA-Lab)

Second, non-AI was really the missing piece. In order to give an agentic system like Claude Code access to my inbox, I had to replicate my inbox (or inboxes) into a "sandbox", a safe space that the agent has full access to.

And for this replication I didn't need AI. I needed a simple, stupid workflow on a platform I've been using anyway for a long time. In my case, that's n8n.

How I think about this now

So I split the job into two.

Part 1 became the data layer. n8n fetches my emails from the different providers and brings them into a shared table. In there, context is built. Thread, recipients, outbound, inbound, etc. There's also a little script that ignores all emails with an "Unsubscribe" in it. Emails from mailing lists didn't have to be managed and were not worth AI tokens.

This context-rich, high quality dataset was the basis for the agentic system on top. (If you wonder what "you need high data quality for high-performing AI systems" means, this is it.)

Part 2 was the agent. I picked Claude because I already had a subscription and it's in my opinion the best agentic platform right now. But the same thing could be done with Codex or ChatGPT.

All I had to do now was write the main system instructions in a CLAUDE.md file and define some tools, like fetching emails or updating status, that would be served by n8n.

The agent never works on anything other than the sandboxed table. It reads it, makes notes, keeps a log, drafts a reply when I ask. It cannot delete anything from my real mailbox. It cannot send. Those actions aren't within its reach.

That's the whole trick. Give an agentic system a clean dataset with all the context, then give it room to figure things out, inside a box where it can't break anything.

Capability and blast radius are two separate dials. Most setups turn them with one knob: more power means more access. They don't have to move together. I want my agent maximally free to reason and maximally unable to destroy.

So the question for every part of the system isn't "can AI do this." It's "should this part be AI at all." Fetching mail: no. Structuring it: no. Deciding what matters today and why: yes. Sending: never.

The payoff is mostly time. Sorting that used to eat an hour a day now takes ten minutes. I wouldn't pay $10K for this system every year. But I also wouldn't want to be without it.

The whole thing now runs on my laptop as my personal AI Mailroom – with no new subscriptions stacked on top. Every morning I type /organize and /brief to know what's up. Whenever I'm overwhelmed I type /prio and Claude tells me the top 3 things to do now. Every now and then I type /follow-up to check if there are some open loops to close. Claude gives me a draft that I just need to copy and send.

My AI Mailroom in action

Three design choices carry the system

1. Separate the context layer from the reasoning layer. Cheap deterministic code builds the dataset. The expensive, fallible part only ever sees a clean copy.

2. Give the agent a scratchpad. Notes and a running log are what let it reason across threads instead of judging each email cold. Memory makes all the difference between classification and management.

3. Hard-code what it can't touch. Not "please don't send." Cannot send. The boundary lives in the structure, not in an instruction the model might decide to ignore.

Before you point AI at a messy, important system, split the work in two. The boring part prepares the ground so the "cool" part can play to its strengths.

Isn't that the case everywhere?

See you next Saturday,
Tobias