Where Should Your Thinking Live?

The hard part isn't figuring out what AI can do. It's deciding what it should do.

Last week I wrote about how AI is making us overengineer everything.

I wasn't pointing and laughing from the sidelines. I was doing it myself.

I've been building my own systems, looking at other people's architectures, and spending probably too much time around agent frameworks. They're fun to build with. They feel like the frontier.

And if you spend five minutes on the internet right now, you start to feel like you're doing something wrong if your architecture diagram doesn't have a few agents strategically sprinkled around it.

So I started sketching agents into places they didn't belong. More than once, I got halfway through the design and realized I already knew exactly what should happen next.

If I can write the rule down, I probably don't need a model. I need a rule. Maybe a database field. Maybe a scheduled job. But almost certainly not an agent.

Putting an agent on a deterministic path is like buying a self-driving car and bolting it to a rail. You paid for autonomy and then removed every reason to use it.

I kept thinking about that after the post because the mistake wasn't really technical. I had started with AI and worked backward toward a problem worth giving it. Brilliant.

Of course, I couldn't just leave the thought alone. I had to turn it into a framework. (I may have a problem.)

I like frameworks because otherwise I end up with a collection of smart-sounding thoughts I never use. A framework forces me to test the idea against the next real decision.

My first pass was five buckets: MAKE. BUY. AI. HUMAN. DON'T DO IT.

Then I noticed the obvious problem: you can easily buy AI. These weren't five answers to the same question.

MAKE and BUY tell you how to source something. AI and HUMAN tell you where some of the thinking happens. DON'T DO IT asks whether the work deserves to exist at all.

And they overlap everywhere. You can build AI, buy AI, build software, buy software, bring in outside expertise, or develop it internally.

I'd made one diagram out of three different decisions.

That gave me a framework I trust more. It starts with three questions, in order:

1. Should this work exist?
2. If it should, where should the thinking and control live?
3. Once that is clear, should we make the capability or buy it?

Less exciting than "Where can we deploy an agent?" Probably a good sign.

First: should this work exist?

This is the question I skip more often than I should.

Before automating a report, does anybody need the report? Anybody who's spent time in a large company knows the weekly email I mean: 27 bullets, three screenshots, a spreadsheet attached, maybe a red-yellow-green table. Some poor person spent half a day assembling it. Most of the recipients skim the subject line, search for their own name, and move on.

Before wrapping an agent around that, maybe ask why the thing exists at all.

AI makes this easier to screw up because automation is suddenly cheap enough to make bad processes look tempting.

You can now build a very sophisticated machine for doing something nobody should be doing.

AI can make pointless work faster, cheaper, and easier to scale. It still can't make the work worth doing.

Sometimes the right move is to kill the process instead of improving it.

Then: where should the thinking live?

Once the work survives that first question, I see four useful answers: software, AI, human, or some deliberate combination of the three.

Software is still underrated here.

If the logic can be specified ahead of time, I'd rather encode it. If it happens every Tuesday, schedule it. If someone has to approve it, enforce the approval. If a value changes state, store the state.

That's where I keep catching myself. I'll start reaching for an agent, then realize the condition is perfectly knowable.

If X happens, do Y.

That's software.

AI gets interesting when the inputs stop cooperating.

An angry customer email that doesn't fit a clean category. Seventy pages of conflicting evidence spread across several systems.

The rule can't always be written ahead of time because ambiguity is the problem.

That is where models earn their keep.

Then there's the human part.

Some work should remain human because of stakes, values, accountability, relationships, or trust. But there's another reason I keep coming back to: sometimes the process is the product.

The reps are what make you capable later. Writing forces thinking. Reviewing evidence builds judgment. Hard conversations build trust. Making the call and living with it builds accountability. Even writing code the hard way is part of how you become the person who can tell whether the code AI generated is solid or bullshit.

That's the part I have to remind myself of when I'm itching to have AI just do it for me. Generation is easy. The danger is outsourcing every hard rep and then wondering why our judgment never developed.

That doesn't mean doing everything manually. It means being deliberate about which parts of the work are just friction and which parts are actually training.

And that's one reason the hybrid case interests me so much. The human doesn't need to do everything, but the human probably shouldn't disappear from the parts where judgment gets built or authority actually matters.

I learned that as a bank examiner, long before generative AI.

Analysis, recommendation, authority, and execution were intentionally not the same thing.

Software can enforce a hard rule. AI can interpret messy evidence. A person can make the consequential decision. Software can execute the approved action.

Those are different jobs.

That separation mattered.

You could do the analysis. You could have a strong view. You could support it with evidence. That still didn't mean every downstream decision belonged to you.

AI makes that distinction easier to forget because one system can potentially gather the evidence, interpret it, recommend an action, and take the action.

Technically, we can collapse those steps.

That doesn't mean we should.

A model might be the right place for analysis. A person might still be the right place for authority. Deterministic software might be the right place for guardrails and execution.

That doesn't feel like a compromise architecture to me. In a lot of cases, it just feels like good architecture.

Make or buy comes last

Only after those first two decisions does make-versus-buy get useful.

This is where my first framework got muddy. MAKE and BUY aren't alternatives to AI or humans. They're sourcing choices.

There's no prize for building payroll yourself. And if a vendor can give you a commodity capability better and cheaper, owning it mostly buys you maintenance.

But if the capability is where you actually differentiate or learn, outsourcing it can mean outsourcing the muscle you needed to build.

I just want to know what kind of work I'm sourcing before I decide how to source it.

The boundaries will move

These answers will move.

Models will get better. Some AI will fade into "just software." Things we buy today will become easy to build, and some work we keep with humans will shift as reliability improves.

Fine. The point isn't to freeze the boxes in 2026. It's to get better at noticing what kind of problem we actually have before reaching for the fashionable solution.

The test I'm using now is pretty simple:

1. Does the work need to exist?
2. What do we already know well enough to encode?
3. Where is ambiguity, interpretation, or synthesis actually the hard part?
4. Where do judgment, authority, trust, or capability development need to remain human?
5. Once the architecture is clear, should we make the capability or buy it?

That might lead to an agent. It might lead to an if statement, a human approval, or a workflow that deliberately combines software, AI, and humans.

And every now and then the best answer is still: why the hell are we doing this at all?

Intelligence is getting cheap. Judgment about where to put it isn't.

Cheap intelligence doesn't get us out of making these decisions. It gives us more ways to put the wrong kind of thinking in the wrong place.