This isn’t a worry about safety, the loss of human autonomy, or anything deeply existential. Instead, the worry stems from the idea that these changes feel like a shortcut to user growth that can come with deep repercussions.

The short version: agents just got easier to start and no easier to use well, and the bill for that difference will land on the people I think can benefit from the technology the most.

For context, OpenAI and Anthropic have each built wildly successful products that have allowed users to go from simply chatting with an LLM to working alongside agents.

For OpenAI, the most popular harness for this was, then is, Codex.

For Anthropic, their equivalent was Claude Cowork (for non-technical users) and Claude Code (for more tech-savvy users).

These platforms allowed users to see the real capability of giving agency to an AI. Having agents build morning briefs from data in your tech stack became a basic task, and teams were developing entirely new ways for AI to take real work off their plates.

So what was the issue?

I believe it was a product positioning problem. Both first developed primarily coding-focused harnesses (Codex and Claude Code) but quickly needed to figure out how to bring the same power and capability to non-engineers.

Anthropic took the path of creating Cowork - essentially the equivalent of Claude Code, but with a more tailored UI for non-technical users. OpenAI simply adapted Codex to present those use cases in the same product.

Neither was optimal.

Anthropic users were left with figuring out whether to use Chat, Cowork, or Code on their own. OpenAI users were left not realizing all that they could do with Codex, a tool that, even by its name, is not primarily inviting to a non-technical user.

So what changes did they both make around the same time that didn’t sit right with me?

Consolidation!

Anthropic has moved Cowork closer to Chat, making the transition from one to the other as small as possible.

OpenAI, on the other hand... had quite a few days. They renamed and reshuffled things twice in the same week, and even people who followed this daily lost the plot. That created quite the confusion, and has now left users with ChatGPT Chat (not a pop-up?), ChatGPT Work, and Codex...

Long story short... both made (questionable) product decisions to do one thing. Improve the simplicity and accessibility of using Agents.

Credit where credit is due - what they have built is incredible. In the workshops I run for teams that are focused on helping knowledge workers use these frontier models and harnesses, it’s a breath of fresh air not having to teach people about the terminal.

But I’ve also seen that as these tools have become more “user-friendly”, the underlying issues stay the same:

• they don’t know what can be done with these agents

• they don’t know the optimal way to organize context and orchestrate agents

• they don’t know how to evaluate the work that agents do

• they don’t know the risks behind using these platforms

There is still a massive need to enable people to use this technology efficiently and effectively, which simplification doesn’t solve.

And with the most recent changes, the simplification has almost gone too far. With a single click, without the right guardrails, far more is on the table in terms of risk that most don’t recognize (runaway spend, poorly evaluated work, and misunderstanding of what the value of AI is).

Here’s the simplest flow of logic I can give you on all of this:

1. Agents are now easier to access and set up than ever

2. Guidance on how to use them is lacking. People don’t know what they’re even using behind the scenes.

3. Agentic workflows burn orders of magnitude more tokens than chat, and untrained users multiply that with retries, bloated context, and poor model choice.

4. More use of agents in inefficient manners means more tokens are burned.

5. More tokens burned means more budgets being blown.

6. More budgets being blown means more CFOs asking the question of ROI.

7. More questions of ROI lead to uninspiring answers - because without the proper guidance and enablement, we’ll keep seeing Fable 5 being used to summarize simple meeting notes and generate hallucinated, slop-filled follow-up emails people don’t read.

8. More bad uses of AI lead to more constraints on users to experiment.

9. Less experimentation leads to lost opportunities to change how work gets done.

So how does this get solved? I’m biased, of course, but I’ve seen first-hand how powerful focused, smooth, and steady enablement that takes non-technical users under the hood can be. Marketing and finance teams learning when and why to reach for certain models, how to orchestrate subagents efficiently, how to plan the work before an agent fires off thousands of tokens... that’s the version of this that people get excited about, but it doesn’t magically come in the box.

What you get out of these tools has and still comes down to judgment and taste. And while access is now one click, those key elements aren’t and won’t be.

For a receipt showing I wrote this myself, key by key, on Organic: writeorganic.app/p/39XW-63Z5

If you missed my first post about why I started this series and how Agent frameworks work, you can find it below. It’s not required, but it’s the best place to start.

Subscribe now

After my last post, you might have tried out Claude Cowork and Code to see what Agents can do. Maybe you explored its tools, checked which MCPs you could connect, or planned bigger tasks for an agent than you expected.

These are all great ways to use Agents as you explore further. But you might have noticed there’s a limit to how far you can go before things change or stop working. That limit is called the context window.

The context window is like the AI’s brain capacity. It’s measured in tokens, which are small pieces of text, usually a few characters or a word. The context window shows how long you can use the chat before the AI starts forgetting earlier details.

It’s a simple concept on the surface. But the simplicity of it all hides many important implications that affect the output you get from AI and help explain some of the more frustrating and distrustful moments we have with it.

With that in mind, let’s move from background to practical tips. Today, I’ll explain how context windows work, how to manage them, and how to talk about context in a way that’s actually helpful (not just saying ‘context is king or queen’).

We read it like a gas tank.

Visually, the context window looks like a single gauge. That gauge is always measured in a consistent unit of tokens. Each model has its own context window size, and depending on its depth or intelligence, it will use up its context window at different rates of efficiency.

At face value, it doesn’t sound too far from how we think about cars and their gas tanks. There’s a nice E to F gauge to tell us how much we have left in the tank. It’s always measured the same way. And each car has a different capacity and engine to manage it all.

It’s easy to think of context windows as honest gauges: full means full and empty means empty, and each unit gets you the same distance.

Just as I did in high school and definitely not in my 30s because I’m a responsible adult now, I can squeeze out that last mile home on E based on feel and intuition without second-guessing.

I can do the same thing with my context window, right?

Go under the hood of your context window, though, and the whole picture falls apart. Technically, it is one tank. But it breaks the gas-tank promise in three ways at once, and once you see them, you look at running on E a bit differently.

A more accurate analogy: a marathon. The last mile isn’t like the first; each step takes more effort, and not every step covers the same distance.

Unlike marathon training, I’ll cover the most important parts to understand, such as:

• What makes up a context window, and why it’s never truly empty to start

• How using the context window impacts quality

• When to start working with a clean context window

• Why a bigger context window doesn’t mean better

• And how to spend the window you’ve got on purpose

The gauge never starts empty.

Let’s start with what’s actually in the window before you type anything. Before you say a single word to something like Claude Code, the window is already partially used. This may sound odd, but it’s comprised of all the things the agent needs to have on hand to be an agent:

1. There’s a system prompt helping the model understand how to run and use tools.

2. Reference to memory files that it may have created from past sessions.

3. Descriptions of your /skills you’ve given it access to

4. References to the MCPs you’ve connected and their available tools

Along with other global and project instruction files, many of which you can learn more about in an old post of mine that’s maybe more relevant than ever:

So before you begin, know that your context window is never really at 100%.

Then the session starts, keeps filling, and typically happens quite fast. Because, similar to the context at the start, holding more than you may have expected, every tool result, search dump, and reasoning the model does as you work with it gets stored in the window. It’s no longer just made up of the back and forth you have in the chat window.

As Anthropic puts it, the window is “all the text a language model can reference when generating a response, including the response itself.” Its own output counts against the same tank.

So that “room left” number doesn’t tell you much about what’s actually in there. You pictured an empty tank you could fill, but in reality, it was already part full before you woke up, and the session keeps adding to it from there.

Practically speaking, this doesn’t mean you’re being cheated out of context. All of that pre-session context is extremely helpful for the model to run. The key thing to know is that having lots of skills and MCPs connected to your Agent - if unused - can eat away at valuable context that could be used more efficiently.

The gallons aren’t equal.

Even if we know the context Agents start with, more importantly, we need to be aware of how these agents work with context over time in our sessions. Because they don’t follow the same mental model we mere humans do.

Specifically, the model has no built-in memory between chats or turns, unlike us. When we converse with someone, there’s a natural flow to the discussion. We typically build off the last point spoken and go from there. And from a product experience perspective, it seems to be the same when we chat with AI. But it technically isn’t.

It starts with us providing an input. When the AI model receives this input, it will produce an output message. Pretty straightforward: our expectation is that, for AI to produce its next output, it would just need to take in the new context from our next message.

Instead, every time it responds, it re-reads the entire window from scratch, start to finish. It’s re-reading the whole transcript of it with every turn. It’d be like having to read every text message you sent to someone ever before replying to their latest.

So as you build context, the next thing you send is never read on its own. It’s read against everything already in the window: every file it read, every tangent you chased, every dead end that came before it.

It starts to explain something we have all met with AI - why does quality drop when I’m giving it more context?

Think about how you actually reason. You hold a few things in your head at once and work well across them. Hand you a five-hundred-page binder and ask a question that turns on three sentences scattered through it, and you’ll do worse. Your attention is finite, and you just spread it across five hundred pages.

The model has the exact same constraint. As Anthropic puts it, “like humans, who have limited working memory capacity, LLMs have an ‘attention budget’ that they draw on when parsing large volumes of context. Every new token introduced depletes this budget by some amount.”

This implies that every session needs a job. Every lane you take a conversation down is more context that every future message gets read against, which is why it’s important to be focused on what you are trying to achieve - and why a token spent in a near-empty window buys sharp, focused attention while that same token spent in a crammed window buys a fraction of that. The risk and miles get more expensive the further you run, so steering carefully is as important as keeping track of the distance you’re going.

Don’t run it to E.

While knowing that Agents can handle a bit more context than we might expect, many of us still default to disregarding it and simply going until we hit the limit. There’s an assumption that, even if I did “waste” context, I’ve still got a context window to use, and I don’t want to feel like I’m starting over.

The problem is that the model’s performance and quality can degrade over time, especially as it has more context to work through. Mechanically, this is called context rot, which means the AI starts to “forget” or lose track of earlier information as more information is added.

Chroma put 18 models through nearly 200,000 calls in an industry study and found it plainly: “models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows.”

It’s common enough across all models that it’s important to think about as you get into deep sessions with any Agent today. At some point, the Agent is working with so much context that it becomes much harder for it to process it all and deliver the output you expect. You may find the AI is forgetting important information, not thinking as hard, or simply providing output that is significantly lower quality than you’re used to.

I typically find that once an Agent has hit around 50-60% of its used context window, it’s time to start fresh.

Unfortunately, none of this context rot impact shows up in the interface. Interfaces flag you when the conversation is “too long.” Claude Code shows a bar that fills and then auto-compacts, squeezing the conversation down to roughly 12% of its prior size so you can keep going. Compaction (we’ll touch on this later) is genuinely useful, and I lean on it constantly. But the rot started long before the gauge looked scary, and that’s the part you don’t get shown. You’re watching the fuel level while the engine quietly loses compression.

So, when do you start fresh? As I mentioned earlier, I usually reach the 60% mark and then aim to work in a new session, but in many cases, it depends on what you notice in the output. Things like repetition, forgetfulness, contradictions to an earlier decision, or drifting away from what you asked for.

My rule of thumb: start fresh at the first symptoms, or when the task in front of you changes shape (long before E).

Which leaves the obvious counter: just get a bigger tank, right?

A bigger tank won’t save you.

The windows keep getting bigger, and the models keep getting better. Won’t this solve itself?

Yes, the models have genuinely gotten dramatically better at long context, and the old line that models break at a few thousand tokens is out of date. But the issue with context management and window efficiency still exists because the problem is structural.

Every token relating to every other token is an n-squared problem, baked into how these models are built. As Anthropic puts it, “context windows of all sizes will be subject to context pollution and information relevance concerns.” A bigger tank doesn’t escape that.

And while hearing that context windows are being expanded to 1M tokens is impressive, the best way to interpret it is to assume the tank is bigger, but the engine is still the same. It helped solve the problem of having to chunk all of our inputs into multiple chats, one after the other, but it hasn’t addressed how the models handle all that context and output tokens back to us.

A bigger window also leaves an opportunity for higher costs. If we recall how Agents use all previous back-and-forth as inputs, all of that needs to be processed, which comes at a cost. A request that fills 900K tokens bills at the same per-token rate as a 9K one, so it costs roughly 100 times as much, on every call.

It’s also slower. The model reads the entire prompt before writing a single word, so it drags on longer and longer as the window fills. A near-full tank risks worse answers and makes you wait longer for them.

And a bigger tank doesn’t use itself well. On the same model, around 16K of curated context beats 128K of raw. A focused prompt of roughly 300 tokens beat a 113,000-token one on every model tested, because the small one held only what mattered and the big one buried it.

Spend the window on purpose.

So how do you actually spend it well? Four habits cover most of it, and none of them are technical.

First, look at the window before you work. In Claude Code, the context window can be visualized with /context comm and shows you the startup breakdown of your window, the same load we started this post with. Most people find the same surprises: skills they never use, every description preloaded, and MCP servers carrying dozens of tool definitions, all spending your budget before you’ve said a word. Trim the loadout to what you actually use.

Second, give a session one job. Now that you know every message is read against everything before it, a session that has chased three different tasks is three lanes of context fighting each other. Keep one window pointed at one job, and start a new one when the job changes.

Third, keep your active sessions fresh and store context where a fresh window can reach it. When work needs to continue past a session, checkpoint it: have the agent write the decisions, the current state, and the next steps to a markdown file before you close out. The next session starts clean and reads the doc instead of inheriting the sediment.

Alternatively, use /compact to have Claude Cowork and Code compress and summarize your built-up window into a relatively detailed snippet for the Agent to continue from without having to store context elsewhere.

Fourth, graduate to the /handoff, the move that changed my own workflow the most. When a thread is rotting, or an adjacent task pops up that doesn’t belong in this conversation, extending the session guarantees more sediment, and compacting clobbers whatever you were mid-stream on. So I tend to use a custom skill called /handoff instead. It asks the agent to write a short doc that captures the purpose of the next session and provides pointers on what it needs, and then let a fresh window pick it up.

Matt Pocock, who packaged this as a /handoff skill, has a design rule worth following for all agents: “do not duplicate content already in other artifacts... use pointers instead.” It’s how good agents already treat context, too. As we know from my first post, the likes of Claude Code never load the whole repository of files we’ve given it access to into the window; it fetches what it needs, when it needs it.

It was never a tank

The windows will keep getting bigger, and the models will improve, but context management will be the underlying capability to get the most out of them consistently.

Once you stop seeing context as a capacity the labs hand you, and start seeing it as a budget you spend, a few things change at once.

• You stop blaming the model for failures that were really about a crammed window.

• You can hand an agent something big and messy and keep it sharp through the whole job.

• You stop asking “can it do this for me?” and start asking “does it have the right context, and have I actually pointed it there?”

Stop filling the window, and start spending it. Hopefully this was helpful!

Share

Subscribe now

The short version of where I’ve been: heads down with clients across all sorts of industries, helping their teams actually get good at using AI. And that work is what led me here. Across very different companies, I keep running into the same blockers, misunderstandings, and similar aha moments. They’ve become common enough and useful enough that I wanted to share them somewhere wider than one virtual workshop room at a time.

So I’m starting a series here called Under the Hood, and this is the first chapter.

I want to start somewhere practical, with an observation about how these tools are actually built and presented. On the surface, it feels like a classic SaaS product problem. But underneath it is what I’m really trying to get at, both here and across the series:

The ones who are breaking through the most with AI aren’t simply the ones with the most tools, budget, or time to explore them. Instead, it’s those who are investing their time in knowing what’s going on behind the scenes with these models, harnesses, and solutions.

It may feel technical, and can be heavily engineering-focused at times. But I’m hoping to use this series to make AI a bit less scary, more digestible, and more inviting to explore. So let’s get into it.

The gap behind the text box

One of the more interesting things I’ve found exploring AI is the gap between how deep, powerful, and multi-functional these systems are, and how simple the little text box is that we use to talk to them.

The interface itself is just a text box. And the thing sitting behind that text box can write code, plan a quarter’s worth of business, file a ticket, browse the web, and call out to your CRM.

You’d never know it at first glance, though, because the text box looks like a search bar.

It’s the same interface and feel Google has used for decades. One search, an enormous algorithm and toolset on the other side, and the funny thing is, most of us have no real idea how it works… nor do we particularly care.

As long as it gives me what I need, I’m all set. And when something does break, we go to the mechanic, so to speak.

That’s been the product philosophy for the last twenty years or so, and honestly, it’s mostly been the right one. I don’t really want to know how my phone places a call… I want to push a button and hear it ring. I don’t want a manual for my email… I just want my email to send.

But AI is the first technology where I think that philosophy has actively backfired. No matter what the hardcore AI influencers say, there’s no objective manual, handbook, or best practice for using AI well.

The art of the possible has been left for each of us to paint on our own, and if we know anything about humans, it’s that we don’t thrive in that kind of ambiguity.

So we do the thing we always do when we’re handed something powerful with no instructions: we use it the way we already use the tools we know.

Why AI feels stuck

The productivity posts all over social media that felt exciting in 2024/5 now have a tired quality to them. We can write emails faster, produce decent outputs in record time, and do 10X! All true, but none of it feels like the future we were promised, because none of it actually changes the shape of what we are doing re: work.

It just squeezes the same shape into less time (or more if you are simply arguing with it about em dashes).

And from all the workshops I’ve run and the teams I’ve coached and the people I’ve tried to enable over the last year, there’s almost always a limiting factor. Unfortunately, that limiting factor is us, or more precisely, how we’re thinking about the model in front of us.

Most of us apply AI to the work we already know how to do, because that’s our domain of expertise and the only place we trust ourselves to judge whether the output is any good. It’s a reasonable instinct, but it’s also the ceiling we keep hitting.

The way I think about this is that we’ve been operating in an AI-assisted way. We’ve molded AI onto the job we already had, and what we get back is a faster version of that same job, not a different one and (in most cases) not a better one. We are left to our own devices, and our own devices are the methods we already know.

And while we can be quite a creative bunch, I think a big part of the blame lies with the industry itself and with how this whole thing has been sold as helping us be more productive rather than more capable. Similar to being efficient or effective, those aren’t the same thing. Productive means doing the old job faster. Capable means doing something different, which is where AI thrives.

What Anthropic noticed

Let’s take a look at Claude Cowork.

The story of why it exists is one of the more telling things I’ve come across this year, even if Anthropic doesn’t really lean on it. Their own non-technical people, marketers, finance, ops, the folks who’ve never written a line of code in their lives, started opening up Claude Code to get their actual jobs done.

For most, this sounded a bit odd, but perhaps not for a frontier lab like Anthropic. But the reason was not because they had the creators by their side who could help them out, nor were they really using it to Code as most expected.

They were reaching for it over Chat, because Code could do their work the same way it does code work for the engineering team..

So to make things a bit easier from a UI/UX perspective, Anthropic built Cowork: it’s essentially the same brain underneath, same agentic shape, just a friendlier wrapper with the tools tilted toward knowledge work instead of code.

Which brings me to the biggest flaw I see in all of this. What’s truly going to change how we function, make progress, and frankly survive with AI has nothing to do with having a friendlier thing handed to us.

It’s being handed the understanding of how the thing actually works. And yes, that means getting out of your comfort zone, taking a look at some unknown unknowns, and stepping into territory you’ve maybe been a little terrified of. But that’s the territory we’re in now, because the actual function of how we work is what’s changing.

Not being able to see, comprehend, and experiment with the core of how these things work is a disservice to you.

So back to Cowork: yes, it’s powerful, and yes, it’s intuitive. I agree with both. But the UI and the framing have planted three dangerous ideas that come up in pre-workshop intakes I’ve had with clients:

• That it’s simply a new tool that’s smarter than Chat, without you knowing it’s the exact same brain.

• That it can do more than you’re used to, without you knowing why, or what else it could do beyond what you’re asking of it.

• That it has access to all sorts of things, without you knowing how to control that access, or that it can run a bit wild.

• That it’s the only thing non-technical teams should be using, and Claude Code is for coding, when in fact that’s just Anthropic’s marketing doing some pretty heavy lifting.

I’m not saying you need to know the ins and outs of agent frameworks, or be able to rattle off what an SDK is. What I care about is that if you can see what Agent harnesses like Claude Code or Codex are actually doing, and translate that to non-technical work, you’ll be a more confident, more token-efficient, more effective operator.

So with this series, where I break down key concepts of advanced and practical AI, I want to leave you more confident in how to think about using AI, more able to talk to teammates and help them along on their own journey, and with a bit of peace of mind around the constant movement of all of this.

With all the noise going on, my hope is that you’ll know what noise to pay attention to, what to care about, and what to lean into, with fewer existential freak-outs.

Today I’m starting with a bit of a lookback to late 2025 with the Claude Code boom, and what’s changed since, and as you’ve probably guessed, we’re going to talk about what the hell an agent actually is, and apply that to Claude Code.

If you’ve spent any time on LinkedIn in the last six months, between the “I built an Agent” talk and the agentic workflow posts, it’ll feel like everyone and their grandparents are deploying agents to do everything. It can sound daunting, maybe like you’re behind, and make you want to close the laptop and go for a walk.

But as healthy as that can be, you may not need to end your day so abruptly. Because what I’ve found from those entering my workshops is that they all have wildly different definitions of what an agent is, and most people are either misinterpreting it themselves or, worse, confidently misguiding someone else.

What a model can do on its own

So let’s just get to a working definition. Start with the simplest possible use case, which is what I’ll call Chat. You open ChatGPT or Claude or Gemini, type something in, hit enter, and you get text back. That’s essentially the entire interaction model.

While the LLMs are incredibly powerful and also complex in how they work, all they can do, technically speaking, by themselves, is to receive text, run that text through their parameters, and produce text. It can’t open a file, send an email, or pull a report from your CRM. On its own, it can’t actually do anything else. Unfortunately, almost no marketing tells you that.

More and more over the last few months, however, labs and developers alike have found a way to have these incredible brains operate with hands through tools.

Tool use is the whole game

The moment AI can take action, execute work, do something in the world, we can start calling it an agent. And the mechanism that lets a model do that has a very boring name called tool use.

Tool use is the primary game to think about as you explore what agents can do. It’s the single most important concept in this entire conversation, and it’s the one thing that rarely makes it into the LinkedIn agent posts.

Before we get a touch more technical, the cleanest way to explain it is with a contractor.

Let’s say you hire a contractor to redo your kitchen. They show up, you tell them what you want with some specifics (new cabinets, an island, maybe a different layout), and they listen, they nod, they confirm a few things, they suggest alternatives, because they’ve done kitchens before and they’ve seen the mistakes you’re about to make.

You’ve got some agreement in place and a plan to go with. But it’s awkward because nothing is happening. You’re hoping they’ll write up a quote in their system, bring in their plumber, cross-check the structural wall, get the permit… but nothing happens, because the contractor doesn’t have a phone, a truck, a permit book, or a crew on speed dial. They can think about your kitchen, but they cannot do anything about it.

That’s what using AI through Chat directly is. A smart contractor with no toolkit. They can think about your problem, talk about it, and describe what should happen next, but they cannot do any of it.

Now imagine the contractor in real life:

• phone in pocket

• crew on speed dial

• calculator

• truck

• permit book

• spreadsheet of suppliers

Now they can make the calls, do the math, hire in extra hands who can also do work, and tell you when it’s done. The contractor just got equipped, and that’s what an agent feels like. The only difference is tool use.

We’ll get to what tools are readily available for most agents, but before we can do that, we need to understand more about the toolbox and how AI utilizes it.

The harness and the loop

There’s going to be a lot of talk about harnesses over the next year, and it’s likely going to be a bit overwhelming. It’s the architecture that goes around an AI model to allow it to use tools and go farther than most day-to-day uses of AI.

As these harnesses develop further, capabilities will change, and it may feel hard to keep up. However, the core of how the AI functions in this harness will stay the same, and is the most important concept to grasp if you want to get the most out of it.

At its core, the AI model itself is still doing what it always did, which is taking text in and producing text out. It’s the harness around it that makes the text consequential.

Some of that text could be just a reply to you, similar to how Chat functions. However, some of it is an instruction for the harness to run a command, open a file, hit an API, search a directory, or even spin up a subagent.

The interaction model changes significantly.

Rather than supplying text back to you, the AI can now have the harness execute (use its hands), return the result, and allow the model to assess it. And depending on the task at hand, the AI can continue with more instructions in the form of a loop until it feels it has what it needs to produce text or artifacts back to you, the user. It’s as if the brain just got handed a remote control.

Here’s a look at how this flows at a general level:

1. We prompt the agent with a request

2. The agent analyzes that request. Based on the tools available in the harness, it will instruct the harness to execute these tools (e.g., “Search the web for X”).

3. The harness executes and gathers some form of output to return to the LLM to analyze.

4. Based on the output and requirements of the prompt, the LLM will either:

   1. Instruct the harness to execute more steps (either more of the same tool or others)

   2. Package up a reply to the user

5. The harness then sends the packaged up reply to the prompt, enhanced with analysis of the tools that were used, back to the user.

Let’s get even more granular and use an example of sending off a simple prompt to an agent along with a PDF that says, “Open this file and summarize its contents.”

When you send your message, the harness, behind the scenes, tacks on a few instructions you never see, teaching the model how to ask for things. Something like:

So when the model “opens a file,” what’s really happening is it produces that one line, the harness spots it, goes and reads the actual contents of the file with its tools, and pastes the contents back into the conversation. The model never touched the file or read it in the way you would expect. It just asked, in a format the harness was watching for.

Once you can see that one move, the whole loop makes sense, because it mirrors how any of us work through a problem.

1. You gather context

2. You make a plan

3. You take action

4. You look at what came back and adjust.

The model does exactly that, round after round: gather, plan, act, read the result, go again. It’s the same way our contractor would work once they’re properly equipped, sizing up the job, doing a piece of it, seeing what the room tells them, and revising as they go.

Now let’s get back to reality and consider Claude Code, since it’s the cleanest example. Claude Code is a harness. It’s a piece of software that wraps around the model and gives it a set of tools to operate with. While the harness is powerful, it is just plumbing. It still needs a brain to be useful, and that’s where the model comes in.

But the thing I think very few people internalize is that when you use Claude Code, you are using the exact same trained model you’d use in Claude Chat.

It’s the same weights, the same training, the same parameters. The brain you talk to when you ask Claude about your weekend plans is the same capable brain that’s doing some pretty complex work in Claude Code.

What changes is the harness around it and the tools it can reach for. Because when a brain knows it has tools, it behaves differently. It’s more thorough, and it often feels smarter, even though it just has tools.

So the mechanism, end-to-end, looks like this.

1. You send a message to Claude Code.

2. The model takes it in, processes it, and produces text.

3. Some of that text is the reply you see, and some of it is instructions to the harness.

4. The harness reads the instructions, runs the tools, and returns the output.

5. The model reads the output, decides what to do next, and produces more text. Some is reply, some is instruction.

6. Gather, plan, act, and on it goes, until the work is done.

That, end to end, is what an agent actually is, and it’s less mysterious than the marketing suggests. But with such a powerful harness available out of the box, it’s the tools that it has inside that will change how you work with it and how you can customize it further.

Understanding Tools and MCPs

Tools come in every shape and size. Claude Code’s default tool set includes Bash for running terminal commands, Glob for finding files by pattern, and Grep for searching inside files. It can read, write, and edit files. It can search the web.

While pretty uncommon in the non-technical world (Glob and Grep sound like great orc names for LOTR), none of this is too exotic. These are the things any developer does on any day, and the model just got handed them.

It gets more interesting when the tools get wider.

Launching subagents is a tool, which is a way of saying the model can spawn a copy of itself in a fresh context window to handle a contained subtask, return a clean summary, and let the main thread carry on without the noise. When that happens, it starts to feel different, because the thing can delegate to itself.

And it gets really interesting when you add MCPs, which probably deserve a Part 2 on their own. People talk about MCPs like they’re some new mystical category, but they’re not.

An MCP is a way of giving a model more tools. And those tools can be part of interacting with other systems and tech stacks.

Connect a Granola MCP to Claude Code, and the model now has tools to read your meeting transcripts. Same logic for Gmail, Attio, whatever else you’ve got. Each “connector”, as it’s called in the desktop version of Claude to simplify things, is just another button on the remote control.

So when someone says they’re using an agent, the only thing they’re really saying is, “I’m using an AI model to help me solve a problem, and that model has been equipped with tools via a harness, so it can actually do something about the problem.”

That’s the whole definition. Strip the marketing off the thing, and you find a small, clean idea underneath.

The same logic applies to Codex, and the same logic applies to Cowork. They’re all variations on the same shape: brain plus harness plus tools.

Which also means that Cowork and Code are more similar than you’d think.

Why Claude Code is called Code

Counter to what most people think, Claude Code is not only meant for writing code. Hopefully, the explanation so far has led you down a path where Claude Code is simply a harness with lots of tools that can do lots of different things, powered by an AI model that you’re probably quite familiar with already via Chat.

Claude Code is called Code because the original problem it solved was about codebases. When you have a codebase with thousands of files similar to a company wiki, you cannot upload it into a Claude Project and ask Claude to read all of it, because:

• The context window (i.e., the amount of space the AI has to take in text/context, think, and output context) isn’t big enough

• The relevant pieces aren’t obvious

• Most of the file tree is irrelevant to whatever you’re working on at any given moment.

So the harness was built to give the model a way to (first breathe, then) efficiently search, read, navigate, and operate on a codebase without trying to load the whole thing into its head at once. If we go back to some of those tools listed earlier, the use of Grep, Glob, LS, and Bash commands becomes really effective at finding and gathering just what is needed.

This is why it’s good at coding. The harness + model knows how to manage context, and codebases are the perfect test case. Remember, the model inside the Claude Code harness is great at coding - but it’s no different from the one you’re already using.

Now consider any other professional context. Say a finance team’s reporting stack, a marketer’s brand archive, a founder’s investor notes, and a customer success team’s account history, as examples. Each of these is, in its own way, a codebase: too much context, some of it useful, most of it irrelevant to the specific question in front of you. An efficient way to search through it, parse it, understand it, design a response, and execute is exactly what every knowledge worker needs.

Anthropic, to their credit, saw this. As mentioned earlier, they watched their own non-technical employees figure it out by switching from Chat to Code, and so they shipped Cowork: a safer, friendlier interface to the same underlying machine.

And while a helpful starting point to start working with Agents, I think Cowork misses the point.

Rather than a safer interface to play with, we needed to understand that Claude Code is what it is because of the harness. The renaming/branding is a helpful touch, but it implies that the version for non-technical people is different when it isn’t. And with its rough edges sanded off to be less intimidating, I find that it’s very hard to tap into the full agentic capabilities of the Cowork harness as a result.

Brain, harness, tools, loop

The architecture of an agent really is this simple. A brain that produces text, a harness that runs some of that text as instructions, a set of tools the harness can call, and a loop.

For those scratching the surface, there’s not much else under the hood that you need to know to get started. The whole thing is brain plus harness plus tools, looping until the work is done.

The architecture is simple, but the implications are far bigger. Almost everything being marketed as a new agent product is, mechanically, doing roughly what I just described. Cowork, Code, and a well-equipped instance of Codex are the same thing in three different wrappers.

And even with these solutions, most of the people I meet are still operating in the AI-assisted ceiling and don’t yet see the ceiling, because the harness has been hidden from them by the standard SaaS product philosophy.

This is why going under the hood matters. I don’t expect you to argue about agent frameworks at a party, but I hope with this series (and this as a starting point) that you can ask better questions, of better models, with better tools, and stop bouncing off the same ceiling.

Once you can see the mechanism, the questions you ask of it change. You stop asking “can you do this for me,” and start asking what tools the model has, what context it needs, where that context lives, and what the right shape of the output even is. You collaborate with it the way you’d collaborate with someone on your team, and the thing in front of you stops feeling like a black box and starts feeling like a colleague with a particular set of capabilities, some you’ve already met and some you haven’t.

At the moment, painting the art of the possible and having the likes of Claude Code be the one to get you there is setting the top performers apart from others. But it only comes once you understand what’s happening under the hood.

Next time, I’ll get into how to actually work with one of these things, now that you know what one is.

Hopefully this was helpful!

Share

Leave a comment

Then OpenClaw showed up.

What changed

If you’ve been following AI tools recently, you’ve probably already heard of it.

It’s an open-source AI agent that hit 145,000 GitHub stars in under a week. It runs on your machine, connects to a multitude of AI models, and you interact with it through Telegram, WhatsApp, Slack, iMessage, or Discord. It browses the web, manages your calendar, sends emails, runs code, controls your browser, and extends itself through a community marketplace of skills. It maintains persistent memory across every conversation, with the ability to connect to an incredible amount of tools from your well-known SaaS apps to smart home devices. And it can develop new skills when it needs capabilities it doesn’t have yet.

It got so popular that people started buying dedicated Mac Minis just to run it 24/7. Rumor has it that the M4 Mac Mini sold out in multiple regions. A $599 computer, purchased specifically so an AI agent never has to sleep. I’d imagine Apple’s Mac Mini product team is having a good month… and probably didn’t see this particular use case coming.

On paper, OpenClaw sounds pretty similar to Claude Code. But there’s a key difference in how they are designed to be used that I can’t stop thinking about.

Claude Code waits for me. I open it, I prompt it, it works, I close it. I pick up the tool, I put it down. Even when it’s running agents or pulling from my CRM, it’s doing those things because I asked.

OpenClaw doesn’t wait.

It has something called a heartbeat engine. It wakes up on its own. Checks conditions. Takes action. Messages you. You talk to Claude Code. OpenClaw talks to you. Proactively and on its own schedule. I should also mention that it’s completely free thanks to it being entirely open source.

People are using it to manage inboxes overnight. Research leads while they sleep. Automatically buy things when prices drop.

The simplest way I can describe the difference is that Claude Code is a tool, OpenClaw is a presence.

Where the conflict starts

I went solo almost two years ago for specific reasons: control over the work, choice of clients, and end-to-end ownership of quality. And most of all, creative ownership. Seeing something go from an idea in my head to something real that looked even better than what I’d imagined.

Claude Code amplified all of that. More capability with the same control. I drive it. It doesn’t drive me.

So when I look at OpenClaw - something that could, in theory, do everything Claude Code does but also run proactively while I sleep - the obvious question is: why wouldn’t I use it?

My first thought (excuse?) was security. I’ve had Claude Code send an email when I asked it to draft one, and it’s stuck with me like a cringe memory that comes to mind at the worst time.

But that argument doesn’t really hold up. OpenClaw can only access what you give it access to. Security is a configuration problem more than a fundamental one. If you’re risk-averse, there is technically a way to have it operate that aligns with what you’re comfortable with.

So what’s actually in the way?

The craftsman and the tool

There’s a thing that happens in any craft when the tools get powerful enough.

A potter who switches to making ceramics with molds produces more. Faster, more consistent, more scalable. But over time, the mold starts to shape the work. They stop deciding based on feel and study of the clay and ceramics, and start deciding based on what the mold allows or what other molds they could make. The output in quantity improves, but the connection between hands and clay gets thinner (and so does the quality that made it special in the first place).

I think about this every time I see someone talk about what they’re doing with OpenClaw and the things they’ve built.

And I struggle with it because I’m a workaholic. I’ve never worked so hard (or enjoyed work as much) as I have over the last couple of years, and since seeing what can be built with Claude Code. But my work-life balance isn’t ideal. If I worked 40 hours a week, I’d feel like I was missing something. That’s a problem I’m actively working on personally, and it’s not something I can address effectively if I’m increasingly focused on finding more outlets for even more productivity.

Adding an always-on AI agent to that, I believe, doesn’t solve it. It would simply make it pretty invisible.

If OpenClaw is checking my pipeline at 6 am and messaging me a briefing before I’ve had coffee, that creates an expectation. And that’s troublesome for a perfectionist like me. I now need to know what it found. I need to respond to what it built. Instead of controlling it, it just showed up at my door, and I’m terrible at ignoring it.

For a lot of people, that’s a feature. For me, it crosses a line I’ve been trying to draw.

The other side of the coin

AI doesn’t need sleep. It doesn’t need rest or mental resets. It operates at full capacity, continuously, indefinitely.

We mere humans can’t.

But when you use a tool that operates like that, something changes in you. You start to feel like you should operate that way, too. Nobody consciously decides “I should work like a machine.” But the ambient expectation creeps in. If something could be running right now, shouldn’t it be?

There’s a quote from a Substack I read (embedded below) that helps illustrate this exact feeling

“I replaced Netflix with Claude Code. I lie in bed thinking about what I can spin up before I fall asleep, what can run while I’m unconscious. Reading a novel feels indulgent now. Watching a movie without a laptop open feels wasteful. This voice in my head that says “something could be running right now” just doesn’t shut off. I’m not even building a company. I’m just addicted to building my random ideas.”

Balancing Act

Token Anxiety

A friend left a party at 9:30 on a Saturday. Not tired. Not sick. He wanted to get back to his agents…

Read more

7 months ago · 35 likes · 3 comments · Nikunj Kothari

I read that and recognized myself in parts of it. The restlessness and the guilt of not building. And this person was talking about Claude Code, which is still just a tool that still waits for you to open it. Imagine what that voice sounds like when the tool doesn’t wait, and it’s already running, already messaging you, already done with something you didn’t ask for.

There’s a term I came across that summarizes the fear I have with going further. It’s called “agency decay.” It’s the gradual, invisible erosion of your own decision-making as AI handles more. You stop making certain choices because something else is making them for you, and you don’t notice until it’s already happened. Having this happen at work is one thing (maybe ok for things that are low context and monotonous), but having this impact human agency in your personal life is where I get worried and where tools like OpenClaw are starting to make inroads.

And as much as we talk about AI saving us energy, effort, and time, that simply enlarges the opportunity to produce more (and the resulting guilt). HBR ran a study this month called “AI Doesn’t Reduce Work — It Intensifies It”, showing that AI expands the scope of original tasks, blurs work-life boundaries, and introduces pressure for more multitasking… which can have a natural adverse effect and be a massive determinant for burnout.

If not managed properly by yourself or the team you’re on, more capability = more output = more expectation = more exhaustion.

What I’m choosing

To be clear: I’m not anti-OpenClaw. Peter Steinberger built something that hundreds of thousands have starred on GitHub for a reason. For people running operations at scale (managing teams, coordinating across time zones), I get why it’s exciting. I’m not drawing this line forever. If my business grows to the point where that level of automation is needed, I’ll revisit it.

But right now, my goal is specific: work with great people on cool projects. Stay creative. Stay connected to the work. Be the one driving. Rinse and repeat.

The cost of crossing that line - the always-on presence, the erosion of boundaries I’m already struggling to maintain outside of work - isn’t worth what I’d gain.

Why this matters more than it seems

This goes beyond me choosing between two tools.

AI just crossed from something you use to something that uses your time. It can now be a tool you pick up and put down, or it can be a presence that’s always there and acting.

That will only accelerate. The agents will get more autonomous. The heartbeat engines will get smarter. Their memory systems will improve. The line between “I use AI” and “AI is running my life” will get harder to see.

Where’s the line between a tool that helps you do more and a presence that won’t let you do less?

I don’t have the answer. But the question is going to matter a lot more soon. And if you thought the AI space wasn’t moving fast enough…

It would go into my inbox every morning. Find newsletters I’d tagged with “AI”—the ones I looked up to, the people writing things I didn’t have time to read myself.

It would pull those emails, extract the key topics, cross-reference them against my content strategy, and generate a custom report. That report would land in my Slack. Here are the stories you should care about. Here’s how they connect to your business. Here are questions you could answer in your own content.

I spent hours building it. Tweaking the prompts. Adjusting the filters. Getting the output format just right.

It worked. But every time I wanted to change something—add a source, adjust the logic, skip a step—I was back in the node editor, re-wiring connections.

Then I replaced it.

Thirty minutes in Claude Code. A single command file. And honestly? It’s better.

Not because the output is dramatically different. But because the thing that replaced it understands context in a way a workflow never could.

That’s when I knew I was using an operating system instead of a coding tool.

What Claude Code Actually Is

ChatGPT has projects. Claude has projects. You can upload files, set custom instructions, and the AI remembers context across conversations.

That’s not nothing. For a lot of use cases, it’s enough.

But there’s a ceiling.

Projects are containers you fill manually. You decide what to upload. You write the instructions once. The AI works with that snapshot.

Claude Code is different. It runs on your machine, inside your actual file system. Not files you uploaded last week—files as they exist right now. It reads them, searches across them, writes back to them.

When I update a client proposal in my folder, I don’t re-upload anything. The context is already current because Claude is operating inside the environment where the work happens.

That’s the first change: from static uploads to live access.

The second shift is scope.

In a project, you’re limited to what you thought to include. In Claude Code, the AI can search. If I ask a question and the answer lives in a file I forgot about, it finds it. No pre-loading required.

The third alteration is connections.

Projects can’t reach outside themselves well enough with the standard connectors. Claude Code can connect to external tools through MCPs—task managers, CRMs, email, databases. It’s operating across the systems where my work actually lives.

And doesn’t run into the issue of gobbling up context and ending a chat entirely (yay compaction!)

These three things—live access, searchable scope, external connections—change what’s possible.

It becomes infrastructure you build on top of.

The Anatomy of My System

Let me show you what this actually looks like.

My setup runs on a GitHub repository synced to my computer. But that’s just my choice—you could use Google Drive, Dropbox, or a folder on your desktop. The point is: it’s files. Organized files that Claude can access.

Here’s my folder structure:

Clients/
Content/
Deal Room/
Events/
Knowledge Base/
Operations/
Products/
Strategy/

Each folder is a domain of my business. Client work lives in Clients. Content drafts live in Content. Strategy docs, positioning, ICP frameworks—all in Strategy.

Nothing fancy. Just organized files.

What makes this a system is six layers on top of those files. Each layer does something different. Let me be specific about what each one is and isn’t.

Layer 1: CLAUDE.md files — The Always-On Context

At the root of my project, I have a file called CLAUDE.md.

This file loads automatically every time I start Claude Code. I don’t invoke it. I don’t reference it. It’s just there—persistent context across every conversation.

Mine tells Claude what this project is, what tools are connected, and where things live. My business operating system. Linear for tasks. Attio for CRM. Gmail through Klavis.ai.

But… I also have a CLAUDE.md inside individual folders.

When I’m working in Clients/Acme/, Claude reads the root context and the Acme-specific context. The system is hierarchical. Context stacks.

So I never have to say “remember, for Acme we’re doing X.” That’s already written down. Once.

What it is: Persistent instructions that load automatically into every conversation.

What it isn’t: Something you invoke or trigger. It’s always on.

Layer 2: Rules — The Conventions That Always Apply

Rules live in a .claude/rules/ folder. Every markdown file in that folder loads automatically, just like CLAUDE.md—but organized into separate files by topic.

I have a rule for how I want files named. A rule for how I manage tasks in Linear. A rule for my voice and tone when writing. A rule for how I structure deals in my CRM.

They’re instructions Claude follows every time.

The difference from CLAUDE.md is organization. Instead of one massive context file, I break conventions into focused documents. File naming doesn’t need to live next to CRM conventions.

Rules can also be path-specific. You can set a rule that only applies to certain files. TypeScript files. Anything in the /api folder. I don’t use this much, but it’s powerful if you need different conventions for different parts of your work.

What it is: Modular instruction files that load automatically. Always active.

What it isn’t: Something Claude decides to use. Rules are passive—they inform how Claude thinks, not what Claude does.

Layer 3: Skills — Capabilities Claude Can Invoke

Skills are different. And where the “holy sh*t” moments happen.

Rules tell Claude how to think. Skills give Claude something it can do.

Each skill lives in its own folder inside .claude/skills/. It has a SKILL.md file that describes what the skill does, when to use it, and how to execute it.

I have a skill for generating proposals. One for managing my CRM pipeline. One for writing in my voice. One for applying my brand to documents.

Here’s how they work. At startup, Claude reads only the names and descriptions of my skills—not the full contents —which saves a ton of context. When I send a message, Claude decides if any skill is relevant. If it is, it loads the full skill and uses it.

The key word is decides. I don’t invoke skills. Claude matches my request to the right capability.

If I say “write a proposal for Acme,” Claude recognizes that as a match for my proposal skill. It loads the skill, follows the structure I’ve defined, and generates a proposal in my format. I don’t have to explain the process.

Skills can also bundle scripts, templates, and reference files and - the best part - other skills!

My proposal skill includes my standard proposal structure. My voice skill includes examples of my writing. Claude pulls these in when it needs them. And if I have something more freeform, it will decide all the skills it needs to use on its own. Worst case, I can direct it to a skill to use.

What it is: A capability Claude can invoke when it detects a match. Auto-discovered.

What it isn’t: A manual trigger. You don’t type /skill-name. Claude decides.

Layer 4: Commands — Shortcuts You Invoke

Commands are the opposite of skills.

Skills are automatic. Commands are manual. You type /command-name and it runs.

Commands live in .claude/commands/ as simple markdown files. Each file is essentially a prompt template that executes when you call it.

I have a command called /get-ideas. When I type it, Claude runs a multi-step process:

• Read my /strategy docs.

• Check recent content I’ve published in /content.

• Scan newsletters in my inbox labeled with “AI”.

• Research trending topics that could be related with Exa.ai.

• Generate a matrix of content ideas and post it in a markdown file in /content-ideas folder.

And the whole workflow is defined in one markdown file (equivalent of a Notion page).

I have another called /weekly-review. It will:

• Pull my pipeline from Attio

• Look at my tasks from Linear

• Identify what needs attention

• Propose follow-up actions.

One command. Runs the same process every time.

Commands can take arguments too. /research AI adoption trends passes that topic into the command and shapes the output.

Think of commands like saved automations—but written in natural language. And because they’re just markdown files, I can edit them whenever I want. The process evolves as my needs change.

What it is: A prompt template you explicitly invoke with /command.

What it isn’t: Automatic. Commands wait for you to call them.

Layer 5: MCPs — Connections to External Tools

Everything so far is about files and instructions. MCPs are about reaching outside.

MCP stands for Model Context Protocol. It’s a standardized way for Claude to connect to external services—your CRM, task manager, email, databases, etc.

I have an MCP for Linear, my task manager. Claude can create tasks, update statuses, query what’s due.

I have one for Attio, my CRM. Claude can pull my pipeline, update deal stages, create notes on records.

I have one for Gmail and Google Drive through a service called Klavis. Claude can search my inbox, read newsletters, access documents.

I have one for n8n, so Claude can help me build and validate automation workflows.

These aren’t read-only. Claude can write back. When I run /weekly-review, Claude doesn’t just tell me what needs attention—it creates follow-up tasks in Linear and logs notes in Attio. The connections are bidirectional.

What it is: Bridges that let Claude interact with external tools and services.

What it isn’t: Instructions or knowledge. MCPs provide capabilities, not context.

Layer 6: Agents — Autonomous Workers for Complex Tasks

Agents are different from everything else in this system.

Skills are capabilities Claude can invoke. Commands are shortcuts I trigger. Both operate within a single conversation.

Agents are subprocesses. They spin up, run autonomously, and come back with results. And they are controlled by the primary agent that you are interacting with. You can imagine if Claude had a team of Claudes that were all really focused on just one thing, and they only had to receive a particular set of instructions from the main Claude.

I have an agent for deep research. When I’m exploring a topic for content, it doesn’t just do one web search—it runs multiple searches, cites sources, and returns a structured report. The work happens in the background while I do something else.

I have another for pipeline monitoring. It checks my Attio deals for at-risk indicators, cross-references with recent activity, and prepares a health summary. I don’t have to walk through the logic step by step.

The key difference: agents handle tasks that need multiple rounds of reasoning. Skills and commands are one-shot. Agents are iterative.

You can also assign agents different models. My research agent runs on a faster, cheaper model—it’s doing breadth, not depth. My content writer agent runs on the most capable model because nuance matters. Same system, different engines for different jobs.

Think of it like delegation. Skills are “do this specific thing.” Agents are “figure this out and report back.”

What it is: Autonomous subprocesses for complex, multi-step tasks.

What it isn’t: Something you need for simple operations. Most work happens through skills and commands. Agents are for the heavy lifting.

How they work together

• The bottom two layers (CLAUDE.md + Rules) are always on. They shape how Claude thinks.

• The middle layer (Skills) is automatic but selective. Claude decides when to use them.

• Commands are manual. I decide when to run them.

• MCPs sit alongside everything, giving Claude reach into the tools where my work actually lives.

• Agents sit above everything else. When a task is too complex for a single-shot skill or command—when it needs multiple rounds of research, reasoning, or tool use—an agent takes over. They’re rare, but they handle the hardest work.

All of it is markdown files and configuration. Plain English. No code.

/get-ideas — A Command That Replaced a Workflow

Let me make this concrete.

I mentioned the n8n workflow I replaced. Here’s what it actually did:

Every morning, it would:

1. Search my Gmail for newsletters tagged with “AI”

2. Pull the content from the last seven days

3. Extract key topics and trends

4. Cross-reference against my content strategy

5. Generate a report with story ideas

6. Send that report to my Slack

I was proud of it. Building it took hours of node configuration, prompt tweaking, and debugging webhook connections.

Here’s what replaced it.

A markdown file called get-ideas.md in my .claude/commands/ folder.

When I type /get-ideas, Claude runs through a process I defined in plain English:

Phase 0: Read my strategy docs—positioning, ICP, what I want to be known for. This grounds everything that follows.

Phase 1: Check recent content. What have I published on LinkedIn? Substack? What transcripts are sitting undeveloped? This prevents me from repeating myself.

Phase 2: Pull external inspiration. Search Gmail for tagged newsletters. Run research queries on trending topics. Extract angles worth exploring.

Phase 3: Generate a matrix. Cross-reference strategy, recent content, and external trends. Produce 15-20 ideas, each with a title and two-sentence description. Organized by type and theme—first principles, tactical, strategic, operator perspective.

Phase 4: Save and present. Write to a dated markdown file. Show me the top three recommendations.

Same outcome as the n8n workflow. But different in ways that matter.

Why it’s better

The n8n workflow was frozen. It did exactly what I built it to do—nothing more, nothing less. If I wanted to change the process, I had to rebuild nodes, adjust connections, re-test.

The command is fluid.

If I want to add a step, I edit a markdown file. If I want to skip Gmail one day, I can just say “skip newsletters.” If I want to focus on a specific topic, I type /get-ideas n8n workflows and it weights everything toward that.

The command operates on context.

When Claude runs /get-ideas, it’s not just processing text. It reads my strategy docs and understands what I’m trying to be known for. It checks my recent content, recognizes patterns. It connects external trends to my specific positioning.

The n8n workflow moved data through a pipeline. Claude knows the whole picture.

What the output looks like

I end up with a markdown file that has:

1. Recent content summary — what I’ve covered, what to avoid

2. External inspiration — newsletter highlights, trending topics

3. Ideas matrix — 15-20 ideas organized by type and theme

4. Top picks — three recommendations based on timeliness and gaps

From there, I pick an idea, record a voice transcript of my thoughts on it, and run /from-ideas to turn that into a Substack article and LinkedIn posts.

The whole system connects. Ideas flow into drafts. Drafts flow into content. Each command hands off to the next.

/weekly-review — Pipeline and Tasks in One Place

The other command I run constantly is /weekly-review.

Running a consulting practice means tracking two things: deals and tasks. Deals live in my CRM (Attio). Tasks live in my project manager (Linear). These are separate tools that don’t naturally talk to each other.

Every Monday, I need to answer the same questions:

• Which deals need attention?

• What tasks are overdue?

• What should I prioritize this week?

Before this command, I’d open Attio, scan the pipeline, make notes. Open Linear, check what’s due, flag what’s stuck. Then try to connect the two in my head. Which deals need follow-up tasks? Which tasks relate to which deals?

Now I type /weekly-review.

What it does

Step 1: Pipeline review

Claude pulls my full pipeline from Attio using the MCP connection. It shows me every active deal in a table: name, stage, value, and a health indicator.

Green means on track. Yellow means needs attention. Red means at risk.

The health assessment isn’t magic—it’s based on rules I defined. Days in current stage. Last contact date. Projected close. Claude applies those rules and flags what’s slipping.

For any deal marked yellow or red, Claude pulls the full context—notes, contact history, what we discussed last—and tells me what’s going on.

Step 2: Task review

Claude pulls my tasks from Linear. It organizes them into three buckets:

• Overdue (past due date)

• In progress (currently active)

• Upcoming (due in the next seven days)

It flags blockers. It identifies tasks that have been sitting too long.

Step 3: Follow-up creation

This is where it connects.

Based on both reviews, Claude proposes new tasks. Deal needs a follow-up call? Task drafted. Proposal sitting two weeks? Check-in suggested. Task blocked by something in the pipeline? Dots connected.

Nothing gets created without my approval. Claude proposes, I confirm, then it creates tasks in Linear with the right project, labels, priority, and due date. All following my rules.

Step 4: Summary

I get a combined view:

Pipeline: 5 deals, $45k total value, 2 need attention
Tasks: 3 overdue, 4 in progress, 6 upcoming
Top priorities this week:
1. Follow up with Acme on proposal
2. Ship client deliverable for Beta Corp
3. Prep for discovery call Thursday

One command. Both systems. Clear priorities.

Why this works

Any automation platform can pull data from two tools. Claude understands the relationship between them.

When Claude sees a deal stuck in “Proposal” stage for two weeks, it knows to check if there’s already a follow-up task in Linear. If there isn’t, it proposes one. If there is but it’s overdue, it flags that instead.

Claude reasons across systems.

And because it runs inside my full context—my conventions, my rules, my history—the output fits how I actually work. Tasks get created in my format. Priorities reflect my criteria. Nothing needs translation.

The Intentionality Layer

Building this system taught me more about my business than any strategy exercise I’ve done.

When you set up a workflow in Zapier or n8n, you’re connecting tools. Data goes from here to there. You think about what, not why.

When you build a system like this, you have to write it down. In plain English. What does my CRM structure actually mean? What makes a deal “at risk”? What conventions do I follow when creating tasks? What does my voice sound like?

You can’t be vague. Claude needs specifics. So you get specific.

I spent an afternoon writing my rule for Linear conventions. Naming patterns. Label taxonomy. Estimate scale. Priority definitions. I’d been using Linear for a year without ever articulating any of that. It was all in my head, applied inconsistently.

Now it’s written down. And it’s consistent every time.

First principles by necessity

There’s a phrase in software: “If you can’t explain it to a computer, you don’t understand it well enough.”

Building this system forced me into that kind of clarity.

Why do I structure deals the way I do? What actually matters in my pipeline? When should I follow up, and why? What makes content worth writing?

These are business questions. But I only answered them because I was trying to teach Claude how to help me.

The act of building the system was the strategy work.

The noise reduction

The other thing that happens: you realize how much noise you’ve accumulated.

When you’re designing from scratch, you only include what matters. You build exactly what you need.

My system has eight folders. A handful of rules. A few skills. A few commands. Five MCP connections.

That’s it. That’s my entire operating system.

I’m not saying it’s complete. I add to it as I find gaps. But I’m building toward what I actually need, not inheriting what someone else imagined I might need.

There’s a creative freedom in that. And a clarity.

What This Isn’t

I need to be honest about the limits.

This works for me. A solopreneur running a consulting practice. One person, one system, one set of preferences.

I’m not sure it scales. And I’m not sure everyone needs it. But once more people get the hang of this, this way of operating (which is interestingly less structured) will be the new norm. Systems thinking will look a lot different when applied to organizational design in the future.

The barriers

File management gets complicated with teams. Who owns what? Where do things live? How do you handle conflicting conventions? My system works because I’m the only one using it. Add a second person and you have coordination problems.

Accessibility is another issue. I’m comfortable in a terminal. I know what a markdown file is. I’ve spent years tinkering with tools like this. Most people haven’t. Asking a team to adopt this setup means asking them to work in unfamiliar ways.

Technical understanding matters too. When something breaks, I can usually figure out why. Read an error message, adjust a configuration, test a fix. Not everyone can. And right now, there’s no support layer. Just documentation and your own willingness to debug.

These aren’t small obstacles.

Traditional automation still matters

I also want to be clear: the n8n workflow I replaced wasn’t wrong.

I still use n8n. I build workflows for clients all the time. For most teams, agentic workflows and traditional automation tools are exactly where they should be focusing.

Not every problem needs this level of integration. Most teams would get real value from well-designed automations using tools they already have—Make, Zapier, n8n, combined with targeted AI where it makes sense.

The gap between “no automation” and “AI-native operating system” is enormous. Most of the value lives in the middle. Taking manual processes and making them automatic. Connecting tools that don’t naturally talk. Adding AI to specific steps where reasoning helps.

That work is where most organizations should start—and many should stay.

What I’ve built is a forward-looking experiment for someone who wanted to understand where this is all going. It’s not a prescription for how everyone should work.

The Shift

A year ago, I would have told you I’m not technical.

I’d been a Chief of Staff. An operator. A generalist. I understood tools well enough to use them, but I didn’t build things.

I’m not sure that distinction holds anymore.

I still can’t write a function from scratch. But I run my business on a system I designed. The rules are mine. The conventions are mine. The processes are mine. I can change any of them by editing a text file.

That’s the change I’m trying to describe.

I don’t know what AI will do. But I know what’s possible now for someone willing to spend a few weekends figuring it out.

An AI that knows your context. Follows your rules. Connects to your tools. Runs processes you define in plain English. All that’s left is figuring your own core business model and running with it.

If that sounds useful, here’s where I’d start:

• Download Claude Code and open it in your terminal (30 seconds)

• Voice-to-text transcribe your entire business model, way of working, and goals and have it repeat this back to you. Tell it you want to build an entire OS.

• Type in /init to create an initial CLAUDE.md file to start, and keep going.

That’s it. That’s your operating system. Everything else is just layers you add when you need them.

I’ve been getting questions lately about how I got into this AI space. And honestly, the answer keeps looping back to something I struggled with for years in my operator roles.

More on that below. It’s that time of year for reflecting, right?

~ Harry

I spent five years as a Chief of Staff. And for most of that time, I couldn’t really explain what I did.

Not because I wasn’t doing anything. I was everywhere. Strategy meetings, cross-functional projects, putting out fires, connecting dots, and having a blast being somewhat of a rogue generalist. I was, as many operators describe themselves, “the glue.”

But explaining that to someone new or outside the company, no matter the context (interview, resume, networking), sucked.

Glazed eyes for days.

“I improved cross-functional alignment.” And?

“I streamlined our quarterly planning process.” Okay, but what does that mean?

“I was the person who made things work.” Sure. But what did you actually *do*?

Too vague, and I sounded like a corporate training manual. Too casual, and I tended to devalue what I was doing. Unless you knew what a Chief of Staff was... good luck.

I didn’t have a good answer. None of the operators in related communities did. The value was real, but the proof was... words. Just words about work that was nearly impossible to demonstrate.

“You had to be there.”

The Invisibility Problem

Operators have always had this curse.

Our best work doesn’t photograph well. It’s the meeting that didn’t blow up in our faces. The project finished on time. The cross-functional political battles and nonsensical riffs that somehow turned into alignment because of your you. It’s preventing problems, not solving visible ones.

This is genuinely valuable work. Companies run on it. But it shows up in micro-moments rather than KPIs. It’s felt more than measured. And when it comes time to prove your worth (in a performance review, a job search, a conversation about your next role), you’re left with descriptions.

“I was strategic.” “I drove initiatives.” “I wore many hats.”

These are just, again, words. Fancy (and cringey) ways of saying “trust me, I was useful.” The corporate poetry (h/t ) that somehow becomes second nature.

I’ve been on both sides of this now. Struggling to articulate my own value as a CoS, and then coaching other operators through the same conversation.

Honestly, there are only so many ways to say it without sounding like everyone else applying for the same type of career paths.

And for a long time, that was just the reality of being an operator. You accepted that your work was invisible. You hoped the right people noticed. You got good at telling stories.

But something’s changing.

The Follow-Up Question

I’ve been talking to founders and people hiring for ops roles lately. And there’s a question I keep hearing that I don’t remember from a few years ago.

It comes after the standard stuff. After “tell me about your experience” and “how do you approach ambiguity.” After you’ve explained your ability to figure things out, handle complexity, operate in different environments.

The follow-up: ”What have you actually built?”

Not “what did you work on?” Not “what were you responsible for?” What did you build?

Pre-AI, this would have been a tough standard to meet. Some might consider it unfair. Operators don’t build things - engineers build things. We design, we scope, we coordinate, we manage. The actual making was always someone else’s job.

But the question makes sense when you realize what it’s really asking: Can you produce something tangible? Can you show me, not just tell me? How did you turn an idea into something that impacted growth?

And until recently, most operators couldn’t.

What Changed

They couldn’t because the requirements to do so meant becoming engineers, learning to code, or - on a deeper level - stepping away from their generalist and operator roots that made them valuable in the first place.

But now those requirements are not as far to reach. And combined with the business sense of an operator, you can learn to architect real, ROI-driving solutions with tools that didn’t exist five years ago.

Custom GPTs that solve real problems. Automated workflows that actually run in production. Internal end-to-end applications that teams use every day. Real artifacts.

Think about how designers have always worked. They don’t just talk about their aesthetic sense. They show you a portfolio. “Here’s what I made. Here’s the impact it had.”

Operators can have that now. Except instead of mockups, it’s workflows and tools that actually run.

• “Here’s the automated process I built that saves my team 10 hours a week.”

• “Here’s the Custom GPT my sales team uses to prep for calls.”

• “Here’s the system I deployed that tracks X and alerts us when Y.”

That’s a different kind of proof. It’s about demonstrating.

The Threshold Is Higher Than You Think

I want to be clear about something, though. The bar isn’t “I can prompt.”

Everyone can prompt now. That’s literacy. Knowing how to use ChatGPT doesn’t set you apart any more than knowing how to use Excel did in 2010 while on Wall St.

The real threshold is production. Things that:

• Actually work reliably

• Teams adopt and use daily

• Solve real problems that tie to real goals, OKRs, and EBITDA

Artifacts that prove you can produce from start to finish (and may even show up on a GitHub contribution graph).

This is harder than it sounds. Most operators I talk to have tried AI in some form. They’ve used ChatGPT, followed a tutorial or two, maybe even started building something. But they don’t have much to show for it. Their experiment hit a wall. The workflow they tried got ~70% of the way there. Their teams don’t really use what was built.

Now, this doesn’t mean you need to be vibe coding SaaS applications left and right. But from what I’ve seen in the market today, there is still a gap between where operators are today and where the opportunity lives.

What This Means

I want to be careful here. I’m not saying the invisible work doesn’t matter anymore. Coordination, synthesis, and making things run smoothly are still essential. Companies still need people who can do that (and perhaps more than ever, given how fast some of these seed-scaling companies are growing).

What I’m saying is there’s now an additional dimension for people to consider.

And the operators who can support themselves with real artifacts will have a different kind of perspective to share.

It compounds, too. Every solution you build adds to your portfolio. Every working system becomes a reference point. There is more proof in the promise.

What I’m Doing About It

This thinking is what led me to build a course launching in January.

Not another course about understanding AI or promising an outdated PDF of prompts that AI generated in the first place. Trust me, we have plenty (too many?) of those.

My focus is on helping others build. It’s about leaving with artifacts you can point to instead of knowledge you can absorb anywhere else.

The idea is simple: operators who want to answer “what have you actually built?” should have a real answer by the end. Something deployed. Something that works. Something that proves you can produce.

If that sounds like what you need, the first cohort starts January 12th, and you can use ‘AI4OPS’ for a nice lil discount.

AI for Operations Leaders Course

I also ran a lightning lesson last week on some of the initial topics for that course - free to check out, and may be helpful if you’re specifically thinking through the CustomGPT vs Workflow vs Agent decision-making process.

Access Lightning Lesson

The Bigger Picture

But beyond any course, I think this shift is worth paying attention to.

The question “what have you built?” is going to keep getting asked. By founders, by hiring managers, by the people deciding your next role or your next raise. And operators who can only provide descriptions of activities or hopes will be at a disadvantage compared to those who can show their work.

As I said earlier, some challenges can’t be solved by building. And there’s a reason operators are the ones who solve those. They have solutions and ideas that others don’t possess. But now, even more of your ideas can be prototyped faster and don’t need as much support from others; the potential value you bring is greater than ever.

I’m still figuring out what most of this means for future organizational design. But I know it starts with being able to answer the question.

What have you actually built? And what will you build next?

Share Not Another AI Newsletter

Not bad, exactly. Not scammy. Just... hollow.

I believe the premise behind most approaches is fundamentally wrong. And the perfect summation of this is that the likes of OpenAI and Antropic aren’t publishing articles for the “100 Best Prompts for Productivity” as some would expect. They’re creating cookbooks and guides like this one to help you get the most out of the models.

They’ve made the right assumption that using AI is about knowing how to get the most out of the tools, not simply filling in the blanks as instructed.

Let me explain what I mean.

…And you get a template!

Scroll through LinkedIn for five minutes and you’ll find someone offering free AI prompt templates. Comment a keyword, get a PDF, unlock productivity secrets.

The structure always looks similar:

• “Use this prompt to write emails 10x faster”

• “Copy this template for better meeting summaries”

• “Here’s the exact prompt I use for...”

The prompts probably work. You’ll get something out of it. They’re not lying.

But it’s like someone handing you a Mad Libs sheet and calling the final product creative writing.

Yes, you technically produced words. No, you didn’t actually learn anything about how to write.

The template got you to 60-70% of a result. Maybe even 80%. But there’s always a gap. And that gap is where the actual value lives.

The Hollow Gap

As I mentioned last week, AI isn’t like traditional software. When you learn Excel, the formulas work the same way every time. =SUM(A1:A10)does exactly one thing.

AI is a language. It’s malleable. Context-dependent. The same prompt produces wildly different results depending on what you’re actually trying to accomplish, how you’ve set up the conversation, and what unique constraints you’re working within.

Think about it this way: you wouldn’t copy someone’s LinkedIn post word-for-word and expect it to represent your voice, your perspective, your professional context. The structure might work. The message wouldn’t.

Prompts work the same way. There’s a mechanical component you can borrow. But the nuance - the part that makes it actually useful for your specific situation - can’t be templated.

And as we’ve played around with AI more, seen the possibilities, and gotten some value from it, our expectations have shifted.

Because everyone knows AI can do impressive things, we expect it to do impressive things for us. When it doesn’t, we feel like we’re failing. Or worse, we think AI is overhyped.

Neither is true. We’re just using the wrong learning model.

The Exhaustion Cycle

Here’s what I see happening:

Someone feels pressure to “learn AI.” Maybe their CEO made comments about people who aren’t using it. Maybe they’re building a career and watching the once-stable landscape shift under them. Maybe they’re just curious and want to understand what all the noise is about.

So they follow the people posting about prompts. They comment the magic words. They download the PDFs. They try a few things.

And they’re... underwhelmed (and overwhelmed for a different reason?)

Because someone else’s general-purpose solution doesn’t solve their specific problem. The broad approach recognizes a general pain point, but not their pain specifically.

So they try another template. Another course. Another “proven system.”

Same result. Different packaging. And another mailing list to be part of.

The exhaustion builds. The motivation fades. They conclude either that AI is overhyped or that they’re just not “technical enough” to get value from it.

Both conclusions are wrong.

Back to Basics

With all the change going on in the AI space, I’ve been going back to the question of “what’s not going to change in the next 10 years?”

It’s a bold question to try and answer in this case, but I think it’s a useful one.

Everything tactical will likely change. The specific prompts that work. The interfaces. The tools. The models themselves. What’s optimal today might be irrelevant by the New Year, even.

What doesn’t change are the principles underneath.

Understanding what these systems actually are. How they process information. What they’re genuinely good at and what they’re genuinely terrible at. Where to apply them and where to stay away. How to think about problems in ways that make AI useful.

This is the same pattern that exists in every other domain.

If you’re learning to write, you don’t just copy other people’s work. You learn about structure, voice, audience, and clarity. You develop instincts that transfer across any writing project.

If you’re learning to paint, you don’t just trace pre-drawn images. You learn about composition, color theory, and technique. You develop capabilities that transfer across any canvas.

AI should work the same way. But most of what’s out there is paint-by-numbers.

The Templated Learning Problem

I run an AI consulting business. I experiment with this stuff constantly - what works for clients, what doesn’t, what transfers across industries, what stays specific.

And I’ve noticed something about the courses and resources available.

The ones focused on “prompt engineering” are often teaching you to pay for experimental time. That’s literally what you’re doing… paying someone to guide you through trial and error that you could have done yourself.

That’s not inherently bad. Structure and guidance have value. But the thing they’re not teaching you is why any of it works. How the technology was built. How that architecture affects how you should use it. What’s happening under the hood that determines when to trust it and when to question it.

It still feels like magic. Pleasant magic, maybe. But magic.

And when the magic doesn’t work (when you hit a wall on something the template didn’t anticipate), you have no foundation to debug or gain confidence from.

What I Think Matters More

When I think about what actually prepares someone to be effective with AI long-term, it’s not always about the tactical stuff.

Yes, knowing how to architect solutions, build them in platforms, evaluate their performance, launch them, and enable others is still important.

But it’s knowing how to think about problems in ways that make AI useful that stands out to me. Knowing which models to use when. Understanding where AI insight is valuable and where human judgment should override. Knowing how to organize your thinking so AI can actually help - because prompting is really just organized thought, and most people can do that once they know what “organized” means in this context.

These are slower-moving concepts. They don’t feel as immediately actionable as “copy this prompt.”

But they’re the things that compound. They transfer across tools, across use cases, across whatever the next thing is. They put you ahead of the curve instead of perpetually catching up.

The models are going to keep getting better. They’ll require less prompt engineering. They’ll handle more context. The mechanical skills will matter less over time.

But knowing what you’re prompting for (knowing how to reason with these systems, how to evaluate their output, how to fit them into actual work) is going to matter more.

That’s the difference between hollow and substantial. Between consuming someone else’s shortcuts and developing your own capability.

The templates will keep coming. The PDFs will keep getting downloaded. And most people will keep feeling like something’s missing.

Because it is. The fundamentals were never there.

Going Forward

Connor put this all perfectly on a LinkedIn post of mine.

My bet is that people who think like solutions engineers will be ahead, and there’s an incredible opportunity to position yourself as one. I would imagine it’s going to gain the same momentum and popularity as the Forward Deployed Engineer.

P.S. I’m running a Lightning Lesson on Maven next week if you want to explore some of these ideas in this post live.

I’ll be launching a more hands-on course in January for those who want to go deeper.

Feel free to share it with your network to spread the word to those who might be on the lookout for more than PDFs of prompts.

With some space to breathe around the holidays, I’ve been thinking about my own tech stack lately. It’s changed a lot over the course of the year and not in the way you might expect. Rather than going down a path of adding more and more, I’m finding myself using less and less.

Pretty much to the point where I’m running almost everything on markdown files in a repository on GitHub with Claude Code as my engine. Outside of scripts I use and some n8n workflows I store, there’s hardly any traditional code.

This progression (or regression?) has had me thinking along something I’m noticing in the SaaS industry on a large scale and much more loudly when working with clients over the last few months. So I used today’s post to explore this change I’m noticing in a bit more depth.

Enjoy!

~ Harry

---

Before going solo, I spent five years at an enterprise SaaS company. We were building OKR software, and I was running OKRs internally using the very product we were selling to other companies. The ultimate dogfooding situation. And extremely meta, considering I was Chief of Staff.

For some companies, it was amazing. For others, it made it just okay. The gap between “this works well enough” and “this is exactly what we need” was always there. A missing % existed that needed to be filled.

It was a bit of a Goldilocks situation.

That’s why we had a Solutions Engineering team. It’s the same reason why Salesforce has them. Almost every major software company does. These are business-savvy people who are also technically capable, and their entire job is last-mile customization. Configuring the foundation to match how this specific company actually operates.

I didn’t think much of it at the time. It was just how enterprise software worked. And they were a remarkably talented and valuable team.

But.

Now I’m on the other side. Running a one-person consulting shop. And I’ve noticed the same pattern playing out, except now it’s everywhere, and I’m experiencing it personally.

The Solopreneur Version

When I started my business, I went through the standard tech stack journey. Asana first. Then ClickUp. Then Linear.

Each one was fine. None were bad products.

But none were quite right.

And this used to just feel like pickiness. Or maybe FOMO. Always thinking the next tool would be the one that finally clicked.

I didn’t spend precious time on any of this. I didn’t consider it business-critical. However, through this process, I realized I would never find what I needed, and the same would apply to assessments of other software.

Because once you’ve seen what AI can build - once you’ve used Claude Code for more than just coding, or built a workflow that is as effective and more than half the cost of a Clay.com subscription - you can’t unsee it. The bar permanently shifts.

Every piece of software gets evaluated against a new question:

Would I rather build this custom or pay for yours?

And increasingly, with those that are leaning into AI, the answer is “build it custom.”

Something I’ve Been Trying to Articulate

I’ve been sitting with this observation for a while now, and I think there’s a pattern emerging that I haven’t quite found the right words for.

Some software feels like plumbing. Email. Calendar. E-signatures. The data layer of a CRM. You just... use it. You don’t want to think about it, nor do you really have to most of the time. And most of all, you don’t want to build it yourself.

Building your own email server makes no sense. Neither does creating your own legally-compliant e-signature system. These are infrastructure. You outsource them and move on.

But everything else? Everything that sits on top of that infrastructure?

It’s starting to feel optional by the day. Challengeable.

Project management tools. KPI trackers. Dashboard builders. Status update generators. Internal tool builders. All of it is now competing against “I could probably build something that works better for my specific situation.”

And that’s a very different competitive landscape than “I could probably find a better vendor.”

The Attio Example

There’s a CRM called Attio that’s been gaining a lot of traction in the startup and VC world. And I think they’ve figured something out.

They’re a complete CRM solution. But they’re positioning themselves as infrastructure - a clean data layer with good enrichment that you build on top of. Their free tier gives you the foundation. Their paid tier scales with you. But the applications, the custom workflows, the specific ways your team interacts with the data? That’s on you.

And for most GTM teams today, that’s a perfect setup.

*This post isn’t sponsored by Attio but if you know someone on their team that’s willing to sponsor posts like this… open to intros!

They’ve essentially said: “We’ll be the plumbing. You build the house.”

Compare that to Salesforce or HubSpot, which try to be everything for everyone. Which means they need massive Solutions Engineering teams to bridge the gap between what they offer and what companies actually need.

I see Attio as having skipped that problem by not pretending they could solve it.

Why This is Happening Now

Two things changed.

Expectations shifted. The “art of the possible” has permanently expanded. When you know that AI can turn unstructured data into structured workflows, generic software feels inadequate. Not because it’s bad, but because you know it could be better if it were built for you specifically.

And building custom got easier. It used to require developers, budgets, timelines. Now someone who’s business-savvy and “dangerous with technology” can experiment their way to a working solution. Not perfect. Not production-grade. But good enough to replace the tool that was only getting them 80% there anyway.

The same dynamic I saw at Quantive (the OKR company) - where Solutions Engineering bridged the gap for enterprise clients - is now accessible to everyone. You just need to be willing to experiment.

The Pricing Challenge

It’s breaking how software companies charge, too.

Seat-based pricing made sense when value meant “access for your team.” Pay per user, everyone gets in, scale predictably.

But what happens when AI does the work instead of humans?

The more you automate, the fewer seats you need. Seat-based pricing and automation are then fundamentally at odds.

Seat-based pricing dropped from 21% to 15% of software companies in just twelve months. Hybrid models (mixing subscription with some sort of usage or outcome-based pricing) jumped from 27% to 41%.

Everyone’s scrambling to figure out how to charge for value when the value isn’t “access” anymore. It’s “work actually done.” Or in the case of any OKR software platform, the pressure might be there to have clients pay based on how successful they are in achieving OKRs, based on how well your platform supports their strategy-execution efforts.

It opens up the question of what exactly customers are paying for.

The Cable TV Moment

This feels like the cable TV unbundling (and now re-bundling) saga.

We spent years unbundling. One tool for project management, one for communication, one for documentation, one for automation, one for analytics. We’re more bloated than ever.

And just like cable TV, people are starting to say: “Wait, why am I paying for all this? And it costs how much altogether?!?”

Except rather than rebundling into a new cable package that does it all, the teams I’m working with are building their operations into something simpler: foundation layer tools (the plumbing you don’t want to manage) plus custom applications (built by someone who understands the business and can get creative with technology).

What is Still TBD

I wrote a few weeks ago about how your playbook isn’t your advantage anymore. How AI is making it possible to compete on how you operate, not just what you do.

This feels connected. If operational approach is becoming a competitive advantage, then the tools that enable unique operational approaches are going to matter more than the tools that enforce standard playbooks.

But I’m not sure what that means for software companies in the middle. The ones that aren’t quite infrastructure, but aren’t quite compelling enough to beat custom alternatives.

Maybe they specialize harder. Maybe they become platforms that enable customization rather than products that deliver solutions. Maybe they just... struggle.

I don’t have a clean answer.

But the question that will matter more and more stays the same:

Would I rather build this custom or pay for yours?

For infrastructure - email, CRM data layers, e-signatures, payments - the answer is obviously “pay for yours.” The opportunity cost of building is too high.

For everything else? The answer is increasingly “let me think about it.”

And for a lot of solopreneurs, small teams, and even larger companies with the right people... the answer is becoming “actually, I’ll build it.”

That’s a different world than the one most software companies were built for. And I think we’re still in the early stages of figuring out what it means.

Most of the conversation around AI is still about optimization - doing the standard thing better, faster, cheaper. And that matters. But there’s another pattern I keep noticing across totally different industries: companies that want to throw out the playbook entirely.

It’s not for ego or the sake of being different. But because they have ideas about how their industry could work better, and how AI can finally make those ideas real. It’s the same disruption mindset we’ve seen with venture-backed SaaS over the years, but now applied outside of tech.

So this week’s post is about that: when AI’s real value isn’t optimizing the playbook others succeeded on, but helping you to compete on how uniquely you operate.

Enjoy!

~ Harry

So I’ve been working with a weird mix of companies lately. Executive recruiting. Non-profits. Asset managers. Real estate firms. CPG brands. Professional communities.

From the outside, these businesses have nothing in common. Different industries, different business models, different customers.

It’s the kind of portfolio that makes it really hard to answer the “so what’s your niche?” question. Still working on it…

But there’s one common thread: they all have the same problem. And the same ambition to solve it.

It’s not that they don’t know how to run their business. They know the industry playbook. They’ve seen how everyone else operates. They understand the standard approach.

The problem is that they want to operate differently. And until now, they couldn’t.

The Playbook Prison

Every industry has its playbooks. The way things are done. The standard operating procedures that emerged because they worked, got copied, and became the default.

In B2C, you broadcast messages because personalization doesn’t scale. In sales, you segment accounts by size because small teams can’t give enterprise-level attention to everyone. In recruiting, you follow a funnel because manual research on every candidate is impossible. In nonprofits, you operate within certain constraints because the alternatives require infrastructure you can’t afford.

They exist for real reasons. They’re not bad. They are things like resource constraints, human limitations, and an economic reality that comes with running any operation.

But almost every client I work with has ideas about how their industry could work better. Not revolutionary moonshot ideas. Just “what if we could do this part differently?”

What if we could treat every customer like an enterprise account instead of broadcasting? What if we could research every prospect as deeply as we research our biggest deals? What if we could operate our nonprofit more like a high-velocity startup without losing our touch?

They’re operational hypotheses. Ways of working that would create genuine differentiation if they were actually achievable.

And until recently, they weren’t unless you had large amounts of capital and a pretty high risk tolerance.

Let me explain what I mean.

What AI Actually Changes

I will say that I think we’re having the wrong conversation about AI and business.

Most of the discussion is about making existing playbooks better. Using AI to execute the standard approach faster, cheaper, more efficiently. That’s fine. That’s the “raise the floor” work I wrote about last time.

But there’s something else happening that’s I’m finding even more interesting: AI is making it possible to compete on how you operate, not just on what you do.

Let me give you some examples of what I mean.

A B2C company that can now give every customer the kind of individualized attention that used to be reserved for enterprise accounts. Not through better segmentation. Through actual personalized research, understanding, and communication at scale.

A sales team that treats what would normally be commercial accounts like enterprise opportunities. Full research. Deep context. Strategic approach. Because AI handles the research that used to require an army of SDRs (and immense venture funding).

A nonprofit that can move at startup speed and measure their impact for future funding because AI handles the operational infrastructure that normally requires dedicated teams. They’re moving faster because they’re not trapped by the nonprofit playbook.

The lazy thinking is that they are simply applying automations and workflows to standard processes. Instead, they are investing time and resources into finding fundamentally different ways of working/operating that become possible when you remove constraints created by the original playbook.

But not everyone is thinking about AI this way. When I look at how companies are actually approaching this, I see three distinct patterns.

The Split I’m Seeing

Here’s how I’d describe what I’m actually encountering in the market.

On one end, there’s the garbage. The cheaply produced AI ads. The spammy outreach. The SaaS tools adding AI features that do nothing except show they needed to do something AI-related to keep investors happy. The content engines polluting our comment sections.

Instant block. Report as spam so fast.

Then there’s the middle ground - and this is where most companies should start. Taking what works and doing it better with AI. Your current operations, your proven SOPs, your effective playbook, just executed with more consistency, speed, and scale. This is the “raise the floor” work. It matters. You should probably do this first.

But the companies I keep thinking about are doing something different. They’re using AI to test hypotheses about how their industry could work better. They’re applying it to operational approaches that weren’t possible before, and AI gives them a chance to validate whether their contrarian ideas actually create value.

This is where the most interesting conversations are happening. And it’s happening with smaller teams, not enterprise companies stuck in legacy processes.

Which brings me back to that question about my niche.

Why This Matters More Than Optimization

The companies I work with are similar because they all want to operate in ways that their industry doesn’t. They’re asking “what if the standard way isn’t actually the best way?”

And that question used to be theoretical. You could have opinions about better ways to operate, but you were constrained by what was actually executable with human teams and traditional tools.

AI changes that calculation. Your competitive advantage isn’t just your product anymore. It’s not your positioning. It’s not even your team (though that still matters).

It’s how you operate. How you do the work. How you engage with customers. How you deliver value to them.

It won’t be for everyone, but it will be for those in your market who are also screaming for a change from the other side.

The Foundation Problem

But the thing is, you can’t skip straight to tier 3 work immediately.

If your current operations are chaotic, if your systems don’t reflect reality, if your team is drowning in debt - throwing out the playbook doesn’t help. It makes things worse.

You need the foundation first. The boring operational discipline. The pieces in place that help your work function consistently. The baseline effectiveness that lets you raise your floor.

Because differentiation without operational sanity is just a mess with better marketing.

The companies I see making this work are doing both. They’re using AI to handle the operational basics so their team members can focus on the unique approach that creates actual value. The boring stuff gets automated. The differentiated stuff gets attention.

It’s not either/or. It’s sequential. Foundation first, then differentiation.

What Changes

If AI makes it possible to compete on operational approach, a lot changes.

Industry best practices become less important. The “this is how it’s always been done” argument loses weight. The playbook becomes a starting point for questioning instead of blindly copying.

Smaller teams can operate in ways that used to require enterprise resources. You don’t need a massive SDR team to do enterprise-level research. You don’t need huge customer success organizations to give individualized attention. You don’t need extensive infrastructure to move fast.

And competition starts to look different. It’s going to be more about who has the operational creativity to do things differently when different is actually better.

The biggest questions around AI for any company should be less about the tech and more towards using it for competitive advantage their customers would care about:

What could you do differently for your customers if you could? And can AI make that testable?

Subscribe now

Sorry for the silence here. I’ve been quiet here for the last month, thanks to lots of hours in the lab (on my laptop) working on new projects and workshops, and spending quality time with family overseas.

Since taking a pause from writing, I’ve found it almost impossible to have a conversation about AI where ROI is not mentioned (RoAI?). The last few years seem to all be about innovation, creativity, and imagination with AI. And now that we’ve been building more with it, the skepticism is higher than ever.

My take is that people who aren’t getting returns on AI are pointing AI at the wrong things in the wrong way to start with. So today’s post is about putting AI to work in simple ways on boring tasks - not because it’s easy, but because it’s more valuable than you might think.

Enjoy!!

Share

I built an AI agent that does something incredibly simple. It takes meeting transcripts and creates tasks in ClickUp.

That’s it.

No fancy orchestration. No RAG. No sophisticated reasoning. Just: transcript in, properly structured tasks out.

And this boring thing has become the most valuable AI work I’ve done as a 1-person team.

Not because it saves time. Not because it’s technically impressive. But because it revealed something I’d been thinking about backwards.

The Ceiling Problem

Every AI demo I see is about raising the ceiling. Write better than you could possibly today. Analyze data in a way you didn’t think was possible. Do things you couldn’t do before. Make your best work even better.

And I get it. That’s exciting. That’s what gets funded and celebrated and shared on LinkedIn.

But watch what actually happens when people try to use AI this way.

They want it to make them better writers, so they feed it their drafts. The output is... fine? Different? It doesn’t quite sound like them. They spend more time editing the AI’s version than they would have just writing it themselves.

They want it to analyze their business data in new ways. So they build complex dashboards with multiple models. It breaks in weird ways. The insights are technically correct but somehow miss what matters.

They’re chasing capabilities they don’t have. Trying to raise a ceiling that doesn’t need raising. And it exhausts them because they’re trying to become someone they’re not.

The Floor Problem

Here’s what I realized building this agent:

My problem was never that my best work wasn’t good enough. My problem was that my worst work was terrible.

On a good day, when I’m focused and energized, I do fine. I have good conversations. I make smart commitments. I follow through. That’s my ceiling - and it’s probably high enough.

On a bad day? When I’m tired or distracted or just overwhelmed?

I forget things. I drop balls. I lose track of what I committed to. My ClickUp instance becomes a graveyard of half-captured information that doesn’t reflect reality. That’s my floor - and it’s way too low.

The floor is what actually kills you. Not your best days. Your worst ones.

What Raising the Floor Looks Like

After every meeting, my agent processes the transcript. It knows my ClickUp structure. It creates tasks the way they’re supposed to be created: proper descriptions, realistic due dates, clear dependencies, appropriate priority.

It does this every single time. Doesn’t matter if I’m having a great day or a terrible one. Doesn’t matter if I’m energized or exhausted. The operational discipline happens consistently.

That’s what raising the floor means.

I didn’t get better at project management. I didn’t develop new capabilities. I just stopped being as bad at it on my worst days.

And since I’ve turned it live, it’s become the quickest-to-ROI investment than any ceiling-raising project would have been.

Because when I open ClickUp now, I can trust it. I can see what I committed to without trying to remember. I know what’s blocking what. I have the context I need. The system actually works.

Not because I got better. Because my floor got higher.

Why This Matters More Than You Think

Most people I talk to - especially solopreneurs and fractional folks - have the same pattern.

They’re good at their core work. On their best days, they’re genuinely excellent. They don’t need AI to make them better at that.

But they’re drowning in the operational stuff around it. Project management. Follow-ups. Documentation. All the boring discipline that lets you actually execute on the work you’re good at.

That operational floor is low. And it costs them constantly.

They drop follow-ups after networking calls. They lose track of client commitments. Their systems don’t reflect reality, so they can’t trust them, so they stop using them, which makes everything worse.

They don’t need to raise their ceiling. They need to raise their floor.

And that’s what AI can actually do right now, today, without any sophisticated architecture or complex prompting or months of implementation.

It can just handle the boring stuff. Consistently. Every time. Regardless of what kind of day you’re having.

The High Agency Trap

Here’s the specific way this shows up for high-agency people.

We’re good at seeing opportunities and moving fast. We’re comfortable with ambiguity. We can hold a lot in our heads at once. Those are real strengths.

But those strengths come with a specific weakness: we’re terrible at operational discipline.

And we’ve accepted this as the trade-off. You can be operationally disciplined, or you can be high-agency, but probably not both. The discipline feels like it would slow us down.

But what if that’s wrong?

What if you could maintain operational discipline without it constraining how you work? What if the boring stuff just happened automatically, without you having to change who you are or how you operate?

That’s what raising the floor actually enables. You get to keep being yourself - having conversations, making commitments, moving fast. You just stop paying the constant tax of inconsistent operations.

Your worst days stop being as bad. And everything else gets easier.

What Changes

I’m not prescribing that everyone build ClickUp agents.

But the pattern matters: we’re obsessed with AI giving us superhuman capabilities when the most valuable thing it can do is prevent us from being subhuman on our bad days.

The boring operational work we know matters but never maintain. The systems we build with good intentions and then abandon. The gap between how we should work and how we actually work.

That gap costs us constantly. And for solopreneurs especially, there’s no one else to cover it.

Maybe AI’s real value isn’t doing things we can’t do. Maybe it’s consistently doing the things we should do but won’t. The boring, unglamorous operational work that creates the foundation for everything else.

Maybe instead of asking “how can AI expand my capabilities,” we should ask “where do I consistently fail, and can AI just handle that?”

The answer is probably yes. And raising your floor turns out to be more valuable than raising your ceiling.

Because you can’t build anything sustainable on a shaky foundation. Even if you’re building with AI.

Subscribe now

I’ve been thinking less about what AI can produce (time back, productivity, ROI) and more about how we go about practicing efficiency when we actually put LLMs to work.

Because the way I see most of us use them is overcooked for the work we’re trying to have them produce.

It’s down to a reflex problem.

Somewhere along the way, we reverted to simple evaluation of LLMs. Latest = greatest, bigger = better, and pricier = more valuable. Shiny-object syndrome is brighter than ever, simply the default, and we’ve forgotten how to right-size.

Why has this happened?

• Lack of fluent expertise in this space. This stuff is moving so fast, it’s tough to keep up - and let alone form any personal judgement.

• Frictionless setup. Top-tier models are one click away and unusually affordable to try (relative to the previous way we could get access to such powerful SaaS).

• Models are products. And teams are shipping more and more features that showcase value. Spec sheets of models become taste.

• Naming. Pick “thinking” over “mini”? Of course, why would we use something that’s “not as smart”?

This same line of thinking is why expensive reasoning models often end up being used for the most trivial tasks, and how perfectly good models get dismissed as “trash” just a few months after their release. Remember those days with GPT-3.5-turbo? Those were truly the darkest of times… right?

I’m not against advanced, powerful AI models. And I’m not trying to preach for austerity. I’m just a fan of proportion. It’s like how a bigger house doesn’t make a better home by default. And you don’t need a supercar to drive to the grocery store. The same can apply to using AI - big context windows don’t necessarily make better answers, and using reasoning models to look up a simple recipe is wasteful.

However, the problem we face is that the excess is invisible, and the constraints are being lowered. Even as someone who has a business in helping others work properly and more effectively with AI, it’s hard for me to hit usage limits consistently. So the incentive to throttle down to a more efficient model is smaller than ever.

But the costs are real, even if they don’t appear as straightforward: time, energy, attention, creativity, and the resources that go into making this industry run in the first place.

So, here’s the stance I work from, and one I think the world around us would literally thank us for considering (even a little bit): start small unless reality proves otherwise. Not as a forced way of adopting minimalism, but it will keep your attention honest.

Because when these magical tools and applications blow our minds, our attention to the behind-the-scenes aspects and other impacts drifts away. We want more of what we just witnessed. But we then over-credit the tool and find ourselves under-specifying the task to justify it.

In short, “fit > flash” should become the default approach, and any escalation otherwise requires evidence to support it.

To do this for myself (as someone who has fallen into the trap of going too big to accomplish relatively little), I now run four quick questions before I ever turn AI on:

1. How big is the input? (context I feed it)

2. What’s the task shape? (straightforward transform of given data vs decisions with tools)

3. How big is the output? (length and or depth you expect in return)

4. How fast do I need it to work?

That alone does a good enough job of being more effective than most using AI extensively today. Most pick the latest and greatest and default to smaller models when their allotted usage limit is near complete.

If I feel I don’t have the answers to the above questions and need to build as I go, I’ll follow a similar line of thinking but be more prescriptive:

1. Pause - do I even need AI? Or is this something a workflow node in n8n can solve? Perhaps some code that can handle a complex regex I’m battling with would suffice.

2. If I do require AI, small/fast models can be used to extract → transform → format with short in/short out.

3. Do I need greater structure for more reasoning or a larger context? Move to a mid-tier model that is typically default (e.g., GPT-5)

4. If I require more advanced reasoning, or I’m setting up agentic work where I need AI to support planning, reconciliations, multi-step choices with tool interactions, I’ll use reasoning models trained for this type of constraint.

5. For huge inputs or high-stakes analysis, I’ll use more frontier/long-context/specialist models.

However, the key to all of this is to escalate only after prompt fixes, few-shot examples, and evaluations that demonstrate the output is not meeting your criteria. Yes, prompts do operate differently from model to model, and there are best practices for each. But the determination of whether AI is “good” is very sensitive to how you’ve prompted it (not as much the model in most general use cases).

(If you want to know more about doing objective evaluations in n8n and see the impact of changes to prompts vs changes to models, watch below. I’ll be posting more like this on LinkedIn from now on.)

See more content like this

The moral of the story is that you only escalate to a more extensive model if you run into these failures:

• Structural: e.g., did the fields map as expected?

• Interpretive: e.g., did the justification follow logically?

• Operational: e.g., did the outcome reduce intervention requirement?

If a cheaper model misses one of those and you’ve tightened your prompt, then escalate. Otherwise, you’re at risk of being inefficient for comfort.

If your default is “just use the best,” you’re being wasteful in more ways than you think. But if your default is careful, calculated proportion, you become a builder - and that craft scales because it means smaller loops, more apparent failures, and saner bills.

The goal is to be clear about cause and effect. Using AI can be fast and quick, which can give us a false sense of security. Having it work and avoiding the model choice conversation is basically allowing the model to compensate for your lack of craft and care.

And if we genuinely care about preserving creativity, agency, craft, and the resources this industry relies on, thinking frugally about compute becomes more than just saving a buck or being efficient with your AI credit limit. We’d be in a much more sustainable spot with AI if we all became more resource-conscious before we turn things live.

Following the simple mindset and flow I outlined above doesn’t require much effort and can produce a higher ROI than you might expect. Give it a try and let me know how it goes!

Subscribe now

Share

It’s nothing to do with whether I feel they do or don’t know what they’re talking about. In some cases they usually know more than I do about the technical details.

It feels more to do with a sense that fluency in a subject and making it operational can move in opposite directions. The more sophisticated someone’s understanding of AI capabilities, the less likely - in the day to day - they are to build something that actually gets used.

Sure, it’s not always the case. But with a barrier to entry so low, the probability is there.

And this bothers me because I used to think that knowledge was the constraint. That if people just understood what AI was in layman's terms and knew what it could do, they’d naturally figure out how to apply it.

But I’m seeing more cases of the opposite happen.

Those that are experimenting and learning on the fly - and actively building - are shipping stuff that’s good. It’s not sexy or brilliant, but it gets the job done. And then there are people who can explain larger architectures but we never see anything built.

And I think the difference here is being comfortable with simplicity.

When you get what AI can do, get a practical feel for understanding it, and see some output, simple solutions seem almost insulting. You hear of cases where someone spent an hour building a relatively simple AI agent workflow and selling it for far more than you’d expect and it feels wrong.

Why automate one manual process when you could redesign the entire system that it’s part of?!?

But then I have to think about what happens in reality. Complexity means you’re likely taking on expensive risks. Maintenance. Breaks. Explanations to others. And the biggest of them all - building something complex that’s for a complex problem that isn’t even a real problem in the first place.

Simple systems can be boring. But they work. And if they don’t, you know quickly (and at a lower cost).

A lot of this comes at a moment where I’ve been rethinking my own business model. Specifically, what is it that I do that brings me joy, can be sustainable for work, and can address a need in the market.

Subscribe now

The answer is simple solutions that work fast and let teams get a grip on the potential around AI in ways that create ROI.

But simple solutions, in my mind, felt inadequate. Part of it was the intellectual challenge mentioned earlier.. if you know what’s out there, basic applications feel like you’re not using the tech properly. It’s too good to be true.

But I think something else is going on in those cases where we hear 90+% of AI implementations fail.

Sophistication and overcomplicating a solution give you permission to avoid the uncomfortable, difficult conversations.

This has happened now for years in SaaS (particularly in Product teams). And the same pattern is playing out with AI - the people and teams that get overwhelmed by the possibility of AI have yet to figure out what makes their business actually different from their competitors.

Simply put, they can't answer 'what are we uniquely good at?' with enough specificity to guide their AI decisions.

When you don’t know what you’re optimizing for, every AI capability looks equally promising. That’s what we’re being told from every vendor and the horizontal, flat, multi-vertical nature of AI makes it hard to go against. Every efficiency gain seems worth a test. Every integration feels like it “might be the game-changer.”

So you end up trying to build systems that do everything instead of systems that do one important thing really well.

It’s those that know that business clarity problem first that win. They know the constraints, the focus, the goals, and the distractions. They know what creates a competitive advantage and those that don’t. It becomes a literal filter for every investment decision.

Dare I say, they have a strategy.

Without that filter, technical sophistication becomes a way to avoid admitting you're not sure what you're trying to solve.

So instead of showing a bad example, here’s a good one from a team I talked to that’s approaching this well:

They’re a small team and are in an old-school space. They are battling lots of larger, more traditional, and well-respected competitors. Each - including themselves - has their unique toolkit: a product/service, a network, and a message.

But when I asked them about what is the one thing that’s going to help them outlast and win, they said their human-centered approach. Their communications are deeply empathetic, most of their time is spent talking to customers, and they have ambitions to be far more customer-centric in the future.

While this doesn’t scream like a fit for AI off the bat, their deeper reason for leaning into AI is a perfect use case. They want to find even more ways to amplify their unique, winning approach.

And not in the ways most would think.

Where some teams would use AI to replicate their communications at scale, they want to find other parts of their back office work to automate so they can spend more time on calls with customers. Where some teams would look for AI to identify and chase new leads and expand their base, they’re building products with AI to create deeper relationships with their existing customers.

Teams like them with clear business focus for AI describe what the tool will help them stop or start doing. Teams without that focus describe technical architecture - what models they’re using, how the agents interact, what the workflow looks like. And are probably explaining workflows that can be explained rather than starting with a real problem to solve and uncovering a solution as you go.

Technical architecture is much easier to discuss than business strategy. It feels concrete, more measurable, more like progress. I can go on about how much I enjoy using Claude Code, but without purpose behind it it’s just experimentation.

That’s ok in the space I’m in (and required at times). But for other teams it’s a cost.

So all of that is to say that this has made me reconsider how I think about AI expertise and how I defined it for myself. I used to assume that understanding all the bells and whistles and capabilities would naturally lead to better solutions (and help me be a better engineer).

But maybe the opposite is true. Maybe understanding capabilities makes it harder or more distracting to choose a capability that’s going to work.

The biggest constraint for most will be having business clarity of what actually matters and being able to say no to complex, sophisticated solutions when there’s a simple one right in front of you.

I believe this is why all these massive AI implementations aren’t going well, but the scrappy few that work for small teams do. The pressure to find something that works today is the constraint we all need to work in.

It now feels like the time we should start focusing on figuring out what AI should do for a specific situation, even when that means ignoring most of what it could do.

It’s a bit of a different kind of expertise. It’s not necessarily technical, but it makes it really clear what matters to your business and what’s going to get you the ROI we’ve been promised.

Maybe that’s why I’m getting suspicious of AI sophistication in some areas. Again, it’s not wrong, but it often finds itself solving the wrong problem.

Share

My challenge was that I had so many avenues to cover and lots of rabbit holes I could have jumped into. The constraint of pulling this into a single workshop actually forced me to throw out quite a lot of my content (e.g. Agents, workflows, LLMs, RAG implementations), and instead focus on the principle that has helped me the most when building with AI myself and helping clients:

10% > 10x. Is it mathematically sound written like that? Nope. Will it make sense if you read on? Hopefully!

Enjoy!

Subscribe now

Like many of you, I've been flooded with demos, showcases, and clickbait LinkedIn posts begging me to write "AI" that focus on showing me something that seemingly used to be impossible.

They've designed a solution for something that previously took 3 hours but now takes 12 seconds. And they all wait for some sort of applause, recognition, or AI-generated comments to pump engagement.

But what's actually happening isn't excitement. It's something much heavier.

Not exactly fear. More like... that feeling when you realize you have seventeen browser tabs open about AI and each one we deem important, but looking at all of them makes you want to close your laptop? That weight.

And that weight is crushing us.

The Revolution Trap

We only celebrate revolutions now.

Nobody gets promoted for lots of slight improvements. Nobody raises money for incremental progress. The whole story we tell about technology is about disruption, transformation, and changing everything.

AI made this worse. Way worse.

Because now transformation feels both possible and required. A nightmare for any perfectionist!

Every workflow that hasn't been AI-enhanced feels negligent. Every human process feels outdated. Every small improvement feels like cowardice.

You take your own notes still? SHAME.

But watch any company trying to adopt AI right now. They freeze because they have too many options. Leaders are exhausted by the need to "transform" everything. Teams split between those racing toward an AI future and those trying to preserve something human.

The transformation imperative becomes its own kind of trap. And the only answer seems to be chucking ChatGPT licenses and wishing everyone good luck.

How Change Actually Happens

So what actually happens? Companies announce these massive AI initiatives. Revolutionary customer onboarding. The AI SDR that changes everything. Beautiful architectures with multiple models working together, RAG implemented, fallback options designed.

They plan for months. They strategize. They roadmap.

They never launch.

It's not that it couldn't work. Testing might even show results. But implementation would mean retraining everyone, rebuilding the CRM, rethinking their entire service model. The transformation becomes too big to actually do.

Meanwhile, something else is happening quietly.

Someone in Customer Success starts using ChatGPT to write better follow-up emails. That's it. Nothing fancy. Just better emails. Customers start responding more. Conversations improve. Relationships strengthen.

Nobody calls it a transformation. But their Tuesdays from here on are way more manageable than they were before.

The sales rep who uses AI to research prospects has more time to think. The engineer who automates code reviews has energy left for design. The marketer who generates variations faster can focus on strategy.

They're just getting better at being themselves with the help of AI, without needing to become a full-on AI Operator.

The Compound Effect Nobody Sees

Compound improvement breaks our brains.

We understand linear progress. Ten percent, then another ten, then another. It feels slow. Human-scaled. Normal.

But compound math is weird. For most of the curve, you're actually behind where linear growth would put you. Then suddenly, you're not. You're miles ahead.

Get 1% better every day and the math gets weird fast. You're not 365% better after a year. You're 37 times better. It just happens through accumulation instead of revolution.

We can't see it though. We judge progress by next quarter, not next year. We want the revolution now, not the compound effect later.

So we chase 10x improvements. But most 10x improvements are lies.

Not intentional lies. Just narrow ones:

• The AI processes documents 10x faster… but needs 3x more human oversight.

• The automation handles 10x more volume but breaks in ways humans never did.

• The transformation hits its metrics but destroys what made those metrics matter.

When we chase 10x, we define success so narrowly that we win by changing the game. We can often celebrate the one metric that improved and ignore the three that got worse.

But 10% improvements can't hide. Ten percent better means actually better. Your Tuesday actually improves. You can feel it and measure it.

The Other Kind of Courage

Transformation takes courage. Breaking things takes courage. Betting everything takes courage. We celebrate this courage. We fund it. We write articles about it.

But there's another courage we don't talk about.

The courage to be 10% better when everyone expects revolution. The courage to compound small gains while others chase moonshots. The courage to evolve when you could revolutionize.

This looks like admitting your current process mostly works, building on what exists instead of starting over. Measuring progress in smaller increments. Trusting accumulation over disruption.

It's the courage to be ordinary when everyone's trying to be extraordinary.

Why This Actually Matters Now

Every week, someone tells me they're terrified. AI will replace them. It's too technical. It's overwhelming.

The fear makes sense. The demos are compelling. The capabilities are real.

But watch who's actually thriving. Not the ones trying to become AI operators. The ones who got 10% better at being themselves.

The designer who uses AI for variations but spends the saved time understanding users better. Developers automating the boring stuff to focus on architecture. And that one ops person who finally automated the thing everyone's been complaining about for two years.

They're using AI as leverage to become better at what they already do.

And it compounds. Each improvement makes them more valuable, not less. More human, not less. They're growing with AI instead of putting them in a race against it.

Share

The Radical Thing

Maybe the most radical thing we can do right now is refuse to be radical.

Choose evolution when everyone demands revolution. Pick 10% when 10x is possible. Be ordinary in extraordinary times.

Because real change happens through accumulation instead of through disruption. Because ordinary improvements compound into extraordinary results. Because humans still need to live in whatever future we're building.

The companies I watch succeed are the ones running small experiments every week. Where progress gets measured in increments. Where teams have permission to get just a little better.

Those are the ones actually reaching that greater promise of potential. Even if it is a long game.

Especially because it's a long game.

My knee-jerk reaction was to roll my eyes. Sounded like a Chief of Staff with better branding. Or maybe a founder-in-residence who couldn't find a company to start. The tech world loves its titles.

But.

I've been sitting with this for two days now, and there's something here I can't shake. Something about why this role is emerging now when everyone's supposedly building with AI already.

It’s funny because the barrier to building has essentially dissolved. A product manager can spin up their own tools before lunch. Sales can automate workflows without filing a ticket. Customer success can create dashboards without asking permission. In theory, everyone becomes a builder. The democratization we were promised and marketed.

So why is everyone frozen?

The Weight of What's Possible

I was Chief of Staff during a 20→500 scaling. Started in March 2019, back when AI meant machine learning models that data scientists built in isolation. By 2023, everything had changed. ChatGPT had arrived. Suddenly, AI was accessible to everyone.

The company needed someone to figure out what that meant. So I became that person. Led our internal AI team while still doing the Chief of Staff thing. I had this weird freedom to explore new corners of the organization, test things, fail quietly (and loudly…). Nobody else had bandwidth for that kind of wandering. They had jobs to do. Quotas to hit. Customers to serve.

My job became, in a way, to not have a job. To be uncommitted enough to commit to exploration.

We decided we needed more to be involved, so I created this AI ambassador program - I'll write about the full mechanics another time, but the core insight was simple. We needed designated explorers in each function. People who could spend four hours a week just figuring out what could be possible.

Testing. Breaking things. We'd meet weekly, share what we'd learned, what failed, what surprised us.

The conversations in those rooms were fascinating. And terrifying.

Week one: "I built a script that does my weekly reporting in 12 minutes instead of 3 hours." Week three: "I built 50% of an SDR." Week five: "I don't know what to build anymore."

That last one. That's where everyone gets stuck.

Tuesday's Tools, Thursday's Obsolescence

The pace is insane. And I mean that literally - it makes people feel crazy.

GPT-5 just arrived and with every drop, everyone's asking if they need to rebuild everything. Next week, something new will come out and create a fun, shiny distraction.

This begs pretty hard questions to answer quickly: What happens when we do? What else becomes possible? What breaks? Who gets uncomfortable? What assumptions about our business are we actually encoding into an automation? What are we choosing not to build while we build this?

But who has time for those questions???

You're running a business. Your team has deliverables. Your board wants updates. Your customers need support. You can't afford to explore every possibility. You can't afford the luxury of uncertainty.

During those AI ambassador sessions, I watched brilliant people struggle with this exact pressure. They could see lots of possibilities. They could build almost anything. And that paralyzed them.

We used to know what tools to use. Now we don’t even know what problems to solve.

The Explorer's Mandate

This is where the Builder in Residence thing starts to make sense. The role is a containment strategy for infinite possibility.

Think about it. Every other leverage point in business has had this:

• Capital lets you invest in new projects and scale ideas

• Talent lets you bring incredible people together to solve problems

• Code lets you build something once and scale it infinitely

And now AI is this fourth leverage point and lets you build a new way to create value.

AI needs its explorers. People who can hold the uncertainty while everyone else holds the business together.

When I ran that AI ambassador program, I was essentially a Builder in Residence without the title. My value wasn't in the tools I built (though I built plenty). My value was in the exploration itself:

• The failed experiments that saved other teams from wasting time.

• The unexpected connections between disparate tools.

• The ability to say "we tried that, here's why it doesn't work" or "this looks complex but it's actually straightforward if you approach it this way."

The ambassadors would come to our weekly sessions with questions:

• "Can AI help with our pricing models?"

• "What about customer churn prediction?"

• "Could we automate account research within Salesforce?"

My job was to have already explored enough of the possibility space to guide the conversation toward what mattered. To help them understand the difference between what's possible and what's valuable.

The Anxiety Economy

There's an emotion I keep encountering in every company I work with now and in conversations I have with solopreneurs. It's specific. Unique to this moment.

It's the anxiety of knowing you should be doing something with AI but not knowing what. The fear that by the time you figure it out, you'll be too far behind. The overwhelming sense that everyone else has it figured out while you're still trying to understand what "it" even is.

This anxiety is profitable for a lot of people. Tool vendors promise to solve it with their platform. Course creators promise to solve it with their playbooks.

The anxiety is about infinite possibilities more than anything.

When you can build anything, how do you choose what to build? When everything is changing, how do you commit to a direction? When tools make everyone a builder, who decides what's worth building?

The Designated Wanderer

Last month, a client called me his "Chief of Agents."

He'd hired me to build a go-to-market function from scratch. It’s a fun challenge: early-stage company, great product, no systematic way to sell it at higher ticket value.

But instead of immediately hiring salespeople or buying tools, we explored a different question: How could AI help us stand up a GTM function before bringing in human talent?

The exploration started narrow. Testing AI for lead qualification. Building agents for initial outreach. Experimenting with different conversation flows.

Each week, I'd build something, break it, rebuild it better. No formal process. No workshops. Just me wandering through the possibility space and reporting back what I found.

Then something interesting happened.

My exploration in go-to-market was opening up possibilities they hadn't considered elsewhere. Not because I was smarter or more creative, but because I had the luxury of exploration. While they were shipping features and fixing bugs, I was discovering what AI could actually do in practice for the product itself and even onboarding journeys as well.

I became the organization's AI scout in a way. Testing the terrain before they committed resources. Building prototypes that might go nowhere. Learning what worked by discovering what didn't.

The key was that I wasn't creating burden for anyone else. No mandatory meetings. No required reading. Just: "Here's what I learned this week. Here's what it might mean for you. Take what's useful, ignore the rest."

The Builder in Residence is hired to be what everyone else could be but can't afford to become. They explore so others can execute. They fail in ways the core team can't.

What This Actually Looks Like

Here's what I've learned about making this work:

The exploration has to be grounded in real problems. Not "what can AI do?" but "what does this specific team need?" During those ambassador sessions, we'd start with actual workflows, actual frustrations, actual wishes. Then we'd explore from there.

The builder needs enough context to be dangerous but enough distance to be objective. As Chief of Staff, I had both. I understood how the organization actually worked, but I wasn't embedded in any single team's daily operations. I could see patterns others couldn't because I wasn't drowning in the details.

The insights have to be translated, not just transmitted. When I discovered something useful, my job wasn't to say "here's a cool tool." My job was to say "here's how this changes what's possible for your specific situation, and here's what we'd need to believe for this to be worth pursuing."

Most importantly: the exploration has to be continuous. This isn't a sprint or a project. The landscape changes too fast. The Builder in Residence is a permanent function, like having a scout who's always three miles ahead of wagon train.

Subscribe now

The Coming Wave

We're going to see a lot more Builders in Residence. Or whatever we end up calling them.

Every company that's serious about AI but realistic about their constraints will need someone in this role. Someone whose job is to carry the burden of infinite possibility so everyone else can focus on specific, chosen realities.

They won't be prompt engineers who optimize your ChatGPT usage. They'll be explorers who venture into the space between what your company does today and what it could do tomorrow, then come back with actual intelligence about which paths are worth taking.

I've ended up in this role for my clients almost by accident. They hire me thinking they need AI strategy or implementation help. What they actually need is someone to carry the weight of not knowing. To sit with the uncertainty. To explore the maze while they run the race.

There's something almost religious about it. The designated wanderer. The one who goes into the wilderness and comes back with maps of territories that didn't exist last month.

Maybe that sounds too mystical. But I don't know how else to describe what's happening. When you can build anything, someone needs to figure out what's worth building. And that someone can't be everyone.

The burden of infinite possibility is real. The question isn't whether you need someone to carry it. The question is who, and how soon.

Subscribe now