Episodes

  • Why Handing Off Work Is Not the Same as Continuity

    Why Handing Off Work Is Not the Same as Continuity
    Oct 22 2026

    This week I’m going solo to talk about the pattern underneath almost everything your business does: receive, execute, hand off. Handing work to the next person or AI agent isn’t enough, because they also need the context to continue it, and I show why with an AI customer success agent named Maya and a customer success leader named Sarah.

    We get into why access to your CRM, Slack, and email is not the same as context, how Sarah’s call with an at risk customer creates new context that has to travel back to Maya, and why a handoff and true continuity are two different standards. I also connect it to infrastructure architecture, the third pillar of the AI labor architecture framework, and close with an exercise you can run on one handoff this week. If you’re an operator or investor designing a workforce of people and AI agents, this one is for you.


    Episode Timeline & Highlights

    [0:00] – Almost all work follows one cycle: receive, execute, hand off

    [1:31] – Meet Maya, an AI customer success agent who spots a customer at serious risk of leaving

    [2:35] – Maya hands the at risk customer to Sarah, a customer success leader, with no background

    [3:35] – Sarah has to rebuild the story from the CRM, support system, billing, email, and Slack

    [4:54] – Why context is not more information, a bigger context window, or access to everything

    [6:20] – Access to the CRM is not the same as context, only the raw materials to build it

    [7:32] – The better question: what does this worker need to understand to execute this responsibility?

    [8:06] – Sarah calls the customer and creates new context: a business change and a promise by Friday

    [9:31] – When the work returns to Maya, a CRM status change is not the same as context

    [11:45] – This isn’t an AI problem, it’s a work problem: meaning gets left behind every time work moves

    [12:13] – Why so much context lives between your systems or inside your people’s heads

    [14:14] – Good infrastructure gives each worker the right context for their bounded responsibility

    [16:37] – Infrastructure architecture as the third pillar of the AI labor architecture framework

    [18:37] – The difference between a handoff and continuity

    [19:39] – The exercise: pick one handoff and stand in the shoes of the worker receiving it

    [21:30] – People inside your business have become part of the infrastructure, compensating for the friction


    5 Key Takeaways

    1. Handoff Is Not Continuity: Moving work to the next person or AI agent means little if they have to rebuild the story before they can act.
    2. Access Is Not Context: Giving a worker access to the CRM, Slack, and email only hands them raw materials to build understanding themselves.
    3. Execution Creates New Context: Every decision, conversation, and commitment made along the way has to travel forward with the work.
    4. Bounded Context Beats Total Access: Each worker needs the context that fits their responsibility, not the entire history of the organization.
    5. Follow One Handoff: Pick a single handoff in your business and look at what the receiving worker has to search for, ask, and reconstruct.


    Links & Resources

    • smrtPhone: https://www.smrtphone.io
    • That Real Estate Tech Guy: https://thatrealestatetechguy.com


    If this made you think about how work changes hands in your own business, pick one handoff this week and stand in the shoes of the person receiving it. You’ll probably find someone quietly carrying context around in their head. More high-signal conversations coming next.
    Show More Show Less
    24 mins
  • How to Find Where Work Gets Stuck in Your Business

    How to Find Where Work Gets Stuck in Your Business
    Oct 15 2026

    This week I'm going solo to ask a question most business owners skip. You probably run a CRM, a billing platform, a support desk, and 10 or 20 other systems, so how does work actually move between them? I break down why those systems are great at storing information but terrible at moving the next piece of work, and why that gap gets exposed the moment you add AI agents to your workforce.

    I walk through a real world example with an AI customer success agent named Maya, who does her job perfectly and then hits a wall when the work needs to go to a person. From there we get into shared execution, why people like Sarah have been the invisible connective tissue in your operations for decades, and a simple exercise to find where work stalls in your own business. If you're an investor or operator thinking about AI agents, workflow automation, and business infrastructure, this one is for you.


    Episode Timeline & Highlights

    [0:00] – Why most businesses run 10 to 20 systems that store information but don't move work

    [1:06] – The real question: how does work move through your business after a status changes?

    [1:40] – Why the answer is usually manual: emails, Slack posts, and copying data between systems

    [2:57] – Why people have always been the ones moving work between your CRM, billing, and support tools

    [4:38] – Why AI agents expose an infrastructure gap that businesses were never built to handle

    [5:13] – Meet Maya, an AI customer success agent who spots a customer at risk of leaving

    [6:52] – What happens when Maya hands off the work: a task, an email, a Slack message, or a ticket?

    [8:23] – The constraint moves: AI agents become faster than the infrastructure around them

    [10:36] – Why moving data between systems is not the same as moving work

    [12:20] – Why shared execution between people, AI agents, and systems only works if work can move

    [13:28] – Islands of execution, and how Sarah's invisible work fills gaps in your architecture

    [16:10] – The infrastructure questions to ask: what triggers movement and who owns the work next

    [17:06] – The exercise: pick one piece of work and follow it across your organization

    [18:12] – The test: if the people moving this work disappeared tomorrow, would your systems know what to do?

    [19:37] – Why context has to move with the work, not just a notification


    Key Takeaways

    1. Storing Is Not Moving: Your systems record what happened, but they rarely move the next piece of work on their own.
    2. People Are the Connective Tissue: Salespeople, project managers, and coordinators have been manually carrying work between systems for decades.
    3. AI Agents Expose the Gap: A capable agent still stalls when its output has to cross a responsibility boundary by email or Slack.
    4. Move Work, Not Just Data: Syncing fields between systems is not the same as keeping execution going as work passes between people, agents, and systems.
    5. Context Travels With the Work: The next worker needs to know what happened, what was tried, and why the work moved, not just a "please handle" alert.


    Links & Resources

    • smrtPhone: https://www.smrtphone.io
    • That Real Estate Tech Guy: https://thatrealestatetechguy.com


    If this made you stop and wonder where work sits waiting in your own business, pick one process this week and follow it from start to finish. You'll probably find your own version of Sarah. More high-signal conversations coming next.
    Show More Show Less
    22 mins
  • Why Your Best Employee Might Be Compensating for a Broken System

    Why Your Best Employee Might Be Compensating for a Broken System
    Oct 8 2026

    This week, Jordan goes solo again to talk about a category of work that never shows up on an org chart: the checking, chasing, reminding, and reconciling that keeps a business running even though nobody assigned it to anyone. He walks through a hypothetical operations manager named Sarah, the kind of person every business has, who ends up compensating for a dozen invisible gaps a day without anyone realizing it's even happening.

    Jordan argues this "invisible work" might be one of the biggest blind spots when it comes to finding real opportunities for AI, because if you only look at job descriptions and process maps, you'll never see it. The real question isn't whether an AI agent could do Sarah's job. It's why that work exists in the first place, and once you can see it, you can finally decide what should happen to it.


    Episode Timeline & Highlights

    [0:00] – Opens by describing a category of work that doesn't appear on any org chart, job description, or process map

    [0:26] – Describes this as "the work between the work": checking, chasing, remembering, reminding, coordinating, and moving information around

    [1:07] – Points out most businesses only think about work in terms of formally defined departments like sales, customer success, finance, and operations

    [1:39] – Introduces a hypothetical operations manager, Sarah, described as indispensable because she knows how everything actually works

    [2:11] – Walks through Sarah's day: she notices an incomplete customer step nobody asked her to check

    [2:35] – Sarah catches a data mismatch between two systems and has to figure out which one is correct

    [3:04] – Sarah recalls a customer's unusual arrangement from memory because the information isn't reliably documented anywhere

    [3:28] – Sarah tracks down a stalled task, discovers two people assumed the other was handling it, and gets it moving again

    [4:22] – Imagines Sarah disappearing for two weeks and the cascade of missed follow-ups and dropped context that follows

    [5:28] – Argues Sarah isn't just doing her job, she's compensating for gaps in how the business is architected

    [6:22] – Names this pattern "invisible work" and explains why it has to be recognized as work before it can be redesigned

    [8:20] – Points out Sarah's actual job description almost certainly doesn't mention remembering missing information, chasing failed processes, or reconciling systems

    [9:16] – Warns against just automating the compensation instead of fixing the underlying structural problem

    [10:13] – Distinguishes between invisible work that is legitimate and should be formally assigned, and invisible work that only exists because something else in the business is broken

    [13:08] – Offers a simple exercise: find the person everyone goes to when something gets stuck, and write down everything they actually do instead of their job description

    [14:47] – Closes with the idea that some invisible work will go to people, some to AI agents, some will be shared, and some should disappear entirely once it's actually visible


    5 Key Takeaways

    1. The checking, chasing, and reconciling your best people do all day is still real work, even when it's not in anyone's job description.
    2. Before handing invisible work to an AI agent, ask why that work exists in the first place.
    3. Some invisible work is legitimate and should be formally owned; the rest is just a symptom of something else being broken.
    4. Automating the compensation just makes a structural problem run faster, it doesn't fix it.
    5. Find your "Sarah" and write down everything she actually does in a day instead of her job title.


    Links & Resources

    • smrtPhone: https://www.smrtphone.io
    • That Real Estate Tech Guy: https://thatrealestatetechguy.com


    If you've got a Sarah in your business, this is the week to actually write down everything she does instead of just being grateful she does it. More high-signal conversations coming next.
    Show More Show Less
    17 mins
  • The Hidden Flaw in Splitting Work Between People and AI

    The Hidden Flaw in Splitting Work Between People and AI
    Oct 1 2026

    This week, that real estate tech guy himself, Jordan Samuel Fleming, goes solo to tackle one of the biggest questions AI raises for business owners: not what can a person or an AI agent do, but who should do it. Using a hypothetical AI sales agent named Daniel, he breaks down why the old dividing lines between "human work" and "AI work" are starting to fall apart.

    Jordan introduces the idea of shared execution, where a single responsibility gets carried by a mix of people and AI agents at different moments, based on what actually produces the best outcome rather than who has always done the work. It's a practical reframe for any business owner trying to figure out where AI actually belongs in their operation.


    Episode Timeline & Highlights:

    [0:00] – Opens with the real question replacing "who can do the work": who should do it

    [0:36] – Explains why, for most of history, work requiring judgment always landed on a person by default

    [1:15] – AI agents can now communicate, make decisions, exercise judgment, and manage relationships on their own

    [1:53] – Warns against drawing a simple dividing line between "human work" and "AI work"

    [3:05] – Argues the future workforce gets designed responsibility by responsibility, not by two separate lists

    [3:35] – Introduces a hypothetical AI sales agent, Daniel, fully trained on product, pricing, and qualification criteria

    [4:38] – A new lead arrives and Daniel handles the entire qualifying conversation with no need for a human

    [5:10] – Daniel flags something unusual: this deal could be worth half a million dollars

    [5:46] – The real question becomes not "can Daniel continue" but who creates the most value in this specific moment

    [7:26] – Flips the example: what happens if a company insists every one of 2,000 leads gets a personal follow up from a salesperson

    [8:02] – Points out Daniel may actually maintain relationships better than a person, with no forgotten follow ups

    [10:30] – Value belongs to whoever is actually contributing to the outcome, not to a category of worker

    [11:05] – Introduces "shared execution," where multiple types of labor intentionally share one outcome

    [13:15] – Distinguishes capability from suitability: being able to do something doesn't mean you're the one who should

    [14:56] – The labor split isn't fixed. An AI agent might start by owning 20% of a responsibility and grow from there

    [18:22] – Closes with the challenge: stop asking "could I do this" and start asking "who should do this, and why"


    5 Key Takeaways
    1. Ask "Who Should," Not "Who Can": As AI agents get more capable, the old question of who is capable of doing the work stops being useful. The real design question is who creates the best outcome in this specific moment.
    2. The Human vs. AI Line Is Dissolving: Clean categories like "AI does repetitive work, people handle relationships" feel comforting, but they don't hold up as agents get better at judgment, empathy, and context.
    3. Shared Execution Beats the Relay Race: The best model usually isn't an AI agent handing off to a person once things get hard. It's an AI agent and a person both staying involved in the same responsibility, moving in and out as the situation changes.
    4. Capability and Suitability Are Different Questions: Just because an AI agent, or a person, is capable of doing something doesn't mean they're the one best suited to do it. That decision comes from outcome, cost, risk, and context, not default habit.
    5. The Split Isn't Permanent: An AI agent might start by owning 20% of a responsibility and grow into 60% or more as it's trained and trusted. The goal isn't to maximize AI or protect people. It's to get the best outcome.


    Links & Resources
    • smrtPhone: https://www.smrtphone.io
    • That Real Estate Tech Guy: https://thatrealestatetechguy.com

    If there's one responsibility in your business you've been assuming needs a person just because that's who's always done it, this is the week to go take a second look. More high-signal conversations coming next.
    Show More Show Less
    20 mins
  • The Best Employees Have Clear Boundaries, Your AI Agents Need Them Too

    The Best Employees Have Clear Boundaries, Your AI Agents Need Them Too
    Sep 24 2026
    This week I want to introduce the second part of the framework I've been building across these videos: bounded responsibility. Think about the best person you've ever managed, someone you trusted with real autonomy. That trust almost certainly came from clear boundaries, not the absence of them. They knew what they owned, what information they had access to, what decisions they could make, and exactly when to bring someone else in.I walk through a detailed example: a customer success rep named Mark, given the vague instruction to "keep customers happy, use your judgment." That sounds empowering, but it actually forces Mark to constantly guess, ask permission, and learn the real boundaries through trial and error over time. Compare that to clearly defining his responsibility up front, the outcome he owns, the information he can access, what he's authorized to decide, and where he must escalate, and you'll find his autonomy actually increases. This is exactly the same conversation we need to have when handing responsibility to an AI agent, and I break bounded responsibility down into four elements: role, context, skills, and escalation.Episode Timeline & Highlights[0:00] – Thinking about the best person you've ever managed, and why you trusted them[0:28] – What actually makes someone trustworthy: clear boundaries, not the absence of rules[1:02] – Why AI management isn't an entirely new set of principles from human management[1:36] – Introducing bounded responsibility: being clear on what a worker is allowed to do, not just what they should do[2:16] – Why the word "bounded" matters, and how clear boundaries actually create autonomy[2:47] – Introducing Mark, a customer success rep given a vague, seemingly empowering instruction[3:11] – The problem: Mark has to constantly guess and ask permission on nearly every decision[4:32] – How Mark eventually learns the boundaries anyway, just slowly and informally[4:59] – Why that's actually a failure of design, not a success story about Mark[5:32] – Rewriting Mark's responsibility with real clarity: outcome, access, authority, and stopping points[6:34] – Why this actually increases Mark's autonomy instead of restricting it[7:08] – Introducing an AI customer success agent, Alex, capable of far more than he should be authorized to do[7:37] – Why "what can Alex do" is the wrong question, and "what should Alex be authorized to do" is the right one[9:09] – Confirming this is a labor architecture principle, not something unique to AI[9:50] – Applying bounded responsibility to a previously pulled-apart job: lead qualification[11:36] – A real edge case: what happens when a normally disqualified lead turns out to be worth half a million dollars[11:36] – Introducing the four elements of bounded responsibility: role, context, skills, and escalation[12:39] – Why access to everything isn't the goal, only the information needed for that specific responsibility[13:07] – Escalation as possibly the most important element: knowing exactly where a worker must stop[14:23] – How organizations quietly rely on tenure and unwritten rules to paper over undefined responsibility[15:40] – Why AI isn't creating the need for boundaries, it's exposing responsibility that was always poorly defined[17:25] – The exercise: does your best person perform well because of design, or because of tenure[19:03] – The four questions to ask about any responsibility: outcome, access, authority, and stopping point[20:01] – Why the future of work is designing the work itself, not separate systems for people and AI5 Key TakeawaysClear Boundaries Create Autonomy, Not Restriction — A worker who knows exactly what they own, what they can decide, and where to stop can act confidently without constant check-ins. Vague empowerment actually produces more hesitation and more escalation, not less."What Can They Do" Is the Wrong Question — Technical capability, whether in a person or an AI agent, isn't the same as authorized responsibility. The real question is what they should be allowed to do, not what they're capable of doing.Bounded Responsibility Has Four Elements — Role (the outcome owned), context (the information accessible), skills (the actions and decisions authorized), and escalation (where responsibility ends). Every one of these needs to be defined, not assumed.Escalation Points Prevent the Most Common Management Friction — Most frustration between managers and employees around "you should have handled that" or "you should have escalated that" comes from never actually defining where the boundary sits in the first place.Businesses Often Run on Tenure Instead of Design — If your best people perform well mainly because they've been there long enough to learn the unwritten rules, that knowledge walks out the door when they leave. Designing responsibility clearly protects against that risk, for people and AI agents alike.Links & ResourcessmrtPhone: https://...
    Show More Show Less
    22 mins
  • Why Automating Your Existing Processes Could Be a Mistake

    Why Automating Your Existing Processes Could Be a Mistake
    Sep 17 2026
    This week I want to challenge one of the biggest promises being made about AI right now: automation. It sounds great, take an existing process and make it faster with AI, but I think there's a question that gets skipped way too often. Should this process exist in the first place? When you automate a process without asking that, you're quietly assuming every step, every handoff, and every approval is actually necessary.I walk through a detailed example: a sales discount approval process, where a salesperson has to escalate a discount request to a manager because the manager holds the judgment and authority to decide. You can automate every step of that request and response cycle and make it much faster, or you can ask why the approval exists at all, and realize that once an AI agent understands your commercial boundaries, most of that back-and-forth can disappear entirely. This is the same mistake many businesses made during digital transformation: they digitized their paper processes instead of asking whether those processes should still exist. Pick one process in your own business this week, and instead of asking what you can automate, ask why each step exists in the first place.Episode Timeline & Highlights[0:00] – The big promise of AI automation, and the question that gets skipped[0:31] – Why automating an existing process assumes the process itself is correct[1:44] – Introducing the example: a sales discount that requires manager approval[2:07] – Walking through the current process: request, context gathering, decision, and response[3:06] – What an automation vendor would immediately offer to speed up that process[4:06] – The better question: why does the approval process exist in the first place[4:34] – The real reason: judgment and commercial boundaries live inside the manager's head[5:07] – Introducing AI labor trained on commercial policy, pricing, and customer history[5:40] – Setting clear boundaries: what an AI agent can decide, and what still escalates[6:14] – What happens to the approval process once those boundaries exist[7:29] – Comparing automating a process versus redesigning the work itself[8:01] – The digital transformation parallel: paper forms became digital forms, not new processes[9:33] – Why AI is a new source of intelligent labor, not just a faster way to move information[10:03] – The bigger question: how many of your processes exist just to move information between people[11:26] – Why your existing processes aren't sacred, just how work got done given past constraints[11:56] – Some processes should be kept, some automated, some redesigned, and some eliminated entirely[12:25] – Separating the actual work (a commercial decision) from the process steps built around it[13:01] – Why starting with the work avoids the traps hidden in technology, job titles, and process[13:57] – The uncomfortable discovery: some of what you're about to automate probably shouldn't exist[14:55] – Framing AI as a labor question rather than a technology question[16:00] – The exercise: pick one process, map its steps, and ask why each one exists[17:01] – Why the biggest AI opportunity might be realizing you don't need the process at all5 Key TakeawaysAutomating a Process Assumes It's Correct — Before making a process faster with AI, ask whether the process itself should exist. Every step you automate without questioning it carries forward whatever assumptions created it in the first place.Approvals Often Exist Because Judgment Lives in One Person's Head — A sales discount approval process exists because a manager holds context and authority a salesperson doesn't. Once that judgment can be captured in clear boundaries, much of the back-and-forth disappears.AI Can Own a Decision Within Defined Boundaries — Rather than routing every request to a person, an AI agent trained on your policies can approve straightforward cases automatically and escalate only what falls outside the boundaries you've set.Digitizing a Process Isn't the Same as Redesigning It — Many businesses made this mistake already during digital transformation, turning paper processes into digital ones without ever asking if the underlying steps still made sense.Your Processes Aren't Sacred — They're simply how your business learned to get work done given the people and systems available when they were created. Some deserve to be kept, some automated, some redesigned, and some should disappear entirely.Links & ResourcessmrtPhone (sponsor): https://www.smrtphone.ioThe AI Workforce: https://thefutureworkforce.aiThat Real Estate Tech Guy: https://thatrealestatetechguy.comThanks for tuning in to this one. If this got you second-guessing a process you were about to automate, that's exactly the point, pick one this week and ask why each step actually exists before you make it faster. Head over to thatrealestatetechguy.com for all the episodes and some great discounts on the tech we talk about. More...
    Show More Show Less
    18 mins
  • Why Automating Tasks Isn't the Same as Redesigning a Role

    Why Automating Tasks Isn't the Same as Redesigning a Role
    Sep 10 2026
    This week I want to go deeper into an idea I touched on before: your job descriptions might actually be hiding how your business really works. I use a detailed example, a salesperson named Jennifer, and follow her through an entire day to show that "salesperson" isn't really one job. It's a bundle of completely different kinds of work, administrative tasks, predictable execution, pattern recognition, and high-value human judgment, that all got stitched together simply because one person had to do all of it.Once you stop asking "how much of Jennifer's job can AI do" and instead pull the bundle apart into its individual responsibilities, initial contact, qualification, scheduling, nurture, negotiation, closing, you can make a much smarter decision about how each piece should actually be executed. This is part of what I call work architecture, the first section of my AI Labor Architecture framework in my new book, The AI Workforce. Try this yourself: pick one important person on your team, forget their title for 30 minutes, and just follow the actual work that crosses their desk.Episode Timeline & Highlights[0:00] – Where would you even start explaining how your business works?[0:35] – Why a job description shows how work got bundled, not what the work actually is[1:04] – Introducing Jennifer, a top salesperson, and her simple-sounding job title[1:32] – Following Jennifer through a full day: a lead comes in and she makes contact[1:58] – The research and qualification work: comparing a lead against past successful customers[2:25] – The scheduling grind: calendar links, availability, and the back and forth to book a meeting[2:57] – Preparing for and running the meeting, then handling objections when they don't buy right away[3:20] – The nurture and follow-up work that keeps an opportunity from disappearing[3:32] – Pricing, approvals, and contract negotiation on the way to finally closing the deal[4:04] – Breaking down the four different types of work bundled into "salesperson"[5:12] – Why intelligent work has always required a person, and how that shaped the modern job[5:41] – Jennifer's job title as simply the container used to organize the work, not the work itself[6:16] – Why "how much of Jennifer's job can AI do" is the wrong question to start with[6:49] – Pulling the job apart into its individual responsibilities: qualification, research, scheduling, and more[7:30] – What it looks like once each responsibility can be assigned independently[8:04] – The real shift: not replacing Jennifer, but no longer treating Jennifer as the architecture[8:40] – Why most businesses will preserve the same work bundles even after adding AI[9:46] – Why the assumption behind those bundles has now changed[10:17] – The exercise: pick someone important and follow their actual work, not their job description[10:52] – Why the real job usually isn't captured in the written job description at all[11:25] – What makes your best people better: the judgment and context nobody ever documented[12:01] – The risk of only automating obvious tasks and calling it a redesign[12:43] – Realizing a "job" might actually be six or twelve separate responsibilities[13:50] – Separating the work, the responsibility, and the execution once again[14:23] – Revisiting Jennifer: an incredible closer spending half her week on work that doesn't need her[15:20] – Where this shows up everywhere: managers as human routing systems, founders making decisions they should have handed off years ago[15:41] – Introducing work architecture as part of the AI Labor Architecture framework[16:27] – The 30 minute exercise: forget the title, follow the actual work[17:37] – Where to find The AI Workforce and get notified when it's available5 Key TakeawaysA Job Title Is a Container, Not the Work Itself — "Salesperson" bundles together administrative tasks, predictable execution, pattern recognition, and high-value judgment into one title, simply because a person had to do all of it. The title hides how different those tasks actually are.Stop Asking "Can AI Replace This Person" — That question treats a job as one unit. The more useful question is what the individual responsibilities inside that job actually are, so each one can be assigned to whoever or whatever executes it best.Job Descriptions Capture Activity, Not Judgment — What makes your best people valuable is usually the context and judgment they've built up that was never formally written down: knowing what to ignore, when to break the process, which customer needs a call instead of an email.Talented People Often Carry Work That Doesn't Need Them — A skilled closer spending half her week on scheduling and data entry isn't a personal failing, it's an architecture problem. Once the bundle is pulled apart, that mismatch becomes visible.Try the 30 Minute Exercise on One Important Person — Pick someone on your team, ignore their title, and track everything...
    Show More Show Less
    19 mins
  • Stop Asking What AI Can Do, Start Asking What Work Needs to Be Done

    Stop Asking What AI Can Do, Start Asking What Work Needs to Be Done
    Sep 3 2026
    This week I want to tackle a question I hear constantly from business owners, and I think it's actually the wrong question to be asking: "what can AI do in my business?" It feels reasonable given how fast AI capability is moving, but starting there makes AI the center of the conversation when it should be the work. Your business exists because of outcomes that need to be produced, not because of a tool that needs a job to do.This is the first part of what I call the AI Labor Architecture framework in my new book, The AI Workforce, and it's the starting point for every other decision that follows. If you try nothing else this week, pick one part of your business and ask what actually needs to happen there, not what an AI agent could do, and not even who's currently doing it.Episode Timeline & Highlights[0:00] – The common question business owners keep asking, and why it's the wrong one[0:57] – Why AI isn't the center of your business, the work is[1:28] – Reversing the question: from "what can AI do" to "what work actually needs to be done"[2:00] – Introducing the SaaS onboarding example[2:33] – What a CEO sees when a capable new AI agent looks able to handle onboarding[3:39] – Why "could she do onboarding" is still the wrong question, even if the answer is yes[4:12] – Breaking onboarding down piece by piece: information gathering, account setup, and interpretation[4:41] – What actually happens after setup: helping the customer understand what's been done[5:10] – The follow-up work: noticing when a customer gets stuck or disappears[5:49] – Why "onboarding" was always a bundle of very different kinds of work sitting inside one role[6:34] – A break to highlight smrtPhone, the show's sponsor, and its 5,000 free calling minutes offer[7:07] – Introducing AI labor as a way to unbundle execution from any one person[7:37] – What this actually looks like: an AI agent gathering information and following up consistently[8:06] – When a person still needs to be brought in, and why they'd have full context already assembled[8:47] – Why capability doesn't tell you how your business should be designed[9:18] – The real questions to start with: where judgment, consistency, context, and relationship matter most[9:57] – Why so much of the current AI conversation gets the order backwards[10:24] – The hiring analogy: choosing a job for someone because of their resume, not their fit[11:31] – Why businesses have always been built around people, and why that shaped how we see "the business" itself[12:07] – Separating three things that used to travel together: the work, the responsibility, and the execution[13:14] – Why the order matters: starting with the work, not the AI agent[13:56] – Introducing work architecture as the first part of the AI Labor Architecture framework[14:29] – Why capability comes later, after you understand your business and its outcomes[15:04] – Where to sign up to be notified when the book, The AI Workforce, launches[15:32] – The one exercise to try this week: pick one part of your business and start with the work5 Key TakeawaysStart With the Work, Not the Capability — Asking "what can AI do" makes the tool the center of the conversation. Asking "what work needs to be done" keeps the business's actual outcomes at the center, which leads to much better decisions about who or what should execute that work.Job Titles Hide Bundles of Very Different Work — A role like "onboarding specialist" looks like one job, but it's usually a bundle of distinct types of work, information gathering, interpretation, administration, education, follow-up, and exception handling, that only ended up together because one person had to do all of it.AI Breaks Apart Three Things That Used to Travel Together — Historically, hiring someone into a role answered three questions at once: what work exists, who's responsible for it, and how it gets executed. AI labor lets you separate those three and assign execution more intelligently.Capability Doesn't Tell You How to Design Your Business — Just because an AI agent can technically perform a task doesn't mean it should, and just because a person can perform something doesn't mean it's still the best use of their time.Judgment and Exceptions Still Belong With People — When you break work down clearly, predictable and consistent pieces are well suited to AI, while genuine complexity, judgment calls, and relationship-dependent moments are where a person should still be brought in, ideally with full context already gathered for them.Links & ResourcessmrtPhone: Listeners get 5,000 free calling minutes: https://www.smrtphone.ioThe AI Workforce: https://thefutureworkforce.aiThat Real Estate Tech Guy: https://thatrealestatetechguy.comThanks for tuning in to this one. If this got you rethinking how you look at a role in your own business, try the exercise: pick one part of it this week and ask what actually needs to happen, not what an AI...
    Show More Show Less
    17 mins