Atiba de Souza.Start a conversation
WritingAI

The Best AI Talk You'll Attend This Year Will Feel Like an Audit, Not a Demo

By Atiba de Souza

Atiba de Souza wearing a blue baseball cap with a Superman logo, seated in front of a microphone. The cover reads: AI The Best AI Talk You'll Attend This Year Will Feel Like an Audit, Not a Demo

You left with a notebook, and nothing moved

You've sat in that room.

Two hundred slides. A live demo. A prompt library stapled to the handout. You filled six pages of notes and photographed the QR code on the way out.

Three weeks later, nothing in your business is different.

Here is what you probably concluded: I need a better talk. Or worse, I'm behind.

Both are misses. The talk was fine. It was answering a question. Just not yours. And you walked in without knowing what your question was, so you had no way to tell the difference.

I want to hand you the test. Not a review of anybody's keynote. The test for whether the next room you sit in deserves your afternoon, and the one move that makes the answer obvious before the first slide.

An assistant hands you back chores. A second brain hands you back judgment.

That line is the whole thing.

An AI assistant clears routine tasks off your plate. It gives you time. That is real, and it is smaller than advertised, because the tasks an assistant takes over were mostly the tasks you were never going to do anyway. That is why the time it returns never feels like enough to change anything.

A second brain does something different. It reaches the work that moves the needle.

So when you measure a talk, stop asking what it took off you. Ask whether it reached the work that moves the needle. Those are two different rooms, and only one of them is worth your afternoon.

A talk worth your time runs a diagnostic on you

It is not delivering content. It is locating your constraint.

I design agentic AI systems for a living, and the sequence I use for that is the same sequence that tells you whether a talk earns your time. It is called the Agentic AI Diagnostic Sequence. Here it is, with the branch that actually matters:

Yes

No. It jumps to prompts, PRD or build

1. Constraint (TOC): where is the leverage?

Eisenhower: what is the leverage of this work?

Eliminate the work that fails both filters

Does the talk locate your binding constraint?

Stay and diagnose. 2. Role, 3. Work Type, 4. AI Employee, 5. PRD, 6. Build

Leave and get a builder

That diagram is the article. Now let me walk the sequence the way I actually run it, because the slide version is how people end up building in the wrong place.

Step 1: Constraint (TOC)

The question it answers: where is the leverage? Which single step in your system sets the pace for every other step?

Binding constraint: the one step in your system that sets the pace for every other step. Work anywhere else on the line is motion, not progress.

That definition comes out of Theory of Constraints, and it is where every build starts. Constraint first, always.

If you skip it: everything after it is guesswork. Get the constraint right and steps two through six are engineering. Get it wrong and steps two through six are an expensive hobby.

The decision it forces on you in the room: did this speaker try to find my constraint, or did they assume mine matches everyone else's?

Now the honest part. I am not going to hand you a sequence and pretend running step one is free. Locating your constraint is an audit of your own business, and it costs you:

  • Work you are proud of. The AI project you are excited about may sit nowhere near the constraint, which means it is not the project right now, however good it is.
  • The comfort of the list. Once you can see the constraint, everything else on your roadmap gets quieter, and some of it goes away.
  • A decision you have been avoiding. Constraints are usually not hiding. They are usually the thing you already know about and do not want to touch. That is often how they became the constraint.
  • Exposure. You have to say out loud, to the people who work for you, that you have been building in the wrong place.

Nobody invoices you for that. Which is exactly why most people decline to pay it, collect another prompt library, and feel productive for ninety minutes.

The counter-move, and it is not a mindset trick. It is a capture.

End of a four-hour session with nine people in Singapore. I was exhausted. The group still wanted dinner. I was ready for the day to be over.

The owner of the Singapore organisation I was making AI-native walked over, unprompted, and said it was one of the best sessions he had ever been through.

I asked if I could pull out my camera. I asked nothing else. He talked for twenty-seven usable seconds.

Best testimonial of the trip. Needed no questions at all. Had I waited until I had my three interview questions ready, the moment and his own words would both have been gone. The questions are the thing that makes it stop sounding like them.

Here is why that belongs in step one. Your constraint does not announce itself in a tidy bullet. It shows up in the raw sentence, the one you say out loud in your normal voice once you stop performing. If I had interrupted that man to run my questions, I would have handed him my structure and lost his. You do the same thing to your own constraint every time you tidy it into a takeaway.

So when the constraint surfaces, do not interrupt it. Get it down in the words it arrived in. Capture the sentence first. Summarize later, on your own time.

The un-numbered move: TOC, then Eisenhower, then eliminate

Before you org-chart anything, run two filters. They sit between step one and step two, and most people skip them, which is how they end up automating work that should not exist.

  • TOC asks where the leverage is. Is this work at, feeding, or near the binding constraint?
  • Eisenhower asks what the leverage of the work is. Triage by urgent and important: do it now, schedule it, delegate it, or eliminate it.

Then, and only then, do you place a role. That last quadrant is where the money is, and it is also the quadrant with no vendor, no demo, and no conference talk, because nobody can sell you the work you are not going to do.

Step 2: Role (AI-Empowered Org Chart)

The question: whose work is this, and where does it sit in the org?

If you skip it: you buy a tool with no owner. It lands on nobody's desk and quietly dies.

What it costs you to do it anyway: naming the seat means naming who owns that work today. Sometimes that person owns it badly. Sometimes nobody owns it and it has been floating for a year. Either way you have to say it out loud, and the org chart you keep in your head does not survive contact with the one you write down.

The decision it forces in the room: can I name the seat this work belongs to in my business? If I cannot, I am not buying a system. I am buying a hobby.

Step 3: Work Type

The question: is this work Strategic, Tactical, or Analytical, and does that slot go to a Human or to an AI?

If you skip it: you hand judgment to an AI and busywork to your best strategic thinker. Both are expensive, and both are common.

What it costs you to do it anyway: this is the step where you write down which of your people's tasks belong to a machine. That is a conversation most leaders avoid right up until the tool gets bought anyway and the conversation happens without them.

The decision it forces in the room: for the constraint I named, which slots are Human and which are AI? If the talk cannot get me to that answer, it has not reached my business yet.

Step 4: AI Employee (Diagnostic Canvas)

The question: what is this AI employee's job description? What does it own, what does it hand back to a human, and how do I know it did the job?

If you skip it: you get a clever assistant with no defined role. Results are inconsistent, nobody can tell whether it is working, and it gets blamed.

What it costs you to do it anyway: writing that job description exposes how vague the human version has been for years. This is the step where leaders discover the real problem was never the technology.

The decision it forces in the room: could I write that job description for the work at my constraint, today, on one page?

Step 5: PRD

The question: what are the requirements? What has to be true for this to work?

If you skip it: you build or buy something, then find out what you actually needed.

Step 6: Build

The question: now what do we actually make?

If a talk starts here, it skipped the diagnosis. Build is not the diagnostic. Build is the reward for a diagnosis you already ran and got right.

Rank the parts, because they are not equal

Step one is the whole thing. Steps two and three quietly decide whether anything you build survives contact with your actual business. Step four is where you find out whether you understood the work. Steps five and six are the least interesting parts of this page, and they are the parts every demo spends its hour on, because they are the parts that look like work.

The gate

Hand this to yourself before you sit down in the room.

  • If the talk spends its hour on prompts, the PRD, or the build before it locates your binding constraint, leave. You are not buying a diagnosis. You are being sold a build, and a build for somebody else's constraint will not fit yours.
  • If it locates the constraint, stay. That is the room you came for, even if the slides are ugly and the demo crashes.

Then run the same filters on the room that you run on your own work. TOC asks where the leverage is: is this room aimed at the work that moves my needle? Eisenhower asks what the leverage is: is this urgent, or just loud? Then eliminate. There is no prize for sitting through the wrong hour politely.

$100,000 this year.

That number did not come from the thing they built in the room. It came from the rewiring of how he thinks about solving problems.

The least likely person in the room, and the hundred thousand dollars

The question came up before one of my recent US AI events: could a coffee-shop owner who does not know what AI is be a target for the event?

I pointed at a man who had already come. His entire experience with AI, in his own words, was signing up for the course. Another attendee that year turned up with a brand-new computer and asked how to turn it on.

Two days later, that beginner put a number on it. A hundred thousand dollars this year.

Now run step one on him, and watch how obvious it gets. His binding constraint was never AI tool knowledge. He had none of that, and he still does not need much of it. His constraint was how he thinks about solving problems. No tool fixes that, which is precisely why two more tools would have done nothing for him. The value of the event was the rewiring. The build was downstream of it.

Which means the screening question changes, for you and for me. Judged on where he started, that man was the least likely attendee to get anything out of a two-day event. The obvious target market was people already using AI. Screening for capability would have kept him out of the room.

And he is the testimonial I quote.

So do not screen beginners out of a teaching offer. Screen rooms by whether they locate and rewire the constraint. A room full of people who already own tools and cannot name their constraint is a room full of expensive hobbies. And when you collect your own proof, capture where the person started, not only what they got. His starting line is what makes the hundred thousand believable.

When NOT to take the general talk

  • If you already know your constraint, a general AI talk is the wrong purchase. You are not buying a diagnosis. You need a builder. Go get one.
  • If the speaker is selling a tool and the tool does not sit at your constraint, the demo is theater. Pleasant theater. Not your afternoon.
  • If your constraint is a decision only you can make (a hire, a pricing call, a partner you need to let go), no keynote is going to make it for you.
  • The one case where the general talk is absolutely worth it: you genuinely cannot see where the constraint is. Then you are buying the diagnosis, and the diagnosis is the best thing you can buy.

The two rooms, side by side

Inconsistent with the diagnosticConsistent with the diagnostic
Opens withA tool, a prompt, a demoA question about where the work actually stalls
Spends the hour onSteps 5 and 6, the PRD and the buildStep 1, the constraint, then the triage
You leave withNotes, a prompt library, a list of tools to tryYour constraint named, and the one decision it forces
What it optimizesFeeling productive for ninety minutesLocating where the leverage actually is
What it ignoresWhether any of it sits at your constraintWhether building is even your next move
What decision it forcesWhich tool to buyWhether to stay and diagnose, or leave and get a builder

Your move before the next talk

It is small, and it takes four minutes.

Write one sentence: the thing you already suspect is the constraint in your business. Keep it ugly. Do not tidy it into a takeaway. Take that sentence into the next room and listen for whether the room finds it or walks past it.

If it walks past it, you have your answer, and you get your afternoon back.

If it finds it, stay. And when the person next to you says their sentence out loud on the way out the door, do what I did in Singapore. Get the camera out. Ask nothing else. Capture the sentence before it turns into a summary that sounds like the speaker instead of them.

Questions

What people ask next

Okay, but once I actually find my real constraint and realize it's a person or a relationship I've been avoiding, what do I do with that? The article stops at 'say it out loud.'
You move to the next step: name the seat. Saying the constraint out loud isn't the end of the work, it's what lets you place the problem on the org chart and ask who owns it today, even if they own it badly. That naming is the exposure the article warns about, but it's also the only thing that turns a painful realization into an actual decision instead of a feeling you sit with.
How do I tell the difference between my actual binding constraint and just the thing that's annoying me most this week?
The binding constraint is the one step that sets the pace for every other step in your system; the annoying thing is usually just noise, loud but not load-bearing. Test it by asking whether fixing this changes what everything downstream can do, not whether it's irritating you. A real sign you've found it: it's usually not hiding, it's the thing you already know about and have been avoiding touching.
If the real leverage is in the eliminate quadrant and nobody can sell me that work, what's supposed to make me actually do it when there's no deadline or vendor pushing me?
Nothing external will push you, and that's the point. The article is explicit that this quadrant has no vendor, no demo, and no conference talk because nobody profits from telling you to stop doing something. The only thing that moves you is running the sequence honestly and accepting that this decision, unlike a purchase, is entirely on you.
The capture technique worked because someone else said the honest sentence out loud to you - how do I run that same discipline on myself when I'm the one being interviewed?
You can't hand yourself a camera, but you can catch your own first sentence before you tidy it. When the real constraint surfaces in your own head in your normal, unguarded voice, write that exact sentence down immediately rather than reaching for the polished version you'd present in a meeting. Summarizing it comes later; the raw version is the one that still has your actual constraint in it.
Once I've named the seat and the work type for the constraint, what happens to all the other projects on my roadmap that aren't near it - do I just leave them running?
No, you run them through the same Eisenhower triage you used for the constraint: do now, schedule, delegate, or eliminate. The article is direct that once you can see the constraint clearly, everything else on your roadmap gets quieter, and some of it goes away entirely, however good a project it seemed before you located the leverage point.