I Built AI to Get My Time Back. I Became the Bottleneck.

 

I run Z Digital Agency, and I am co-founder and COO of Sommelier.bot, I run Cyber-Security and AI private round-tables for most european large companies. Differents roles and windows into what’s truly going on, with the AI revolution.

Three years ago I started building with AI, and starting December 2025, building AI systems seriously. Not “using Claude with MCP to write emails faster” seriously. Seriously as in agents, pipelines, memory, flywheels, autonomous automations, an entire operating layer meant to run parts of my agency work without me sitting in the middle of them.

Twenty-four months in, I have more systems running than I ever thought I would. I also feel more tired than I did before any of them existed. Not tired from typing. Tired in a way that is harder to name: the specific fatigue of being the slowest part of something you built to be fast.

I do not think this is a personal failing. I do not think I am the only one.

I think most of what the AI industry is currently selling assumes the opposite of what actually happens once the systems start working.

So let me explain what I got wrong.

Every time-saving machine has made us busier

This is not speculation. It is a documented pattern going back fifty years, and it matters here because it tells you what to expect from the next wave before it arrives. Four thinkers, none of whom touched AI, described exactly what I was living:

• Staffan Linder (1970). As economies get richer, people do not get more leisurely. They get busier. The richer a society becomes, the more money a single hour can generate, and the more expensive it feels to waste that hour. Wealth does not buy time. It makes time scarcer, because it raises the price of every minute you are not using it. I felt this personally within a month of the first systems going live. The more leverage each hour carried, the more unbearable an empty one became.
• Hartmut Rosa (2005). Every time-saving tool does not reduce your workload. It raises what is expected of you. Email did not reduce correspondence to five messages a day. It raised the normal volume to fifty. I built a system that could generate ten times the content I used to produce. I did not get ten times the free time. I got the quiet expectation, mostly from myself, that I should now be producing ten times the output. Rosa called this a slipping slope: you run faster and the ground moves with you, so you never actually get ahead.
• Jonathan Crary (2013). A 24/7 economy slowly colonizes sleep, the last part of the day that produces nothing. My agents run at 3am. They do not get tired, they do not stop, they do not wait for me to wake up. I built a system explicitly designed to never sleep, and somewhere in that design I stopped noticing that I still need to.
• Josef Pieper (1948). The oldest voice on this list argued that real leisure is not recovery time between tasks. It is the capacity to sit with something for its own sake, without optimizing it. That capacity requires slack. AI systems, left unmanaged, are extraordinarily good at removing slack, because slack looks like waste to a system optimizing for throughput.

Four different eras, one pattern. Every previous acceleration was sold as a path to more leisure. Every one of them delivered less.

Why AI breaks the pattern instead of just repeating it

Here is where the older framework, built for human-paced technology, starts to strain. Rosa’s slipping slope assumes a human is still setting the pace on at least one side of the equation: the person answering the faster email, the worker keeping up with the faster machine. AI removes that assumption.

An agent that drafts, decides, and executes in seconds does not just raise the bar for how fast a human should respond. It removes the human from that side of the loop entirely. The system no longer needs me to keep pace with it in real time. It runs a strategy, tests a hundred variations, and ships a decision while I am still reading the first paragraph of a briefing.

That is not a faster version of the email problem. It is a different category of problem, because the thing being optimized is no longer bounded by my ability to think, read, or react.

Ask yourself, honestly: at the pace your AI systems are producing output right now, are you still meaningfully evaluating what they ship, or are you approving it? The two feel similar in the moment. They are not the same thing at all. All developers who had their Claude Code asking for permissions initially at every move, then not so much anymore…. know what I mean.

When everything is possible, I am the constraint

Here is the part that took me the longest to accept.

I used to think the constraint on my business was time, then it was budget, then it was talent. AI removed all three, faster than I expected, and what was left standing in the way was not any of those things.

It was me.

When a system can generate a hundred versions of something in the time it used to take to draft one, the decision of which version matters, which direction to pursue, which thing deserves my actual attention, does not get any faster. If anything it gets slower, because now there are a hundred options instead of one obvious next step. The machine accelerated. My judgment did not, and it cannot. Judgment is not a compute problem. It is a human one, running on the same nervous system it always has.

I spent months feeling guilty about this. I assumed I just needed to move faster, decide faster, keep up. What I eventually understood is that “keeping up” was never the actual goal. The system does not need me to match its speed. It needs me to know, slower and more deliberately than the system operates, which of the hundred things it just made is actually worth pursuing.

Being the bottleneck is not the failure. Confusing that role with a failure is.

Friction was the thing protecting me from myself

There is a second effect I did not expect, and it has arguably done more damage than the fatigue.

When building something used to take weeks, the friction itself forced a kind of filtering. You did not start a project unless you had thought it through, because starting was expensive. That friction was doing quiet, unglamorous work: it was killing bad ideas before they cost you anything.

Remove the friction and something strange happens. Because building is now fast, cheap, almost frictionless, the instinct becomes that everything should be built, and built now. A landing page here. An automation there. A content engine over there. A dozen half-built things running in parallel because starting any one of them cost almost nothing.

I have personally burned real months and real budget on projects that were technically easy to spin up and never worth spinning up in the first place. The ease of starting fooled me into skipping the harder question of whether I should. Fast building without fast thinking does not produce more finished things. It produces more unfinished things, at a volume that eventually becomes its own tax on the business, paid in distraction rather than cash. Which somehow makes it easier to ignore, and harder to stop.

The question I should have been asking before hitting go on each of those builds: if this works, what do I have to stop doing to make room for it? I never asked it. I built anyway. Six months later I had six systems and the attention span for one.

Prioritization is the only skill that actually compounds now

If building is no longer the bottleneck, and thinking clearly under abundance is the harder problem, the skill that matters most has quietly shifted.

It is not prompt engineering. It is not knowing which model to pick for which task. It is prioritization, in the oldest and least exciting sense of the word: the discipline of deciding what not to do, and meaning it.

This sounds too simple to be the answer, but I have watched it play out enough times to trust it. The people and companies actually getting somewhere with AI are not the ones running the most experiments. They are the ones willing to kill nine out of ten AI-generated ideas before they consume a single hour of build time, and willing to say no to their own excitement. Which is the hardest version of this skill to practice, because the excitement is real and the ideas often are good.

The rule I now apply in both the agency and at Sommelier.bot: I do not start a build unless I can name the specific customer or workflow that will be worse off if I do not. Not “would be nice to have.” Worse off. Most ideas fail that test. That is the point of the test.

An “AI system” is not the build. It is what survives contact with real customers and builds a flywheel from every single usage.

This is the distinction I think most people building with AI right now are missing, myself included for a long time.

Building something that technically works is not the same as building a system. A working pipeline, a functioning agent, a clever automation: none of that is a system yet. It is a prototype with good production values.

A system exists the moment it survives contact with something real: actual customers using it, actual data flowing through it, actual feedback loops telling you what is working and what is not. That is the point where a build stops being a demo and starts compounding, where every cycle makes the next one slightly better because there is real signal feeding it, not just my assumptions about what should work.

Most of what gets called “an AI system” today never reaches that point. It is a build that works in isolation, gets shown once, and then sits there, technically functional and practically inert, because nobody pushed it far enough to get real customers touching it or real data accumulating inside it. I have built several of those myself. They felt like progress at the time. In hindsight they were expensive rehearsals for the thing I had not actually committed to finishing.

How many of the AI things you or your team built in the last twelve months have made it past that line? If the honest answer is “fewer than I would like to admit,” you are on the trend line, not off it.

The hardest part of AI work was never the AI part. It is the unglamorous discipline of carrying one thing far enough past the exciting build phase that it starts generating its own evidence, its own customers, its own flywheel. That takes longer than building the thing did, by a wide margin. It is the part almost nobody wants to sit with, because it is slower, less novel, and does not feel like innovation while you are doing it.

If you build a website, an online tool or content: think ahead how is this working with my system and allowing for compounding effects. If not, it is noise, at best.

The metric nobody is tracking: human bandwidth

Here is the uncomfortable claim I would put in front of any leadership team weighing an aggressive AI rollout:

Compute is not your constraint. Cost per token is not your constraint. Your constraint is the finite, non-negotiable, biologically fixed bandwidth of the humans still responsible for judgment, oversight, and accountability inside the system. 

Yes you’ll be tempted in the future to also outsource this to agents as well (Q&A agent, validation agent, even a CEO agent), but without someone to point the finger to, at the first catastrophe, you’ll roll everything back.

Every AI deployment conversation I have been part of (mine included) centers on throughput, output volume, cost reduction. Almost none of them ask the harder question: what happens to the people who are supposed to contemplate the output, not just process it? Pieper’s slack, seventy-eight years later, is still the missing variable on every deployment plan I read.

If your AI strategy is measured purely in hours saved or output multiplied, you are optimizing the wrong variable. The right variable is whether the humans accountable for the business can still meaningfully track, question, and stand behind what the system is doing, at the pace the system is doing it.

That is not an argument against AI. It is an argument against pretending that the pace of your systems can permanently outrun the pace of your judgment, and that the business still makes sense at the end of it.

What I do differently now

I have not solved the fatigue. I do not think it fully goes away when you are operating at this pace, and I have stopped expecting it to. What has changed is what I measure and what I let myself start:

• Automation is NEVER the goal, it is the by-product of good AI. High-quality (3x at least) is the real goal.
• AI is making your work better, acting as a true sparring partner, challenging your vague buzzy words.
• My filter has become: does it compound? If it doesn’t serve the system, I can say no with confidence.
• It should get cleverer without me, thanks to a system built according to my needs. Every day, it scans my trusted sources of information (youtube, blogs, news outlets…) extract what is interesting, compare it to what we have in the system (agents, skills, knowledge, memory layers) and decides autonomously what to summarize and inject into the knowledge base, asking for clarification for ambiguous facts.
• I focus on the system, not shiny outputs. Believe me I’ve build 21 shiny tools websites in March… Build the system first, then increase its reach (tools and agents) and flywheel (memory, self-compounding knowledge)

The machines are not going to slow down. That much is certain, and pretending otherwise is its own kind of denial. The only variable actually within my control is how deliberately I choose what deserves to run at that speed, and how honestly I admit that the pace itself was never going to save me any time. It was only ever going to raise the price of wasting it.

If any of this sounds like the operating rhythm of your own year, I would rather have a direct conversation than send you another dashboard. Get in touch.