The tool does exactly what it's supposed to. The automation runs cleanly. The output is good. And nobody uses it.

I've seen this happen repeatedly across different types of businesses, different types of teams, different types of tools. The failure mode is almost always the same: the AI required people to change how they work, and people didn't.

This is the real AI adoption problem. Not whether the technology is good enough — it usually is. Whether you can get humans to interact with it consistently.

Why Behavior Change Is Expensive

Every new system asks for a behavior change. A new app to log into. A new process to follow. A new form to fill out. Sometimes it's small, but it accumulates. And for most teams, the gap between “we rolled this out” and “people actually use it” is filled with training sessions, reminders, Slack messages, and eventually quiet abandonment.

The tools that win adoption are the ones that slot into how people already work rather than asking them to do something different.

I ran into this with expense reporting. A client had a sales team that was supposed to log every company card purchase. The process existed. People were supposed to take photos of receipts, upload them to a shared folder, and fill out a monthly expense report. Straightforward enough on paper.

In practice, receipts got lost. The folder went unchecked. People remembered to file expenses at month-end and then spent an hour backtracking. The system worked, but the behavior wasn't there.

The Email Trigger

One of the things I show people when they're building AI workflows is a feature that I consider the most underrated trigger in Lindy: the custom email address.

Every Lindy workflow can have its own email address. You create the address, wire it to a workflow, and then anything forwarded to that address becomes an input the AI can act on.

The bookkeeping version is simple. You give your team an email address — something like expenses@your-company.lindy.ai. You tell them: “Forward your receipts here.” The receipt lands, the agent reads it, categorizes the expense, and updates the record. Done.

No new app. No login. No form. No training session. Just an email address.

Every person in a company already knows how to forward an email. That behavior exists. The email trigger makes that existing habit the entire interface.

The Story That Made This Click for Me

I was working with someone — let's call him Hudson — who had a painful expense workflow. Every business trip, he'd take photos of receipts, email them to himself, and then let them pile up until his admin manually sorted them into an Excel template. It worked, but it was slow and easy to fall behind on.

We set up a similar approach through Lindy's iMessage integration. He could text receipt photos directly to his Lindy assistant. When he was ready, he'd request a summary and get back an itemized Excel file and a PDF of all receipts — formatted exactly how his company needed it.

The reason it worked isn't that it was technically impressive. It worked because it met him where he was. He already had his phone out when he got a receipt. He already used iMessage. The AI just plugged into a behavior that already existed.

That's the pattern. Find the action people already take and make it the trigger.

Applying This Across Your Business

The email trigger works anywhere something already lives in someone's inbox:

Client inquiries: When a prospect emails you, forward it to a Lindy address that creates a CRM record, drafts a first response, and adds a follow-up task. Your team doesn't need to log into a new system — they just forward the email.

Vendor invoices: Forward an invoice to an accounting address that reads the amount, vendor, and due date, then adds it to your records. Finance teams can maintain their existing email workflow while the AI handles the categorization.

Team requests: Instead of asking people to submit tickets in a project management tool, give them an email address. Forward a request to the right address and it creates the task, assigns it, and notifies the right person.

Document intake: In legal, medical, HR, or any field where documents come in by email, a forwarded email can trigger intake, categorization, and routing without asking anyone to switch from email-based work.

In each case, the key is that you're not asking people to learn something new. You're attaching AI to something they already do.

The Principle Behind the Tactic

The Lindy email trigger is a specific implementation, but the principle is general: the best AI deployments work with existing behaviors, not against them.

This matters especially for teams where you don't control everyone's workflow. If you're a manager rolling out AI tools, or a consultant implementing automation for a client, you often don't have the ability to force a behavior change. You need adoption to happen because the tool is easy, not because you've mandated it.

When AI attaches to an existing habit — a forwarded email, a sent message, a file dropped in a folder — adoption happens passively. The trigger is just part of what people were already doing. The AI output is the new thing, but the input behavior is unchanged.

That's the framing I use now when I'm deciding how to trigger an AI workflow: what does this team already do, and can I make that the on-ramp?

The 4-Day AI Sprint covers how to build AI agent workflows — including how to design for adoption, not just automation.

I ran into it with my scheduling assistant.

I built an AI agent called Linda. She handles all my meeting coordination via email. When I need to schedule something with someone, I CC Linda on the thread. She checks my calendar, drafts a reply with available times, and books the meeting once we agree. No back-and-forth on my end. No checking calendars manually. The whole thing runs on autopilot.

It worked exactly as designed. Linda's language was natural. Her tone was warm. She handled rescheduling, confirmations, and follow-up without any issues.

And then someone told me: “This feels like a bot.”

The Problem With 60-Second Responses

Linda was replying within 60 seconds. Every time. Without fail.

That's not how people work. Real assistants get pulled into other tasks. They finish a sentence before opening a new email. They have a quick conversation at the coffee machine. They exist in the world, which means they don't reply in exactly 60 seconds to every single message.

Linda's language was human. Her decisions were human. But her timing was robotic. And people felt it, even when they couldn't articulate exactly what was off.

The feedback I kept hearing was some version of “This is too fast.” Not a complaint about what Linda said — just a vague discomfort about how quickly she said it.

The Fix Is Deceptively Simple

I added a 3-minute delay to the workflow.

Linda still processes everything the moment a message comes in. She checks the calendar instantly. She drafts the reply instantly. But she waits three minutes before hitting send.

That's the entire change. Three minutes.

After that, the feedback stopped. Linda just felt like a fast, responsive assistant — the good kind of fast, where you're pleasantly surprised rather than unsettled.

Why This Matters for How You Design AI Workflows

Most people building AI automation focus on the obvious things: the quality of the output, the accuracy of the response, the tone and language. Those things matter. But they're not the only signal people use to evaluate whether they're talking to a person or a machine.

Timing is a signal too. Behavioral patterns are signals. Anything that's perfectly consistent in a way humans can't be starts to register as off.

This creates an interesting design principle: sometimes making your AI less efficient is the right call.

Not slower in ways that make it less useful. But deliberately imperfect in ways that make it feel more natural. Humans aren't robotically consistent. If your AI is, that's worth examining.

This shows up in a few ways beyond just response timing:

Variation in output length. If your AI agent writes emails and they're all exactly the same length, that reads as machine-generated. Real emails vary. Some are two sentences. Some are a paragraph. Prompting for variation is a feature, not sloppiness.

Acknowledging context. A real assistant might say “Sorry for the delay, I was in a meeting” — not because there was actually a delay, but because that's how people communicate. AI agents that respond with pure transactional efficiency, no acknowledgment of context, feel thin.

Not having an answer to everything. If your AI assistant never says “Let me check on that” or “I'm not sure about this one,” it feels off. Real people don't always have immediate answers.

The Broader Principle: Human Trust Is the Real Metric

When I think about whether an AI workflow is actually working, the output quality is only part of the story. The more important question is: does the person on the other end trust it?

Trust gets built through many small signals. Speed is one. Language is one. Consistency is one. When any of those signals is too far outside normal human behavior, trust erodes — even when everything else is working correctly.

Linda scheduling a meeting in 60 seconds is impressive from a technical standpoint. But it's not the metric that matters. What matters is whether the person on the other end of that email thread feels like she's being helped by a person, or processed by a system.

The 3-minute delay turns impressive into trustworthy. That's the right trade.

Before your next AI workflow goes live: run it a few times and pay attention to the signals it sends beyond the content of its responses. Timing, consistency, variation — the things a real person would bring naturally are the things you might need to engineer deliberately.

The 4-Day AI Sprint covers how to design AI agent workflows — including the details that make the difference between automation that works technically and automation that actually earns trust.

The setup made sense. She loaded all her client programs into the knowledge base. Configured the bot with her tone and approach. Set it up to answer questions about nutrition, workouts, supplements, and how to follow the program.

Before she went live, I asked her one question.

“What do you think happens if a client asks the bot, ‘what's Emma's program?'”

She paused. “It wouldn't answer that… would it?”

I ran the test.

The bot answered in full detail. Emma's calorie targets. Her training split. Her supplement protocol. Everything another client should never see, delivered helpfully and clearly by a bot that was trying to do exactly what it was built to do.

The Bot Isn't Being Malicious. That's the Point.

This is the thing that makes this problem easy to miss and potentially serious: the bot isn't doing anything wrong by its own logic. It was given information. Someone asked a question it could answer. It answered.

It doesn't know the rules of your business. It doesn't know that client data is confidential. It doesn't know that one client asking about another client's program is a privacy violation. It doesn't know that in a medical or fitness context, sharing another person's health information could be a legal issue, not just an awkward situation.

The bot knows what you've told it. If you haven't told it that client information is private — specifically, that it should only ever discuss the person who is asking — it will answer with everything it has.

And it has everything you gave it.

The Blind Spot in Most AI Bot Deployments

When people build AI support bots, they focus on the use cases. What questions should the bot answer? What documents should it have access to? What tone should it use? How should it handle questions it can't answer?

These are the right questions. But they're incomplete.

The missing question is: what should this bot refuse to do?

Most bot deployments don't have explicit guardrails around sensitive information. They have good intentions and a knowledge base. That's not the same thing.

Consider what's common in AI support bot setups:

• A coaching or consulting business loads all client notes and programs into the knowledge base for easy access
• A medical practice uploads patient intake forms and treatment protocols
• A financial firm stores client portfolio summaries for advisor reference
• A legal practice indexes all case files and client agreements

In each case, the intention is for the bot to help the right people access the right information. But without guardrails, “the right people” is anyone who asks.

The Fix: One Instruction in the System Prompt

The good news is that the fix is simple. It's a single instruction added to the bot's system prompt — the foundational set of rules the bot operates by.

For the fitness coach's bot, the instruction was: “Only answer questions about the person who is currently asking. Never share information about other clients. If someone asks about another person's program, schedule, or any details not about themselves, tell them you can only discuss their own account.”

One sentence. That's all it takes to close a gap that could have caused a significant privacy incident.

But the instruction has to be explicit. The bot will not infer that client data is private from the nature of the content. It won't look at a spreadsheet full of client names and realize that each row should only be visible to the person it belongs to. You have to say it directly.

Building Guardrails as a Feature, Not an Afterthought

The broader principle here is that guardrails are something you design intentionally — not something that gets added after something goes wrong.

When I work with businesses on deploying AI agents, I always walk through what I call the refusal list before anything goes live. What should this bot refuse to do, regardless of what someone asks? The list typically includes:

Information scope: Only discuss topics and data relevant to the person asking. Never reference information about other users, clients, or accounts.

Sensitive categories: Never discuss pricing you're not authorized to disclose, internal business information, employee data, or anything the business hasn't explicitly approved the bot to share.

Escalation triggers: When a request involves something sensitive, uncertain, or outside the bot's scope, route to a human rather than attempting an answer.

Identity verification: If the bot has access to account-specific information, define how it should handle requests that seem misrouted or don't match the expected user.

This isn't a long list. But it's a list most people skip, because they're focused on getting the bot to work — not on the edge cases where it works in the wrong direction.

The Bot Is Trying to Help. That's the Problem.

When people hear about AI safety concerns, they often picture dramatic scenarios: bots going rogue, systems making catastrophic decisions, AI doing something clearly harmful.

The real risk in most business AI deployments is more mundane and more immediate. It's a bot that's working exactly as designed — helpful, responsive, thorough — applied to a situation its designers didn't think through.

The fitness bot wasn't failing. It was succeeding at a goal (answer client questions) in a context that nobody had scoped (don't answer questions about other clients).

Every AI bot you deploy needs two things: a clear job, and a clear set of limits. The job is what most people think about. The limits are what most people skip.

Before your next bot goes live: run the Emma test. Ask it a question it shouldn't be able to answer. See what happens.

Then add the guardrail before anyone else does.

The 4-Day AI Sprint covers how to build AI agent workflows — including system prompt design, guardrails, and how to scope what your agents should and shouldn't do.

He was driving between appointments, thought he had a clear afternoon, and glanced at his phone to find a string of missed messages. He'd completely missed what might have been the most important meeting on his calendar that week. Not because he forgot to check his schedule — because the context was scattered and nothing had surfaced it.

“If I keep doing this,” he told me, “important people won't take my calls anymore.”

That's the extreme version of a problem most professionals have in a quieter form. They show up to meetings technically on time but mentally unprepared. They spend the first few minutes of every call trying to reconstruct context they should have had before they dialed in.

Who is this person again? What did we last talk about? What was I supposed to follow up on from last time?

The meeting is already happening, and you're still getting oriented.

What a Prepared Executive Has That You Probably Don't

At a certain level of seniority, executives have executive assistants who handle meeting prep. Before a call, the EA pulls the relevant email history, researches the person, summarizes recent context, and puts a briefing on the executive's desk. The executive walks in already knowing the landscape.

For most people, that level of support doesn't exist. You prep for your most important meetings when you have time, and for the rest, you wing it.

The result is a low-grade inefficiency that's hard to measure but easy to feel: meetings that start slowly, conversations that cover the same ground as last time, relationships that don't advance as fast as they should.

The 30-Minute Notification

The fix I've built — and now set up for clients — is a simple automated notification that fires 30 minutes before each calendar event.

It surfaces three things:

Email history. The last relevant threads between me and the person I'm meeting. Not every email I've ever sent them — just the recent, relevant ones that give context for where we are.

The meeting agenda. If there's a description in the calendar invite or a prior document, that surfaces here. What's the stated purpose of this call?

Three talking points. Based on the email history and agenda, the agent suggests three things worth discussing — topics we've raised but not resolved, follow-ups from our last call, or open threads that fit the context.

The whole thing takes two minutes to read. I walk into every call knowing what was last discussed, what today is supposed to accomplish, and what I should make sure we get to.

What Used to Require an EA

This is what a good executive assistant would do for someone at a senior level. The research, the context-gathering, the briefing — these are tasks that require someone to understand your schedule, your relationships, and your priorities well enough to surface the right information before each meeting.

Building that kind of EA relationship takes months. It requires trust, training, and the ongoing investment of someone's time.

The automated version builds none of those things — but it does handle the research layer that most people lack. It's not a replacement for deep relationship support, but it solves the immediate problem: walking into meetings without context.

And because it fires for every calendar event automatically, not just the ones you remember to prep for, it catches the meetings that slip through.

Why Preparedness Compounds

There's an effect here that's easy to underestimate.

When you walk into a meeting prepared, the conversation starts at a higher level. You don't spend ten minutes re-establishing what happened last time. You pick up the thread. You reference something specific. You ask a question that shows you've been thinking about the relationship.

That signals something to the other person. It signals that you take the meeting seriously. That you're someone who follows through. That time with you is worth their time.

Over dozens of meetings, that impression compounds. Relationships advance faster. Decisions get made in fewer calls. Opportunities don't stall because the context got lost between conversations.

The prep notification isn't just a convenience. It's a forcing function for showing up at the quality level your relationships deserve.

Setting This Up

The core of this workflow is a meeting prep agent — an AI that reads your calendar, pulls relevant email threads for each upcoming event, and generates a brief before each call.

Here's what it needs to work:

Calendar access. The agent reads your upcoming events, including the agenda and attendee list from each invite.

Email access. The agent searches your email for threads involving the person you're meeting, filtered to recent and relevant messages.

A delivery mechanism. The brief needs to land somewhere you'll actually see it. A push notification, an email to your inbox, or a Slack message — 30 minutes before the meeting starts.

The quality of the output depends on your email history and calendar hygiene. If your calendar invites have good descriptions, the agent has more to work with. If your email threads with the person are substantive, the context will be richer.

Start with your highest-priority meetings. Build the workflow, test it on the relationships where prep matters most, then expand from there.

The client who missed that meeting eventually set this up for himself. His comment after the first week: “I feel like I have a new gear.”

That's the whole point. Not more discipline. Not a better to-do list. Just better context, automatically, before every call.

The 4-Day AI Sprint covers how to build meeting intelligence workflows — including the prep notification — using Lindy and your existing email and calendar setup.

It will write one. It will sound plausible. It will follow the narrative arc of a good story. And it will be completely fabricated.

This is one of the most common frustrations people run into when using AI for content — and one of the least talked about. The insights AI generates can be solid. The structure can be clean. But the moment you ask it to make the content feel human through a personal story, it invents something that sounds vaguely like you but isn't you at all.

There's a reason this happens. The AI doesn't know your stories. It's never had access to what you've actually experienced. So when prompted to add a personal anecdote, it does the only thing it can: it makes one up using patterns from what a story like that usually sounds like.

The solution isn't to avoid personal stories. They're what make content actually work. The solution is to give your AI content system access to real ones.

What a Story Bank Is

A story bank is a searchable database of real personal stories, automatically captured from your meeting transcripts and recorded conversations.

Here's how I built mine.

I record every meeting, workshop, and coaching session I run. Those recordings get transcribed. An AI agent then processes each transcript looking for personal stories — moments where I've shared something about my own experience. A deal that changed how I think about pricing. A client situation that forced me to rethink my approach. Something from growing up in the Netherlands that still shapes how I work today.

Each story gets extracted, summarized, and stored in a structured database with tags around the theme, the lesson, and the type of moment it represents.

Now when my content agent is writing a LinkedIn post and needs to illustrate a point with a human story, it doesn't guess. It queries the story bank. It finds a real story that matches the theme. It weaves it in.

The content becomes 100% authentic, 100% personalized, and traceable back to something that actually happened.

Why This Changes the Quality of AI Content

The difference between AI content with a story bank and AI content without one isn't subtle. When you read it side by side, the bank version feels like a person wrote it. The non-bank version feels like a person trying to sound like they have experiences.

Readers can't always name what they're responding to. But authenticity registers differently. When a story is real — specific to a real person, with real details — it creates a different kind of trust than a generic anecdote.

I was working with a client who was trying to use AI to build out their LinkedIn presence. Every time they asked the AI to add a story, it would invent something: a fictional investor they'd met, a made-up lesson from a startup they'd run. The posts were technically clean but felt hollow. After introducing a story bank and loading it with real experiences from their past calls and conversations, the difference was immediate. The content started attracting comments from people saying “this is exactly my experience too.” That's what real stories do — they find the people who've had the same experience.

The Source Material You Already Have

Most people don't realize how much story material they're already generating. Every call, every workshop, every recorded conversation is a source of stories. You tell stories constantly in meetings — when explaining your approach, illustrating a principle, answering a question about your background, talking through a client situation.

Those stories disappear into transcript files that nobody reads again.

The story bank doesn't require you to write anything new. It requires you to have a system that extracts what you're already saying.

For me, stories have come from:

• Consulting sessions where I described what changed in my thinking
• Podcast interviews where I answered questions about my background
• Workshop recordings where I used examples from my own experience
• Sales calls where I explained what I've seen work and what hasn't

All of that material is already sitting in recordings. The bank is just a way of making it findable.

How It Connects to Your Content System

Once the story bank exists, it becomes a resource for any content agent you're running.

The workflow looks like this: a content agent picks up a transcript or a topic to write about. It identifies the core insight. It searches the story bank for a story that illustrates that insight. It writes the piece using the real story as the hook or supporting example.

The content agent isn't creating fiction. It's doing what a good ghostwriter would do — finding the right true story from your history to make the point land.

Over time, as more transcripts get processed, the story bank gets richer. A year in, you have hundreds of stories across every theme you care about. Your content system has a growing library of authentic material to draw from instead of a blank page.

The Practical Starting Point

If you're already recording your calls and meetings, you have the source material. The next step is extracting from it.

Start simple: take your last 10 meeting transcripts and scan them manually for stories. Anything you've said in first person about something that happened to you. Put those in a spreadsheet with a brief description of the theme and lesson.

That's version one of your story bank. It's not automated yet, but you'll see how quickly the database grows — and how differently your content reads when you start pulling from it instead of asking AI to invent something.

The automation layer — having an agent extract stories continuously from new transcripts — comes second. But the database itself is valuable from day one.

The 4-Day AI Sprint covers how to build a content system that pulls from your story bank — including how to extract stories from transcripts and connect them to your content agents.

I was sending emails within 10 minutes of our meetings ending. Resources mentioned, next steps outlined, sometimes an introduction offered on the call already drafted and ready to send. They'd be wrapping up their own notes and my follow-up had already arrived.

The answer isn't that I have a special discipline for this. It's that I don't write the follow-up email.

My AI note-taker does.

The Gap in Standard Meeting Tools

Most people who use an AI note-taker get the same thing: a transcript and an email summary. That's actually quite useful — no more scrambling to remember what was said, no more spending 20 minutes writing out meeting notes by hand.

But there's a gap nobody talks about.

The summary tells you what happened. It doesn't do anything about what comes next. The follow-up email is still on your to-do list. You still have to write it. You still have to remember what you promised, find the link you said you'd share, recall the name of the person you offered to introduce them to.

And follow-up emails are one of those tasks that seems small until it's 6 PM and you're going through your list and you haven't sent it yet. Then it gets pushed to tomorrow. Then two days pass.

The research on this is pretty clear. Response time after meetings and sales calls has a direct relationship to conversion rate. The faster you respond, the more likely the business moves forward. The principle is the same as lead response time in sales — if someone reaches out to you and gets a reply within 15 minutes versus next-day, the outcomes are dramatically different.

What “Drafting the Follow-Up” Actually Looks Like

The meeting note-taker I use — built on Lindy — doesn't just summarize the meeting. During the call, if I mention something I'm going to send to someone (“I'll send you that YouTube video,” “I'll pass along that framework”), the agent catches it in the transcript.

When the meeting ends, two things happen.

One: I get the usual summary email.

Two: I get a drafted follow-up email, already written, already in my inbox.

The draft pulls together the specific items mentioned — the resource I said I'd share, any next steps I committed to, context from the meeting. It's not a generic template. It's personalized to what was actually said.

I open it, read it in 30 seconds, make a quick adjustment if needed, and send it. The whole thing takes under two minutes.

Clients see it arrive within 10 minutes of the call ending and ask how I do it. I tell them: I reviewed an email that was already written for me.

The Introduction Problem, Solved

There's another feature that's saved me more back-and-forth than I expected.

Introductions come up on calls constantly. “You should meet so-and-so.” “I know someone who does exactly that, I'll connect you.” Great intentions, easy to forget.

When an introduction comes up in a meeting, the agent drafts both emails involved in a double opt-in introduction.

The first email is to the person I'm introducing them to: “Hey, I was just on a call with [name] and thought you two should connect. Would you be open to an introduction?” The second is the actual introduction email, with both parties CC'd, ready to send if they say yes.

Both emails are in my inbox when the call ends. I can fire them off in five minutes or save them for later — but the drafting is done.

This matters because introductions are a high-value activity that most people underexecute on. The intention is always there. The friction of sitting down to write two separate emails to two separate people makes it easy to let the moment pass.

Action Items Without Admin

The third piece worth mentioning: anything discussed as a task during the meeting gets pulled out and sent to my project management tool.

If I say “I'll send that over by Friday,” it goes on my task list with a due date. If I ask someone on my team to handle something during the meeting, it gets assigned to them.

No separate meeting-to-task step after the call. No admin layer of re-reading the summary and turning action items into tasks by hand. The meeting ends and the tasks already exist where they need to exist.

The Difference Isn't Discipline

One thing I try to make clear when I show this to people: the speed isn't about habit formation or discipline.

I didn't train myself to follow up faster. I didn't build a system of reminders. I didn't restructure my schedule to block time after every meeting for follow-up.

I just changed what my note-taker does when the call ends.

The meeting is the work. The 45 minutes of admin that used to follow it — writing the follow-up, drafting introductions, moving action items to the right places — that's the part that's been eliminated.

What used to take 30-45 minutes of post-meeting work now takes 5. And the follow-up email arrives faster than it ever did when I was writing it from scratch.

How to Think About Your Current Setup

If you're using an AI note-taker and getting summaries, that's a good start. But ask yourself: what happens to the follow-up?

If the answer is “I still write it myself,” you're missing the highest-leverage output your meeting tool could be producing.

The note-taker already has everything it needs — the transcript, the commitments made, the items mentioned, the context of the conversation. Writing the follow-up email from that information is a straightforward task for an AI agent.

The only question is whether your current tool is set up to do it.

The 4-Day AI Sprint covers how to build meeting intelligence workflows — including the follow-up email drafting system — from the transcript all the way through to action items in your project management tool.

Pull data from Yardi. Reformat it in Excel. Write the narrative sections in PowerPoint. Add property maps in Canva. Merge everything together. Review the whole thing. Send.

Six steps. Three tools. Same process every quarter.

One of their team members said something that crystallized the problem for me: “If someone could teach us the method to automate this, it would be transformational.”

He wasn't wrong. But the bigger insight isn't about that specific workflow. It's about the mental model most people are missing when they think about using AI.

The Wrong Way to Use AI

Most people use AI as a helper. They write a draft, then ask AI to improve it. They do research, then ask AI to summarize what they found. They build a report, then ask AI to check it.

This keeps you in the seat for 100% of the work. AI is an occasional assistant. You're still the one doing the job.

That's not the worst thing — AI as a helper is genuinely useful. But it's not the most valuable way to use the technology. You're working the same way you always did, just with a smarter spell-checker.

The 10/80/10 Rule

When I work with clients on building AI into their workflows, I use a framework I call the 10/80/10 rule.

The first 10% is yours. This is where you set the direction. You define what a good output looks like. You give the AI the template, the data sources, the narrative guidelines, the context about who the audience is and what they need to see. You decide what “done” means.

This part can't be automated. It requires judgment, domain expertise, and taste — things that are uniquely yours at this point in AI's development.

The middle 80% is AI's. This is the execution layer: the data pulling, the formatting, the assembling, the first drafting, the populating of templates, the checking of sources. It's repetitive. It's time-consuming. It doesn't require creative judgment — just careful, consistent execution of a defined process.

AI does this better than humans at scale. Faster, cheaper, and without the cognitive cost.

The last 10% is yours again. This is where you review the output, apply aesthetic judgment, catch anything that's off, adjust tone, and give it the final polish before it goes out the door.

This is also the part where AI currently falls short. The technical term I use with clients is taste. AI can build the skeleton of a PowerPoint. It can draft a narrative. But it can't reliably tell you whether something looks polished, whether the language feels right for a specific relationship, or whether the framing is exactly on. That's still a human call.

What This Looks Like in Practice

For the real estate team, the 10/80/10 breakdown for their investor reports would look something like this.

The first 10%: a team member defines the report structure, sets up the template, and tells the AI what data sources to pull from (Yardi, the Excel files, specific property records). They specify what kinds of language investors expect and what the tone should be for each property type.

The middle 80%: the AI pulls the financial data, populates the template sections, drafts the narrative for each property, adds relevant details from the source files, and assembles the full document.

The last 10%: the team member reviews the draft, adjusts any numbers that need double-checking, tightens the language in a few places, and handles the final layout before it goes to investors.

The total human time on a report that used to take several hours becomes maybe 30-40 minutes of actual judgment work, bookending an AI-executed middle.

I've seen a similar pattern in a medical office building brokerage I worked with. Before each sales call, their team used to spend time researching comparable sales data for the specific property. Pull the comps manually, format them, review them. Now the system pre-pulls and formats all of that before the call is even scheduled. The salesperson reviews it in two minutes. Then they go into the conversation already prepared.

Same output. A fraction of the human time.

The Part That Stays Yours

One thing I want to be clear about: the last 10% is not just a formality.

There's a version of this model where people assume AI will get to 100% eventually, and the review phase will disappear. Maybe — but not yet, and maybe not for the things that matter most.

The places where AI still struggles are judgment calls that require domain expertise and taste. Knowing that a particular investor prefers conservative language over optimistic projections. Knowing that a specific word choice will read as too formal for a longtime relationship. Sensing when a document's structure is technically correct but doesn't quite flow.

These are things you know because of who you are and what you've seen. They're not easily transferable to a model.

The good news: that last 10% is often the most valuable part of what you do. The AI handles the 80% of work that, honestly, you could train almost anyone to do if you had time to train them. What you keep is the piece that actually requires you.

The Setup Upfront

The honest part of this model: getting to 20% of the work requires real investment upfront.

You have to map the process clearly enough that AI can follow it. You have to build the templates. You have to connect the data sources. You have to write the guidelines that define what a good output looks like.

This is what I call the Automation Spectrum — the process of moving work from manual execution to AI execution requires documenting the repeatable backstage layers first. You can't automate what you haven't defined.

That documentation phase takes time. But most people already know their process well enough to describe it — they just haven't written it down.

The output of that work: a workflow where you make the call at the start and review the result at the end. AI handles everything in the middle.

Start With Your Bottleneck

The simplest way to begin: think about your most repetitive work output. The report you assemble every week. The briefing document that requires pulling from three different sources. The proposal template you customize for each client.

Pick one. Map the steps. Identify which of them require judgment and which are just assembly.

That middle layer — the assembly, the formatting, the first draft, the data consolidation — is your 80%.

Start there.

The 4-Day AI Sprint covers how to build the kind of AI workflows that handle the middle 80% — from mapping your process to connecting your tools to setting up the review layer that keeps you in control.

ChatGPT first, for initial ideation. Then Claude, for a technical perspective. Then Gemini, for creative angles. Then Grok, for unfiltered feedback. Every model gives him different insights that the others miss.

When he first described this to me, I asked why he didn't just use one. His answer: “They each see things differently. I get four distinct viewpoints.”

He'd independently arrived at the same principle I keep coming back to when building AI systems: one generalist beats five specialists at nothing.

The One-Agent Trap

The natural instinct when building your first AI agent is to make it capable of everything. Handle my email, do research when I need it, draft content, answer client questions, help with scheduling. One powerful assistant.

This is the same impulse that produces chaotic job descriptions for humans. “Must be a strategic thinker, detail-oriented executor, creative problem-solver, and strong communicator” — which usually means the job is four roles bundled into one.

AI agents have the same problem. When you give one agent multiple jobs, you force it to context-switch constantly. The instructions get long and complicated. The agent has to decide at each moment which “mode” it's in. Errors compound.

And when something goes wrong, you don't know which job caused the failure.

The Librarian Analogy

Here's the mental model I use instead.

Think about a library. You have books, and you have librarians. Now imagine you only hired one librarian, and they're responsible for every section — fiction, science, law, history, reference, periodicals, all of it.

That librarian will give you okay answers on everything. But you'll never get the depth you'd get from a specialist.

Now imagine you have five librarians, each assigned to their section. The fiction librarian has read everything in their stacks. They know which books cross-reference each other. They know which authors are relevant to your question. They read their section differently because it's all they do.

Same books. Different librarians. Way better answers.

Your AI agents are the librarians. The books are your data, your workflows, your content — whatever they're working with.

When I was working with Blake Eastman on his content system, he'd built one agent to do everything. It read all his content and was supposed to generate Instagram posts, find interesting facts, create carousels, and write threads. It did all of it at a mediocre level.

I stopped him and rebuilt it as three separate agents: an idea finder (reads the content, surfaces the most interesting angles), a hook generator (turns those angles into strong opening lines), and a carousel formatter (takes approved hooks and formats them for the specific platform). Same content library. Three specialized librarians.

More files to manage. More agent configurations to maintain. But each one reliably does its job.

The Same Principle Applies to Models

This isn't just about building agents — it's about how you use AI models day to day.

Most people pick one model and use it for everything. But each model has genuine strengths. ChatGPT is strong for general work, brainstorming, and daily tasks. Claude is better for technical work and coding. Gemini handles visual analysis and works better on large documents. Grok is faster for real-time research.

I've started selecting models per task the way you'd select the right tool from a toolbox. When I build multi-step agents, I even pick different models per step: a cheaper, faster model for research steps, a stronger model for final synthesis.

The best practitioners don't ask “which AI should I use?” They ask “which AI is right for this specific job?”

What an Agent That Knows Its Job Looks Like

There's a test I use before building any agent: can you write its job in one sentence?

Not a paragraph. One sentence.

“This agent reads incoming emails and categorizes each one as archive, draft, or snooze.” Done. That's a tight, scoped agent.

“This agent handles my entire workflow and helps me with whatever I need” — that's not an agent. That's a hope.

The cleaner the job definition, the better the agent performs. When an agent can't explain its own role and boundaries clearly, it's not ready. You'll spend more time fixing its mistakes than you save from having it.

Building Your First Specialized Stack

The place to start is your current catch-all agent, if you have one.

What does it actually do most of the time? Find the one or two tasks it handles most often. Pull those out into their own agent. Give each one a tight prompt, a clear job, and only the data it needs to do that job.

You'll end up with more pieces. But each piece will work better.

The library gets better as you add more specialist librarians. The books don't need to change — just who's reading them.

The 4-Day AI Sprint covers how to build a multi-agent setup from scratch — including how to scope agents, connect them, and build the kind of stack where each piece does one job reliably.

Visit www.asianefficiency.com for more productivity tips and tactics.

Get 20% off your first order at dripdrop.com — promo code: TPS

Links

• DripDrop — promo code TPS for 20% off your first order
• 25X Productivity Coaching

If you enjoyed this episode, follow the podcast on Apple Podcasts, Spotify, Stitcher, Overcast, Pocket Casts or your favorite podcast player. It’s easy, you’ll get new episodes automatically, and it also helps the show. You can also leave a review!

None of that stopped me from being invited into early-stage investment deals not available to the public.

How? Relationships. Specifically, the 45+ dinner parties I started hosting in Austin after I read a book about what people say on their deathbeds. One consistent theme: happiness comes from relationships. I took that seriously and started building them deliberately.

People started asking me to make introductions. Introductions led to deals. Deals led to a seat at tables I had no formal credentials to be at.

I've spent the last few years connecting founders with capital — angel checks, seed rounds, mostly $25K to $250K in the Texas ecosystem. And along the way, I've noticed something consistent: investors write checks for a lot of reasons that have nothing to do with the financial projections on slide 8 of your deck.

The Real Reasons People Invest

Learning tuition. Some investors, especially those entering a new space, write small checks as an educational investment. A $10,000 or $25,000 check buys them cap table access, founder updates, and an inside view of how that industry operates. They read every newsletter. They attend every investor call. The return on education often exceeds the financial return, and they know it going in.

I did this once with a CPG startup. I put in a small amount with zero expectation of a big financial return. But I learned more about consumer packaged goods in one year of quarterly updates than I would have in a year of reading articles. That knowledge paid off in ways the investment itself never did.

Cap table association. If a well-known investor is in a round, being in the same deal carries social weight. “I'm invested alongside [name]” is a statement. It says something about who you know, who you're trusted by, and what rooms you can be in. Some investors write checks specifically to be associated with certain people. The financial logic is secondary.

Access to the founder's network. A check buys a relationship. A founder who knows 200 investors, executives, and operators can make introductions that a cold email can't. Some investors are thinking less about the company's upside and more about who the founder will introduce them to. The investment is a relationship-opener.

Genuine excitement. One investor told me directly: “This is my entertainment budget.” He found the company interesting. He liked the founder. He wanted to stay engaged with something that excited him. He wasn't particularly focused on when or whether he'd get his money back.

There's nothing wrong with any of these motivations. They're all honest. The problem is when founders assume every investor is primarily motivated by IRR.

What This Means If You're Raising Money

If you're a founder, ask more questions before pitching. Not “what are you investing in these days?” but “what are you hoping to get out of deals like this?” or “what made you interested in this sector?”

The answers will tell you a lot. Someone who says “I've been wanting to understand how this space works” is a different conversation than someone who says “I'm looking for a 3-5x in 5 years.” Not better or worse — different. You can have the right conversation instead of the wrong one.

The other thing it tells you: financial projections are not the whole pitch. The relationship matters. The access matters. The story of who else is in the round matters. These aren't soft factors. For a lot of investors, they're the primary factors.

What This Means If You're an Investor

It's also worth understanding your own motivation before you write a check.

Are you primarily looking for financial returns? That shapes how you structure the deal, what terms you negotiate, how patient you are.

Are you investing to learn? Then focus on deals in industries you want to understand, and be honest with the founder that you're there partly for the education.

Are you investing for access or association? Make sure the relationship value you're expecting is something the founder actually offers.

I've seen things go sideways when the investor expected ongoing introductions and relationship management and the founder expected a passive LP. Both had different mental models of what the check meant.

Clarity upfront prevents friction later.

The Bigger Pattern

Money moves through relationships. Always has. In my experience, the investors who write checks for purely financial reasons — the ones who see every deal as a spreadsheet — tend to be the most difficult to work with and the least satisfied with outcomes.

The ones who are in it for access, learning, excitement, or association — they tend to be easier to work with, more patient, and often more helpful. Because they're already getting what they actually came for.

That doesn't mean financial returns don't matter. They do. But they're rarely the only thing, and often not the main thing.

Next time you're pitching an investor — or being pitched by one — try to find out the real reason they're in the room. It'll change the whole conversation.

He had transcripts. Good note-taking setup. Granola recording everything.

But the follow-ups weren't happening.

Introductions he'd promised in Monday's call were forgotten by Wednesday. His CRM was three weeks behind. People he'd met were following up with him, and he had no idea what they'd even talked about.

The problem wasn't capacity. He was showing up to every meeting. He was having the right conversations. The problem was post-processing — extracting what mattered after the conversation ended and turning it into action.

Most people have this problem. And most people treat it as three separate problems.

The Three Sizes of the Same Problem

Here's the mental model I use now:

There are three scales of meeting:

The 1-hour call — a recorded Granola meeting with one or two people. Well-defined agenda. Clear start and end. Usually has action items, follow-ups, and things to log.

The 2-hour social event — a happy hour, networking dinner, or group gathering. Less structured. Multiple conversations. New contacts made. Phone numbers exchanged. Looser on logistics but often higher-value for relationships.

The 3-day conference — a full event. Dozens of conversations. Formal sessions mixed with hallway conversations. Biggest input volume. Hardest to process but also highest stakes for follow-through.

The instinct is to treat these as completely different challenges. The 1-hour call feels manageable. The conference feels overwhelming. So people build elaborate systems for conference follow-up and ignore daily meeting notes, or vice versa.

But they're the same job at different scales.

Every one of them has the same post-processing task: extract the people you need to follow up with, the ideas worth keeping, the tasks you committed to, and the things others promised you — before they fade.

One Workflow, Three Scales

Once you see that it's the same workflow, the solution is cleaner.

Build one post-meeting processing system. Apply it at all three scales.

The core steps are the same regardless of input size:

1. Pull the transcript — the recording, the notes, whatever captured the raw conversation
2. Extract people — who did you meet, what's the relevant context, what follow-up do they need
3. Extract commitments — what did you say you'd do, what did they say they'd do
4. Extract ideas — anything worth thinking about later, seeds of projects, things to research
5. Trigger follow-ups — draft the emails, queue the CRM updates, create the tasks

At the 1-hour call level, this takes a few minutes or can be fully automated. At the conference level, it takes longer — but it's the same five steps, just more inputs.

This is what I call the Transcript First principle. The transcript is the starting artifact. Everything useful that comes from a meeting — follow-ups, contacts, content, action items — flows from that single source. If you don't have a system that starts with the transcript, you're operating with low context quality and relying on memory to fill the gaps.

What This Looks Like in Practice

For the connector I mentioned: we built one workflow. When he says “I'll introduce you to someone” in a call, the agent flags it and drafts the intro email, dropping it in his inbox for review. After every call, key details get logged to his CRM. Same workflow at every meeting.

For conference follow-up, the same structure expands. Instead of processing one transcript, you're processing the Granola recordings from the week plus any notes you captured at sessions. The agent runs the same extraction — people, commitments, ideas, follow-ups — just over a larger input.

The output is the same shape. A set of drafts to review and send. A CRM that's up to date. A task list reflecting what you actually agreed to.

The thing I've noticed: 95% of meeting recordings just sit in people's archives, unused. The transcript is there. The context is there. It just never got turned into action.

Building even one post-meeting automation — just a follow-up email draft, nothing fancy — changes this immediately.

Starting Small

The place to start is your next 1-hour call.

After it ends: paste the transcript into a prompt that extracts three things. Commitments you made. People to follow up with. Ideas worth noting. That's it.

Do that a few times manually. See what the output looks like. Then automate it — a Lindy agent, a Zapier flow, a ChatGPT custom action — and have it run every time a meeting ends.

Once the 1-hour call workflow is solid, the same structure handles the happy hour, and eventually the conference. You're not building three systems. You're scaling one.

Same workflow. Different input size.

The 4-Day AI Sprint includes a full module on building meeting automation — transcript processing, follow-up drafts, and CRM updates. If you're still manually processing your meeting notes, that's a good place to start.

We took everything: podcast transcripts, course materials, blog posts, frameworks he'd developed. Loaded it all into a single knowledge base. Now, when his team needs to write something, or create a presentation, or check what he's said about a particular topic, they query the knowledge base instead of interrupting him.

The power wasn't just the retrieval. It was the centralization. Everything in one place, always current, accessible to everyone who needs it.

That same principle applies to your AI agents — and most people are doing it the inefficient way.

The Problem with Isolated Agents

When most people set up AI agents, they configure each one separately. The email agent gets the company background baked into its system prompt. The scheduling agent gets preferences and guidelines. The client support agent gets product details and pricing. Each agent has its own little pocket of context, isolated from the others.

This works fine at first. But it breaks down the moment anything changes.

A new team member joins. You move to a new office. A pricing policy shifts. A client changes their contact info.

Now you have to update every agent that contains that information. Hunt through system prompts. Remember which agent had which version of the details. Edit them one by one and hope you didn't miss anything.

I've seen people managing 8-10 agents start to dread making any changes because the maintenance burden is so high. They let the context go stale rather than face the update process.

The Shared Doc Solution

The fix is simple: one Google Doc.

You create a single document that contains all the context your agents share — business background, team roster, current policies, preferences, addresses, anything that applies to more than one agent. Then instead of pasting that information into each agent's system prompt, you load the Google Doc into the knowledge base of every agent.

Now when something changes, you update the doc. That's it.

Every agent that references the shared doc automatically has the new context. One update, everywhere, instantly.

I walked through this with Evan Baehr last December. He was running several agents across different areas of his business, and every time something changed — a new building came online, the team structure shifted — he'd have to touch each agent individually. Switching to the shared doc model was an immediate unlock. Update the doc, done.

What to Put in the Shared Doc

Think of this as your master context document. What does every agent need to know?

The basics usually cover:

• Business name, address, and contact info
• Team member names and roles
• Core services or products and how they work
• Communication preferences (how you like emails written, what tone to use)
• Current active projects and their status
• Key clients and relevant context about them
• Any recurring policies or rules that agents need to follow

You don't need every detail in the shared doc — only the things that multiple agents need. Specialized context that only applies to one agent can still live in that agent's individual knowledge base.

The shared doc is for the common layer. The stuff that should be consistent everywhere.

This Is What Centralized Context Means

There's a broader principle here that I call Centralized Context.

Most agent failures aren't about prompting or model selection. They're about fragmented, outdated, or missing context. The agent doesn't know what it needs to know. Or it knows something that was true six months ago but isn't anymore.

The solution is a durable memory layer that all agents can read from — and that's easy to update. Not a dozen separate system prompts you have to maintain. A readable document that acts as the single source of truth.

This is why Google Docs work well for this. They're readable. They're editable without any technical setup. Any agent platform that supports knowledge base loading (Lindy, CustomGPT, and most others) can reference a Google Doc. And you can keep it current without touching any agent configuration.

The decision hook I use: if multiple agents need the same truth, centralize it.

Setting It Up

The setup takes about 20 minutes.

Create a new Google Doc. Write out the shared context — business details, preferences, anything that applies across agents. Make it readable and specific. Don't write it like a legal document. Write it the way you'd brief a new assistant on their first day.

Then go into each of your agents and add the doc to the knowledge base. In Lindy, this is the Knowledge section of the agent settings. Most platforms have an equivalent. You're pointing the agent to the doc rather than pasting the content directly.

Test it. Ask an agent a question it could only answer if it had read the shared doc. Confirm it pulls from the right context.

Then the next time you need to update something — a phone number changes, a new service launches, a team member leaves — you update the doc. One place. Done.

The Longer-Term Payoff

The real value isn't the first update. It's the tenth.

The first time you update the doc and watch all your agents stay current without any additional work, it feels almost like a trick. The fifteenth time, it's just how you operate.

Centralized context is one of those foundational patterns that doesn't have a dramatic demo moment — it's just consistently better infrastructure for everything you build on top of it.

If you're managing more than two or three agents and still configuring them individually, this is worth your afternoon.

The 4-Day AI Sprint covers how to build agents that stay in sync, including the shared context doc setup. If you're building your first agent stack, that's a good place to start.

So I built something in Lindy that would let her call a number, have the agent read her emails out loud, and respond by voice. “Archive that.” “Draft a reply.” “Snooze until tomorrow.”

It worked. But here's what I learned building it: the routing logic is where most people get stuck. Not the voice part, not the AI writing part. The part where you tell the agent what to do with an email.

Most people build conditions. And conditions cause problems.

The Condition Problem

When you're new to email agents, the natural instinct is to build rules. One condition for refund requests. One for scheduling. One for support issues. One for partnership inquiries. You think: if I cover every type, the agent will handle everything correctly.

The problem is how conditions work.

They process sequentially. The agent checks condition one, then two, then three. In order, every time. So if your first condition is “check for refunds,” and someone sends you an email that says “I bought a shirt last week and ended up returning it, but by the way I'm having trouble downloading your app” — the agent sees “refund” first. Flags it as a refund request. Routes it to the wrong bucket.

The person needed help with the app. But you're looking at a refund queue item.

This is what I call a false positive. And the more conditions you have, the more false positives you get. I've seen people with 12-15 conditions whose agents still misfire on a regular basis. They keep adding more conditions trying to patch it. It doesn't work. The logic just gets more fragile.

The Fix: One Agent Step

The better approach is to delete all your conditions and replace them with a single agent step.

Instead of a rule-based flowchart, you give the agent one job: read the email, understand what's actually being asked, and output one of three decisions.

Archive. Nothing needed. The email is informational, automated, or doesn't require a response. File it away.

Draft. Something requires a response. The agent writes a draft, and you review it before anything goes out.

Snooze. You need to handle this, but not right now. Set it aside to come back to.

Three options. That's the whole framework.

The AI handles this much better than keyword-based conditions because it's reading the email, not scanning for triggers. It understands context. An email that mentions “refund” in passing but is really asking about an app issue will get correctly classified as a support question — because the agent read the whole thing and understood the actual intent.

Why the Draft Bucket Matters

The middle option, draft, is the one most people underestimate.

There's a real temptation to let the agent send emails automatically. And for some things, that's fine… automated acknowledgments, scheduling confirmations, simple responses to low-stakes messages.

But for most business email, you want a human in the loop before anything goes out. Reputation, relationships, nuance. These aren't things you want to fully delegate.

The draft bucket solves this. The agent writes the reply. You review it — takes 30 seconds usually. You hit send. You still get the time savings (no starting from scratch, no staring at a blank compose window) without the risk of the agent saying something you didn't intend.

Editing is faster than creating. That's the real value here.

How to Set This Up

After your email trigger in Lindy (or whatever agent platform you're using), add a single agent step with this instruction:

“Read this email and decide how to handle it. Output one of three options: ARCHIVE if no response is needed, DRAFT if a response should be written (then write the draft), or SNOOZE if this needs attention later. Base your decision on the full content and intent of the email, not just keywords.”

That's the whole thing. You can add specifics for your situation — “always draft if the email is from a client,” “always archive order confirmations from Shopify” — but start with the simple version and tune from there.

The results are almost always cleaner than what people get from a 10-condition flowchart.

The Bigger Lesson

This pattern applies beyond email. Any time you're building an agent to triage or categorize things, the rule-based approach hits a wall fast. Real-world inputs don't fit into neat buckets. Language is messy. People are messy.

An agent step that reads for intent is almost always more accurate than a chain of conditions checking for keywords.

Start with the simple version. Three options. One agent step. See how it works. Then layer on specifics where you actually need them.

Want to build your own email agent from scratch? The 4-Day AI Sprint covers this workflow in detail, including how to set up the three-bucket system and personalize it for your inbox.

In this encore episode, we break down four practical strategies for separating work and personal productivity — so you can actually be present at work when you're working, and present at home when you're not. If you've ever felt like you're always half-focused on two things instead of fully focused on one, this episode is your way out.

Visit www.asianefficiency.com for more productivity tips and tactics.

Sign up for a $1/month trial period at shopify.com/tps

Get 20% off your first order: dripdrop.com — use promo code tps

Get 60% off personal and family plans at keepersecurity.com/TPS

Cheat Sheet

• Top 3 Productivity Resources [1:28]
• Why keeping everything “together” is quietly wrecking your focus [3:26]
• The counterintuitive first move: cut before you organize [6:54]
• How to stop tasks and information from falling through the cracks [22:28]
• Build a system that makes distraction nearly impossible [32:24]
• Why “balance” is a trap — and what to pursue instead [41:10]

Links

• Shopify
• DripDrop — promo code tps
• Keeper Security
• 25X Productivity Coaching
• LegalShield
• Fantastical
• TripMode
• OmniFocus
• BusyCal
• Postbox
• Mailplane
• Spark
• Drafts
• Field Notes
• Instacart
• TaskRabbit
• Range: Why Generalists Triumph in a Specialized World by David Epstein
• TPS241 — Automate Your Life: How We Save Over 500 Hours/Year
• TPS242 — 4 Tools to Automate Your Technology and Save 100+ Hours a Year
• TPS282 — Web Automation: The Easiest Way to Be More Productive Online
• Why You Need to Color-Code Your Calendar — Asian Efficiency

If you enjoyed this episode, follow the podcast on Apple Podcasts, Spotify, Stitcher, Overcast, Pocket Casts or your favorite podcast player. It’s easy, you’ll get new episodes automatically, and it also helps the show. You can also leave a review!

At one point, I showed them what Gemini could do with their weekly project status reports. The owner of the business started immediately naming things: 30, 40 different ways he could use this across his properties and his team.

Here's what I showed him.

The Problem With Long Status Documents

This company sends project status updates every week. One document covering all active properties — what's on track, what's delayed, what needs a decision from leadership. Construction timelines, pending permits, budget flags, contractor notes. Fifteen-plus pages when you include everything.

The information is all there. It's accurate. It's detailed.

And most of the team skims it.

That's not a people problem. That's a format problem. When your status report is a long document, people have to read it linearly to find the part that affects them. Some will. Most will scan headings and stop when they find their section. A few won't open it until they have to answer a question.

The document works as an archive. As a communication tool — for getting your whole team aligned on status in real time — it's too slow.

What Happens When You Add a Visual

I took one of their status reports, fed it to Gemini with a prompt asking for a visual dashboard summary, and let the model render it.

What came back: one page. Every property listed. Status indicators — on track, delayed, decision needed. Key flags visible at a glance. The kind of layout you'd recognize immediately if you've seen a project management dashboard, but generated from a text document in about 30 seconds.

The reaction in the room was immediate. Everyone could take in the full picture at once. No hunting through pages. No skimming headers. Thirty seconds and the team had a shared understanding of where everything stood.

The owner started asking questions about which properties were flagged — not because he'd read the document, but because the visual made the flags obvious.

Why This Works

A long document and a visual communicate differently, and the difference matters.

A document says: “Here is all the information. Navigate it to find what you need.”

A visual says: “Here is the picture. Everything important is visible at once.”

Most status communications are designed for the person creating them — the person who needs to capture everything accurately. The format serves completeness. But the people receiving the update need something different. They need to orient quickly, identify what affects them, and move on.

The visual does that. The document doesn't.

What's interesting is that you don't have to choose between them. The document stays — it's the source of truth, the archive, the reference for anyone who needs detail. But you generate the visual from the document and distribute that instead. Recipients get the picture. They pull up the full doc if they need depth on a specific item.

How to Build This

The model I use for this kind of work is Nano Banana, which is Gemini's image generation model. It handles infographics, bento-grid layouts, status dashboards, sketch-note style visuals. You don't need a designer or design software — you describe what you want in a prompt and the model renders it.

For a project status visual, a prompt might look like:

“Create a visual dashboard summary of the following project status report. Include all properties as individual cards showing status (on track / delayed / needs decision), key upcoming milestones, and any flagged items. Use a clean, professional layout.”

Then paste the full document text. The model will interpret it and generate the layout.

The first version won't always be perfect. But you can iterate quickly — adjust the layout style, ask for different color coding, change what gets emphasized. A few iterations and you have something worth sending.

This works for real estate and construction, but it applies to any team sending long status updates. Product development teams with weekly sprint reviews. Operations teams with weekly reports. Project managers with multi-site coordination docs. Anywhere you have complex text-based updates that need to be quickly absorbed by multiple people.

The Broader Point

There's a version of AI productivity that's about making your own work faster — writing faster, researching faster, processing email faster. That's real and valuable.

But there's another version that's about making communication more effective. The status visual is in that second category. It doesn't save the person creating the update much time (though it saves them some). What it does is save everyone receiving the update significant time and cognitive effort.

That's a different kind of leverage. And it's one most teams haven't started using yet.

Thanh Pham is the founder of Asian Efficiency and an AI consultant based in Austin, TX. For more on using AI for team communication and project workflows, check out the 4-Day AI Sprint.

This wasn't a minor issue — the whole point of the agent was to give him a clear view of his upcoming week. If it's dropping events, it's broken.

I tried the obvious things. Rewrote the prompt. Added more specific instructions. Tested with a different model. Nothing worked.

Then I looked at what the agent was actually processing: 50 meetings' worth of data in a single pass. A full week of calendar entries, meeting notes, and context, all dumped in at once.

That's not a prompting problem. That's a size problem.

The fix was simple: stop processing a whole week at once. Run the agent on each day separately. Then combine the daily summaries into a weekly brief at the end. The task got smaller. The results got accurate.

The Diagnostic

After building enough of these agents, I've landed on a single rule for debugging AI performance:

Whenever your AI isn't producing the results you want, it's almost always too big. Break it smaller.

Not a better model. Not a more detailed system prompt. The task itself needs to shrink.

This sounds counterintuitive because most people's instinct when something isn't working is to add more — more context, more instructions, more examples. But the context window doesn't work like that.

Think of it as a sheet of paper. The AI can read everything on one sheet with full attention and accuracy. Once you start cramming more onto it — data, instructions, previous outputs, background context — it starts skimming. It misses details. It hallucinates. It produces outputs that technically address the prompt but miss the point.

Once you exceed about half the context window's capacity, performance degrades noticeably. Accuracy drops. Errors increase. And no amount of additional instruction fixes it, because the problem isn't the instruction — it's the space.

What This Looks Like in Practice

A client was running an agent to process a large business database and generate reports. The agent was working fine at a small scale. At larger volume, the quality started declining — outputs were getting vague, missing specific data points, producing results that felt generically correct but weren't reliably accurate.

Cost per query: $9. That's also unsustainable at scale, but the quality issue was the real problem.

We restructured the architecture. Instead of feeding the agent the entire database and asking it to figure out what was relevant, we pre-processed the data into smaller, use-case-specific slices. Each agent run got exactly the information it needed for that particular task — nothing more.

Same output quality. Cost dropped to $0.07 per query.

The AI didn't get smarter. It got a smaller problem to solve.

The Scale Test

I use a simple mental check when building any agent: how would I do this for 150,000 items?

If I can picture the architecture running at that scale without falling apart, it's probably designed right. If I can't picture it — if the approach only works because the dataset is small — I need to redesign before building further.

This scale thinking catches most architectural problems early. A weekly briefing that processes everything at once might work fine for a light week. But give it 50 meetings and it breaks. That's a sign the architecture was never right; I just hadn't stressed it yet.

Breaking into smaller components usually means one of a few things:

Chunking the data. If you're processing a week's worth of content, process it day by day. If you're processing a database, slice it by category or use case. The agent only sees what it needs for the task at hand.

Staging the workflow. Run one agent to extract raw data, a second to analyze it, a third to format the output. Each step gets a clean context window rather than inheriting the full weight of every previous step.

Filtering before processing. Instead of giving the agent everything and asking it to figure out what matters, filter the data first. Extract the relevant subset, then run the agent on that subset.

Any of these approaches can make a failing agent work. And they usually don't require touching the prompt at all.

The Real Problem With “Add More”

The reflex to add more — more context, more examples, more instructions — makes sense from a human perspective. When we need to explain something more clearly, we add detail. We think the AI works the same way.

It doesn't. The AI works better with less information that's more precisely relevant than with more information that's broadly related.

When an agent is underperforming, the question isn't “what else can I tell it?” It's “what can I take away?”

The answer to that question usually fixes the problem.

Thanh Pham is the founder of Asian Efficiency and an AI consultant based in Austin, TX. If you want to get better at building AI agents that actually work at scale, start with the 4-Day AI Sprint.

On Monday, someone told me AI clones are having a real moment. They've been building digital versions of themselves for content and sales outreach, and the results are working. The market's not as resistant as people expected.

On Thursday, someone else said authenticity is what's going to matter most over the next few years. AI-generated content is getting easier to detect and audiences can feel when something isn't real. The people building a genuine presence are going to win.

Both conversations made sense in the moment. Both people were smart and specific. I walked away from each call nodding.

I never connected them.

An AI agent caught it.

The Weekly Synthesizer

I built an agent I call the weekly synthesizer. It runs every Friday and reads every transcript I generated in the last seven days — calls recorded through Lindy, Granola, Otter, and a few other tools.

Most weeks that's somewhere between 10 and 20 conversations. A lot of transcript data. The synthesizer pulls all of it and generates a single document with three things:

Recurring themes. What topics kept coming up across multiple conversations this week? If three different clients all mentioned the same pain point, that's a signal worth noticing — even if none of those calls were directly related.

Outstanding action items. What did I say I'd do across my calls this week, and haven't done yet? A promise on Monday, a commitment on Wednesday, a follow-up I said I'd send on Friday — all of them in one place rather than buried in separate call notes.

Contradictions. Where did I hear opposing signals on the same topic from different people?

The AI clone vs. authenticity flag landed in that third category. The agent surfaced it with a note: these two conversations contain contradictory signals on the same topic. Worth investigating.

I would not have caught that on my own. Those were separate meetings on separate days with separate people. My brain had filed them as separate conversations. There was no reason I'd ever put them side by side.

Why Most Transcripts Die

I had a conversation with Evan Baehr a few months ago where he made an observation I keep thinking about. He realized that 95% of his Granola transcripts were just sitting there, never turned into documents. They were way richer than email — actual full conversation records — but he wasn't using them. The information existed but wasn't accessible.

The same thing happens with most people's meeting notes. The auto-generated summary gets created, maybe you glance at it once, and then it lives in some folder you never open again. The information technically exists. But it doesn't compound. It doesn't connect to anything else.

The weekly synthesizer is the layer that makes transcripts useful instead of just archived. Not by summarizing each meeting individually — you can do that easily with a basic Lindy agent. But by reading all of them together and finding what's invisible when you look at them one at a time.

What Gets Surfaced

The contradiction example is the one that surprised me most, but the recurring themes function is probably more consistently useful.

One week the synthesizer noted that four different conversations touched on the same topic: people feeling overwhelmed by the number of AI tools available and not knowing where to start. Those were conversations with a client, a podcast guest, someone I met at a networking event, and a person who emailed me a question. They had nothing to do with each other. But the agent read all four and flagged the pattern.

That became the topic of a workshop I built the following week. The signal was already there — I just needed something to surface it across conversations I'd stopped thinking of as related.

Action items are the other big one. I'm a fairly reliable note-taker during calls, but the notes live in different places. The synthesizer pulls all of them into one list, sorted by what I've committed to doing and what's still open. It's not a replacement for a task manager, but it's a good weekly audit of whether I'm following through on what I say I'll do.

How to Build One

The basic version of this agent doesn't require a complex setup. You need:

A consistent transcript source. Pick the tool you use most — Granola, Otter, or your AI meeting notetaker of choice — and make sure every call uploads to a folder your agent can access. The most common mistake is having transcripts scattered across five different apps. Pick one or two and route everything there.

A weekly trigger. Schedule the agent to run Friday afternoon or whenever your week naturally closes out. Give it access to the transcript folder.

A clear synthesis prompt. The prompt matters more than the tool. Tell the agent explicitly what you want it to look for: themes, action items, and contradictions. Without that structure, you get a summary of summaries, which isn't useful.

An output you'll actually read. Mine goes to email. A Google Doc also works. Wherever your weekly review happens, put the output there.

The more consistent your transcript pipeline, the more useful the synthesizer gets. In weeks where I have fewer calls, the output is less interesting. In busy weeks, it earns its keep.

The Broader Point

Most AI tools give you a better version of something you already had — faster email, cleaner notes, quicker research. The weekly synthesizer does something different. It creates a capability you literally didn't have before: the ability to read all your conversations at once and find patterns across them.

No human can do that in real time. You're in one meeting, then another, then another. The connections between them only exist in hindsight, and most of us don't have the bandwidth to make them manually.

The agent does. And it turns out there's a lot worth noticing in those connections.

Thanh Pham is the founder of Asian Efficiency and an AI consultant based in Austin, TX. If you want to build your own meeting intelligence system, the 4-Day AI Sprint walks through the fundamentals.

I'd share my screen and walk through the automation. Here's where Lindy receives the email. Here's the logic that categorizes it. Here's where it drafts a reply and waits for approval. Here's the trigger that fires when the client responds. Look at how all these steps connect.

And the client would nod, smile politely, and say: “That looks great. But what I really need is to get out of my inbox. Can you help with that?”

Every time.

Nobody Is Buying the Workflow

The mistake is thinking that clients care about the thing you built.

They don't. And why would they? They're not builders. They're operators with a problem, and the problem is usually some version of: I'm spending too much time on things that don't require my judgment.

The workflow is the solution to their problem, but it's not the same as showing them the solution. When you show a business owner a multi-step automation diagram, you're showing them the mechanism. They have to imagine what their life looks like after the mechanism runs. That's abstract. That's hard.

The only people who appreciate a beautiful workflow are other people who build workflows. If you're pitching to anyone else, you're speaking a language they don't care to learn.

The Switch That Changed Everything

I started using Nano Banana — Gemini's image generation model — to build visual assets showing what clients' operations would look like after the AI was in place.

Not how the automation works. What it produces.

A daily briefing that lands in your inbox at 6am with your three meetings, two key emails to answer, and a summary of anything urgent. A week where you don't have to chase a single follow-up because the agent handled it overnight. An inbox where 80% of the volume is already sorted, labeled, or drafted by the time you open it.

These are images — sometimes simple diagrams, sometimes more polished visual mockups. They're not screenshots of a Lindy workflow. They're pictures of the outcome.

The reaction changes completely. Instead of “that's interesting,” I started getting “wait — can you actually do that?” Which is a much better question to be answering in a sales meeting.

The Riverside Close

Riverside is a commercial real estate firm. They normally spend $200K on marketing videos when they want to promote a building under construction — the kind of polished production that shows potential tenants or investors what a space will look and feel like.

I had a two-day conversation with them. I used Nano Banana to turn their 2027 building sketches into photorealistic visualizations. Not a pitch deck. Not a proposal. Actual assets they could look at and feel. Renderings that showed what the finished space would look like, how people would move through it, what the energy of the place would be.

They hired me. Five figures.

It wasn't the workflow that closed it. It was showing them something real before anything was built.

“People invest in what they can see and feel, not just what they imagine.” That's the principle. And it applies to selling AI services just as much as selling architecture.

This Is a Positioning Principle, Not Just a Sales Tactic

There's a broader framework at work here.

The most effective way to build trust in any relationship — especially when selling something as abstract as AI consulting — is to lead with visible value before you ask for a commitment. Not a pitch, not a case study from someone else's business, but something the client can directly experience or see.

When you show a visual of what their operation could look like, you're not selling them on AI. You're selling them on their own future state. The AI is just the mechanism to get there. And once they can see that future state clearly, the mechanism becomes a detail they're happy to invest in.

The workflow is for building the thing. The visual is for selling the thing. Know which one you're presenting.

What to Start Showing

If you're consulting on AI and your demos involve screen-sharing a workflow builder, try replacing that with one thing: a before-and-after visual of one process.

Pick the process they complain about most. Show what it looks like now — chaotic inbox, manual CRM updates, hours spent on prep. Then show what it looks like after — the briefing, the clean inbox, the automated follow-up. Even a rough diagram works. The contrast is what matters.

Then ask them: is this the problem you're trying to solve?

If the answer is yes, you've just made the sale significantly easier. Because now they're not buying an abstract service — they're buying a specific picture of their life that they've already said they want.

Thanh Pham is the founder of Asian Efficiency and an AI consultant based in Austin, TX. The 4-Day AI Sprint covers the full consulting framework including how to pitch, scope, and deliver AI projects.

My first instinct wasn't to propose. It was to say: before I can tell you what to build, I need to see how you work.

So that's what we did.

The Observe-First Model

For any complex AI project — one with multiple departments, multiple tools, and real workflow dependencies — I use a flat-fee on-site day before I scope anything.

Here's what that day looks like:

I show up with no slides and no pitch. I walk their floor. I watch how things run. I sit with the team and ask questions — not the kind designed to identify upsell opportunities, but the kind designed to understand what's actually happening. I audit the tech stack they're actually using versus the one they think they're using (often different). I find out what breaks, what people do manually even though a tool supposedly handles it, and where the friction actually lives.

At the end, I deliver a report.

Not a sales deck. An actual report — specific recommendations, prioritized by impact, with enough detail that another consultant could implement them without ever talking to me.

The Counter-Intuitive Part

You might think that's a bad business decision. Why would you hand someone a full implementation roadmap?

Here's what I've found: they never use it to go hire someone else.

And it's not because the report is secretly vague or because I'm holding back the good stuff. The report is genuinely complete.

But the report isn't what they're buying. They're buying the context that only exists because I was there. I sat with their front desk coordinator. I watched the doctor flip between three different systems during a patient handoff. I know which team member is resistant and which one is secretly doing workarounds that no one else knows about.

That kind of understanding doesn't transfer in a document. The report proves I have it — but it doesn't hand it to the next consultant. So there is no next consultant.

Why This Works Better Than Proposals

The standard consulting model goes like this: prospect describes their problem, you propose a solution, you negotiate, you start.

The problem is that “prospect describes their problem” and “what's actually happening” are usually different things. Not because clients lie — but because nobody has perfect visibility into their own operations. They tell you what they think is the issue. The real issue often lives one layer underneath.

A proposal based on their self-diagnosis is a proposal based on incomplete information. Which is fine for simple projects. But for complex AI implementations, you're stacking automations on top of existing workflows. If you misread the workflow, you build the wrong thing.

The observe-first model inverts this. You understand first, then scope. The proposal that comes after a day on-site is sharper, more accurate, and usually more trusted — because the client watched you do the work of understanding their business before you told them what it needs.

On Pricing the Observation Day

The flat-fee observation day should feel like a fair trade for both sides. The client pays for your time and expertise. You get the access and context you need to propose something real.

I've found that clients who won't pay for an observation day often aren't ready for a full engagement anyway. They want a free assessment followed by a proposal they can use to compare vendors. That's a different kind of client — and not a bad one — but the observe-first model isn't designed for them.

The clients who engage with this model are usually the ones who already know their problem is complex and want someone who's going to take it seriously. Charging for the day signals that you do.

What I Took From Watching Good Leaders

The best business leaders I've observed don't make decisions from the conference room. They go see for themselves.

I heard about how the Whole Foods CEO would spend hours in stores, talking to employees and customers, before making decisions. Not because store visits were required — because firsthand observation changes what you prioritize.

Same thing applies in consulting. The days I've produced the sharpest recommendations are the days I didn't come in with assumptions to confirm. I came in with questions and let the operation tell me what it needed.

Propose after you've seen it. Every time.

Thanh Pham is the founder of Asian Efficiency and an AI consultant based in Austin, TX. If you're building an AI consulting practice, the 4-Day AI Sprint covers the foundations.

I checked my Lindy dashboard that Friday afternoon and it said: 102 hours saved.

That was the week I hit my goal. And the timing was a little funny, honestly.

But here's the thing I want to talk about — not the 102 hours. The ramp to get there. Because nobody shows you that part.

Where It Started

In February 2025, I started tracking how many hours per week my AI agents were saving me. Lindy has a weekly time savings report that goes out every Friday. I started paying attention to it.

Week one: about 1 hour saved.

Week two: 90 minutes.

Week three: 56 minutes.

That's… fine. An hour or two a week saved is genuinely useful. But it's not the dramatic number people talk about when they say AI is going to change everything. At that point I was skeptical about whether the ramp even existed.

The First Jump

In April, I implemented a new agent — something that was taking me significant manual time each week and I finally built automation around it. That week the Friday report came back with 45 hours saved.

I did a double-take.

I went from two hours to 45 hours in a single week. Not because I'd done anything dramatically different in my setup. Just because I'd added one well-targeted agent to the stack. The compounding had already been happening under the surface, and this new agent surfaced it.

After that, the numbers stopped being predictable. 17 hours one week, then 65, then 25, then 53, then 50. Up and down, but trending in one direction overall.

Turning It Into a Game

At some point I set a goal: 100 hours saved in a single week.

I don't know exactly when I decided on that number. 100 felt meaningful. A hundred hours is something like two and a half full work weeks for a typical employee. If my agents were replacing that much manual work in seven days, something real had shifted.

So I tracked it. Every Friday, I'd look at the report. Some weeks I was close. Some weeks I was further than expected. But I kept adding agents, fixing broken ones, stacking automations on top of automations.

This is what I think of as the “start small, iterate” principle in practice. You build the smallest reliable version first. Then you expand. The way I describe it internally: “life gets better one agent at a time.” Not one massive system deployment — one agent, working reliably, then another.

Thanksgiving week, the report came back: 102 hours.

What the Ramp Actually Looks Like

Here's why I think this matters more than the headline number.

When someone says “AI saved me 200 hours this month,” most people interpret that as: you set up AI, and immediately saved 200 hours. Like flipping a switch.

That's not how it works.

The real story is a slow build with occasional jumps. You start with one agent. It saves you maybe an hour a week. You add another. Maybe two hours. Then you add one that's targeted at a high-frequency task and the numbers jump — because frequency matters more than time-per-instance. A task that takes 5 minutes but happens 50 times a week saves more than a 4-hour task that happens once.

I saw this with a sales team I was working with last year. Their problem was post-call admin: every sales rep spent about 30 minutes after each call updating the CRM, creating tasks, drafting follow-up emails. The agent I built handled all of it automatically when the call ended. Day one: they saved 30 minutes per call. Month three: they'd added new conditions, new integrations, new outputs. The same base agent was doing more, and their reps had stopped thinking about the admin layer at all.

That's the ramp. It's not dramatic in week one.

The Part Nobody Talks About

The weeks where it barely moves are actually doing something.

You're learning which agents are worth building. You're building trust in the outputs — which matters, because an agent you don't trust is an agent you'll override manually, which defeats the point. You're figuring out where your actual time is going.

And then the jumps happen. You add the right agent at the right time, and the numbers surprise you.

The slow weeks aren't wasted. They're calibration.

What to Do With This

If you're just getting started with AI agents, the number to aim for in week one is not 100 hours. It's “is this thing working reliably?”

Pick one task that you do repetitively and that has predictable inputs and outputs. Build the simplest version. Run it for a few weeks. If it's working, add another.

The ramp builds itself once you're consistent. Thanksgiving week just reminded me of that.

Thanh Pham is the founder of Asian Efficiency and an AI consultant based in Austin, TX. If you want to build your own AI agent stack, the 4-Day AI Sprint is where most people start.

Not wildly — I'd ask ChatGPT what a fair range was, then ask Claude, then check with Gemini, and pick something in the middle. Which is a reasonable starting point. But it's basically still guessing.

What actually taught me how to price correctly was a simple experiment: I raised my price every single engagement until someone said no.

Not once. Not twice. But a few times in a row. That's when I knew I'd found the ceiling.

The “Raise Until No” Method

Here's the principle behind it.

If a client says yes too quickly and without hesitation, you've probably left money on the table. The best price isn't the one that gets instant agreement. It's the one where there's a brief pause, maybe a question or two, and then a reluctant yes.

If everyone says no, there are two possibilities: your price is too high, or your value isn't landing. Those are completely different problems. One is a pricing fix. The other is a positioning fix. Knowing which one is the issue tells you what to change.

The only way to find out is to keep raising until you hit consistent resistance. Then you know where the edge is.

For me, starting at $500 per workshop, raising to $800, and eventually offering agency services starting at $10,000 with top engagements reaching $45,000 — none of those numbers came from a spreadsheet. They came from seeing what the market would actually pay and adjusting upward each time.

The Referral Variable Nobody Talks About

Here's the part that surprised me more than the pricing method itself.

The same service can have two very different price ceilings depending on one factor: who sent the client to you.

I noticed this most clearly when I was working with the Padel Society on investor outreach. We were talking about who should bring in capital for the club. The dollar amount mattered, obviously. But who wrote the check changed everything — a well-connected athlete investor brought credibility, a story, and their own network. Generic institutional money brought none of that. Same dollars. Completely different value.

Consulting referrals work the same way.

When a highly respected founder sends me to one of their peers, I walk into that room differently. The peer has already made a preliminary decision about my credibility before we've exchanged a single word. The introduction carried weight. I don't have to earn basic trust from zero — I start from a much better position.

When a casual acquaintance sends me to someone, I start from scratch. Nothing wrong with that. But it's a different room.

The same work, the same quality, the same outcome — all worth more depending on where they heard your name.

What to Do With This

Two questions matter when you're figuring out what to charge:

First: What's the highest number they'd uncomfortably but willingly say yes to? Not the number that makes them shrug. The number that makes them pause and then nod. Find that number by raising your price until you hear consistent pushback.

Second: Who sent them? Be honest about the weight that referral carries. A client from a top-tier referral source can support a significantly higher price than the same client coming in cold.

These two things together — your market-tested ceiling and your referral quality — are what actually determine your real price. Not what you think you're worth. Not a pricing calculator. Not what someone else charges.

The market tells you, but only if you keep pushing until it pushes back.

One More Thing

Most people set their prices once and then leave them there for years.

That's almost certainly wrong, in both directions. Your skills compound. Your reputation grows. Your referral quality changes as you work with better clients and build relationships with more influential people. All of that should be reflected in your rates over time.

The “raise until no” method isn't just a one-time experiment. It's an ongoing calibration. Every quarter or two, test the ceiling again. You'll often find it's moved.

Thanh Pham is the founder of Asian Efficiency and an AI consultant based in Austin, TX. If you're looking to build your own AI consulting business, check out the 4-Day AI Sprint as a starting point.

When you write a prompt, the AI fills that sheet. As long as your instructions fit cleanly on that page, the model reads every word carefully. Clear context. High accuracy. Good output.

Now imagine cramming ten pages worth of instructions onto that one sheet. Smaller font. Denser text. Walls of context. The model still reads it — but it can't give every word equal attention. It starts skimming. It misses details. It loses track of what you actually wanted.

This is the context window problem most people understand. But there's a second problem that almost nobody talks about.

Even within a normal-length prompt, AI doesn't pay equal attention to everything you write.

The Primacy/Recency Effect

The primacy/recency effect is a well-documented phenomenon in human psychology. When people are asked to recall a list of items, they remember the ones at the beginning and the end much better than the ones in the middle. The middle fades.

AI language models have the same pattern.

I was teaching a session with Blake Eastman, and we got into context window mechanics. The insight that came up: AI models selectively attend to different parts of your prompt. The beginning gets high attention. The end gets high attention. The middle? The model skims.

This means your prompt has three zones, and they're not equal.

Zone 1 — The top: High attention. The model processes this carefully. Whatever you put here gets the most focus.

Zone 2 — The middle: Lower attention. Background context, supporting details, examples. Fine for supporting information, but the model's focus has drifted by now.

Zone 3 — The bottom: High attention again. Output requirements, format expectations, what to avoid. The model re-engages here because it's processing the final instructions before responding.

Why This Explains a Lot of Failures

Think about how most people structure prompts.

A common pattern: write a long setup paragraph explaining the background, then the actual task buried somewhere in paragraph three, then a few format preferences at the end.

The background gets read. The format at the end gets read. The actual task in paragraph three? Partially skimmed.

This is why you'll sometimes get AI outputs that technically respond to your prompt but miss the specific thing you asked for. The instructions were there — they were just in the middle.

How to Restructure Your Prompts

The fix is straightforward once you understand the zones.

Start with what matters most. Your role definition, the primary task, and the most critical constraints go at the very top. Don't warm up with background. Get to the point first.

Put supporting context in the middle. Background information, examples, data, and reference material belong here. The model needs it, but it doesn't need to process it with maximum attention.

Close with output requirements. Format, length, tone, what to avoid — these go at the bottom where the model re-engages. This is the last thing it processes before generating a response, so it's the best place for precision requirements.

If you use a framework like OCE — Outcome, Context, Expectations — this maps cleanly. Outcome at the top. Context in the middle. Expectations at the bottom. The structure isn't just logical, it's engineered to match where the model's attention is highest.

The Memo Analogy

Think of a well-written business memo.

It leads with the bottom line. The ask is in the first sentence, not buried in paragraph four. Then the supporting information and context. Then the action items or next steps at the close.

That structure exists for a reason — it matches how busy people actually read. They scan the beginning to decide if it's worth reading, and the end to see what's being asked of them. The middle is where the details live.

Prompts work the same way. The model is a busy reader. Structure for how it actually reads, not how you'd write an essay.

One Quick Test

Pull up a prompt you've been struggling with. A prompt that technically includes everything the AI needs but still produces mediocre outputs.

Read it and highlight the single most important instruction. Where does it live?

If it's in the middle, move it. Put it in the first two sentences. Then rerun the prompt.

A lot of the time, that one change is enough.

Thanh Pham is the founder of Asian Efficiency and runs AI workshops in Austin. To improve your AI prompting skills from the ground up, check out the 4-Day AI Sprint.

Their executive team was preparing for every meeting by reading two-page text documents. Building statuses, project notes, next steps — all dense prose. Someone had to sit down and wade through it before every single call.

It sounds manageable. But multiply that by a full week of meetings, across a team of executives, and you have a real productivity drain. Not because the information was bad, but because the format was wrong.

We solved it with AI-generated visual briefings. One-page dashboards showing the status of every building at a glance. Colors, icons, clear hierarchy. The kind of thing you can absorb in 20 seconds instead of 4 minutes.

The difference in how the team showed up to meetings was immediate.

The Tool Most People Haven't Found Yet

The AI feature that made this possible is Gemini Imagen.

Google named it “Nano Banana” at one point (that's the label that appeared in the UI when I first used it — it's stuck in my head ever since). The concept is simple: you give it a description of a complex idea, framework, or process, and it generates a clean visual asset. Diagrams, explainers, concept maps. The kind of thing that used to require a designer, a few days of back-and-forth, and a budget.

Now you can generate a first draft in under a minute.

I tested it on my own content. I described the TEA framework — Time, Energy, Attention, the three pillars I use when teaching productivity — and asked Gemini Imagen to create a visual explainer. Something I could show a client in a second instead of talking about it for five minutes.

The output was clean enough to use in a presentation that same afternoon.

Why Visuals Close What Words Can't

There's a principle I come back to often: if an output is being ignored, or if it's taking too long to understand, convert it into a visual.

Dense meeting docs get skimmed. A well-made visual gets absorbed.

This isn't new knowledge. We've known for decades that visuals communicate faster than text. What's new is that AI makes it cheap and fast to produce them. You don't need a Canva subscription and three hours of design work anymore. You describe what you need and the model generates something usable.

The business applications are everywhere:

• Sales decks that explain a complex service model in one image
• Internal briefings for executives who don't have time to read
• Workshop materials that make abstract frameworks tangible
• Social media content that stops someone mid-scroll

Any time you're explaining something complex in text and it's not landing… there's probably a visual version that would work better.

How to Try This Today

Open Gemini and find the Imagen feature (look for image generation options in the model selector).

Think of a concept you explain repeatedly. A framework, a process, a system. Write a plain-text description of it — three or four sentences about the main components and how they relate to each other.

Ask Gemini to create a visual explainer based on that description.

Then ask it to iterate. Adjust the layout. Try a different style. Add specific elements. Within a few prompts, you'll have something usable.

This is one of those features that changes your workflow once you start using it regularly. The first time you hand a client a visual you generated in five minutes instead of commissioning a designer, you'll understand why I keep talking about it.

The Bigger Picture

Everyone right now is using AI to write more text. More emails, more blog posts, more documentation.

The people who figure out how to use it for visuals are going to have a real edge in the next couple of years. Not because visuals are inherently better, but because the gap between “can explain it in text” and “can show it visually” is where attention and trust get built.

Words describe. Visuals demonstrate.

And with tools like Gemini Imagen now available to anyone with a free account, the only thing stopping most people from doing this is knowing the feature exists.

Now you do.

Thanh Pham is the founder of Asian Efficiency and runs AI workshops in Austin. To learn how to build your own AI workflows, check out the 4-Day AI Sprint.

She'd clear everything down to a dozen emails and feel genuinely good about herself. Two days later, she'd be back at 300 and the stress would return. She'd go on another clearing sprint. Repeat.

After watching this cycle a few times, I told her she was measuring the wrong thing.

Inbox zero made sense in a world where email was just communication. Messages came in, you responded, you cleared the queue. The inbox was a task list, and empty meant done.

But that model is outdated. And if you're building AI agents, inbox zero can actually work against you.

Email as a Knowledge Store

Here's what changed my thinking.

I was at Arena Hall in Austin, working with Evan Baehr to design his super agent. We kept routing AI outputs to email — daily memos, meeting summaries, agent-generated reports — and at some point Evan asked why.

The reason is straightforward: when his super agent preps him for a meeting, it searches his inbox. It looks for every prior mention of the person he's meeting, every relevant summary, every note that's accumulated. It doesn't query a separate database or a specially formatted document. It searches email. The inbox becomes the context layer.

The more you route to email on purpose, the richer that context gets. Every memo that lands there is one more piece the agent can find later.

That's the shift. Email isn't just a place to receive messages. When you design it that way, it becomes a searchable knowledge store.

What to Route There

Not everything. The goal isn't to fill your inbox with noise. The goal is to store AI outputs intentionally so they're queryable later.

Things worth routing to email:

• Daily briefings and memos your AI generates
• Meeting summaries and key decisions from calls
• Weekly synthesis reports (what patterns emerged, what action items surfaced)
• Agent reports on topics you track (news, research, competitor updates)

These aren't emails you need to respond to. They're documents that accumulate over time. When your agent queries the inbox for context, these are exactly what it needs.

The Framework Behind It

What Evan and I were building that day is part of a broader design principle I use with AI: context files as assets.

The idea is that context — your identity, your preferences, your history — is one of the most valuable things you can give an AI agent. Most people think about this in terms of prompt files or uploaded documents. But email is already a natural container for accumulated context. You just have to start treating it that way.

The inbox zero crowd sees the inbox as a task manager and measures it by how empty it is. The knowledge-store approach sees it as a living archive and measures it by how useful the agent finds it.

Both are valid mental models. But if you're building agents, only one of them makes your system smarter over time.

The Mindset Shift

I'm not saying you should let spam pile up or never archive emails. Triage still matters. But the goal you're optimizing for changes.

Old goal: process everything, stay at zero, feel in control.

New goal: route AI outputs intentionally, let them accumulate, give your agent more to work with.

There's a kind of patience required here that goes against every productivity impulse. We've been trained to clear the inbox. Anything sitting unread feels like a failure.

But imagine your email as a memory layer for your AI stack. Every summary that passes through it is stored. Searchable. Available the next time your agent needs it for context.

You're not managing email. You're building a brain.

Try This

If you're running AI agents and you haven't done this yet, start with one output.

Pick one thing your AI generates regularly — a daily briefing, a meeting summary, whatever it is — and route it to your inbox. Don't archive it. Don't file it away somewhere. Leave it in email.

Do that for 30 days and then ask your agent to pull context from your inbox for something. See what it finds.

You'll understand the value pretty quickly.

Thanh Pham is the founder of Asian Efficiency. If you want to start building your own AI agent stack, check out the 4-Day AI Sprint or the 25X Productivity System.

They want a demo.

A vendor comes in, shows off a polished product, everyone nods and says “impressive.” Then the meeting ends, the demo is forgotten, and nothing changes.

I've been running AI workshops in Austin for the past two years. I've watched this happen enough times that I stopped offering demos entirely. Not because demos are worthless. But because they're solving the wrong problem.

The Problem With Demos

When a company brings in an AI vendor for a demo, they're seeing someone else's finished product. It's been built, polished, and packaged for a specific use case. It looks clean and simple.

What they don't see is the underlying capability. What AI can actually do when applied to their specific situation, their own data, their own workflows.

And here's the thing about being an executive: you can't make good decisions about something you don't understand. You can't evaluate a vendor's proposal. You can't push back when the IT team says “it's too complicated.” You can't spot the obvious opportunity your competitors are missing.

A demo teaches you what someone else decided was worth building. That's not the same as knowing what's possible.

What Actually Changes Things

There's a CFO I worked with last year. Smart, experienced, running a finance team of about 15 people. He came to one of my Austin workshops with a very reasonable stance: “I don't need to learn this myself. I need my team to learn it and implement it.”

By the end of the morning session, he was running his own analysis in real time. Not with help. Just him, a laptop, and a few prompts.

Something shifted.

It wasn't that he suddenly became a developer or an AI expert. It was that he saw enough. He understood what the raw material could do.

The next week, he sent me a list of over 30 processes he wanted his team to look at. Client reporting, reconciliation workflows, contract review prep, board meeting prep… things he hadn't thought about automating because he didn't know automation was possible.

That's what I mean by the awareness expansion. Before you see what AI can do, you're ordering from a menu you can't read. After, you can finally see the options.

What “Understanding AI” Actually Means

I'm not talking about learning to code. Or understanding large language models at a technical level. Or building your own tools.

It's simpler than that.

It means being able to sit down with an AI tool and do something useful in under 10 minutes. Draft a memo. Summarize a long document. Analyze a spreadsheet. Walk through a decision framework.

When executives have that experience firsthand, they stop delegating their AI strategy to the IT team. They start thinking like product managers for their own operations. They see where the bottlenecks are. They know which vendor proposals are overpriced. They understand why the rollout isn't working.

The agent-as-teammate concept is a good way to think about where this leads. The goal isn't replacing workers with robotic automation. It's building AI that behaves like a capable colleague: aware of the priorities, connected to the right information, clear on when to escalate. But you can only design that if you understand what it can do.

Why Most Executives Skip This

It comes down to time and perceived relevance.

“I'm not a tech person.” “That's what I have an IT team for.” “I don't need to know the details.”

I get it. Executives have full calendars. Learning something new feels like a cost.

But AI is one of those rare areas where leadership ignorance is a direct liability. Your team can implement tools, but they can't redirect strategy. They can't decide what's worth building. They can't spot the opportunity your competitor is about to find.

And the awareness expansion doesn't take months. For most people, it takes one focused afternoon.

Try This

If you're leading a team right now: set aside half a day and just play with AI yourself. No agenda. No deliverable. Just try to break it.

Use it to analyze a real problem from your business. Write a memo. Build a process map. See what it does well and where it falls apart.

You won't need to look for opportunities after that. They'll be obvious.

That's the difference between a demo and a red pill. One shows you the surface. The other changes what you see.

Thanh Pham is the founder of Asian Efficiency and runs AI workshops in Austin. If you want to explore what AI could do for your team, check out the 4-Day AI Sprint.

The timing couldn't have been worse. Tax season is the most demanding stretch of the year for a CPA firm. Losing a key team member at that moment would normally mean one thing: bring someone in fast.

Amanda took a different approach. She wanted to see what AI could handle before defaulting to a hire.

Tax season ended. Her clients were happy. The work got done. And Amanda was left with a question she hadn't expected to be asking: “Was the hire even necessary?”

What She Said

“I don't want to hire another person until I fully know every single thing that AI can do. What I did during tax season — I reflected on that a lot. It would not have been humanly possible without AI.”

That's not a casual observation. Amanda had been building out AI systems for her firm over several months — a custom GPT trained on her processes and tax knowledge, an email inbox manager, communication workflows. When her tax manager left, those systems were already in place.

The capacity gap she'd expected to feel badly didn't show up the way she anticipated.

She went into that tax season with nine employees. After the season, she was at four — and maintaining the same client quality she'd had before. Her outsourced team in India was so impressed by the custom GPT that her team lead asked where she'd gotten the training. The GPT was handling complex tax queries more precisely than anything they'd seen from a tool like that.

The thing Amanda was building toward wasn't fewer employees for its own sake. She was building toward a different question: what does this business actually need headcount for?

The Default That Needs Questioning

For most business owners, the response to capacity strain is automatic: hire. More demand, more people. It's the operating assumption that's been correct for most of business history.

But that assumption was built in a world where the only way to add capacity was to add people. That's no longer true.

AI can handle significant workload — not everything, and not always at the same quality a skilled person would produce, but far more than most business owners have tested. The problem is that most haven't run the test. They feel overwhelmed, they assume more people is the answer, and they hire without ever finding out what AI could have done.

The cost of that pattern is real. Every hire is a commitment — salary, benefits, management overhead, onboarding time, the cultural effect on the team. A hire that wasn't strictly necessary doesn't just cost money in the moment; it adds permanent structural overhead.

The Experiment Worth Running

Before your next hire, spend thirty days running a different experiment.

Take the role you're considering hiring for and ask: what are the actual tasks this person would do? Get specific. Not “manage client relationships” — the actual daily and weekly work: drafting proposals, answering common questions, preparing reports, updating records, scheduling, follow-up emails.

Then test each of those tasks with AI. Not a quick attempt — a real attempt. Build a proper system, load it with the relevant context, and see what it can actually handle.

Some things will work well. Some won't. But you'll end up knowing something most business owners don't: the AI capacity actually available to you for this specific function.

After that experiment, you'll be making a hiring decision from a much more informed position. Maybe the hire is still necessary and the experiment just confirmed it. Maybe the hire only needs to be part-time instead of full-time. Maybe a system and a smaller team can do what you thought required adding headcount.

Amanda didn't set out to reduce her team from nine to four. That happened because she kept asking the question before defaulting to the obvious answer. What can AI do here? What do I actually need a person for?

What This Doesn't Mean

I want to be clear about what I'm not saying.

I'm not saying AI replaces people. There are things that require human judgment, relationships, and accountability that AI genuinely can't replicate — and that set of things is larger than the most aggressive AI proponents acknowledge.

I'm not saying every hire is unnecessary. Some roles require a person. Some capacity gaps are real and the hire is the right call.

What I am saying is that the reflexive hire — the “I'm overwhelmed, time to bring someone in” move made without testing AI capacity first — is a less informed decision than it used to be. The space between “I need more capacity” and “I need to hire someone” has grown substantially.

The businesses getting the most out of this moment are the ones asking a new question before the old one. Not “who should I hire?” but “what does this business actually need a person for?”

Amanda found that question after tax season. It's worth asking before the next one.

I help service business owners and professional firms build AI systems that answer this question with evidence — so hiring decisions are made from a position of knowledge, not assumption. If you're thinking about headcount and want to run the AI capacity experiment first, reach out or check out my consulting and workshop programs.

Peak positioning is the simple strategy of mapping your most important tasks to the moments when your mind is naturally at its sharpest. In this encore episode, we break down the science behind your daily energy peaks and valleys, and you'll discover a dead-simple formula to find yours — no fancy gear required. Once you know your pattern, everything changes.

Visit www.asianefficiency.com for more productivity tips and tactics.

Go to HomeServe.com to find the plan that's right for you. Not available everywhere. Most plans range between $4.99 to $11.99 a month your first year. Terms apply on covered repairs.

Links

• HomeServe
• 25X Productivity Coaching
• RISE Science app
• TEA Framework (Time, Energy, Attention) — Asian Efficiency

If you enjoyed this episode, follow the podcast on Apple Podcasts, Spotify, Stitcher, Overcast, Pocket Casts or your favorite podcast player. It’s easy, you’ll get new episodes automatically, and it also helps the show. You can also leave a review!

The difference is usually context.

When you load an AI agent with a real understanding of who you are — your voice, your decision-making patterns, your values, how you like outputs delivered — the quality of what it produces changes substantially. It stops sounding generic. It stops giving you answers that require major editing. It starts working the way a well-briefed assistant would.

The problem is that creating a good context profile sounds like a lot of work. You'd need to write something comprehensive about yourself — your communication style, your priorities, your preferences. Most people look at that task and push it off indefinitely.

Here's how I skip that entirely: I use AI to write the context profile.

The Problem With Writing It Yourself

Trying to write a context profile from scratch puts you in an awkward position. You know yourself, but articulating your own patterns is surprisingly hard.

Most people don't have a clear sense of what their “decision-making style” looks like in writing. They know how they make decisions — they've been doing it for years — but describing that as a document takes a kind of structured self-reflection that doesn't come naturally.

Same with voice. You know what sounds like you. But writing a guide for how AI should sound like you requires you to reverse-engineer your own instincts, and that's genuinely difficult.

The result is that most context profiles, when people actually write them, are too short and too vague to be useful. “Conversational and direct.” “Values relationships.” These phrases don't tell an AI anything it can act on.

The Interview Method

The approach that works better: have AI ask you the right questions.

Give Claude (or ChatGPT) a set of category headers — the structure of what you want to capture. Good headers for a personal context profile include:

• Voice and communication style: How do you like to communicate? What's your tone in writing? What phrases or patterns would others recognize as “you”?
• Decision-making principles: When you're choosing between options, what matters most? What do you optimize for?
• Values: What drives your work? What won't you compromise on?
• Operational preferences: How do you want AI outputs delivered? Long or short? Structured or flowing? What should they avoid?
• Context about your work: What are you working on? Who are your clients or stakeholders? What's the current priority?

Give those headers to Claude and say: “I want you to interview me on each of these categories. Ask me one question at a time. After I've answered all the questions, write a structured context profile from my answers.”

Then answer the questions naturally — the same way you'd talk to someone. Don't write carefully crafted responses. Just answer.

What You End Up With

The synthesized profile is richer than anything most people would write themselves. Because the interview process surfaces things you know but wouldn't think to include.

I did this with Evan Baehr, who runs Arena Hall, a co-working and event space in Austin. He had multiple AI workflows being built — meeting prep agents, weekly briefings, communication drafts — and they all needed to understand how Evan thinks and operates.

We didn't sit down and “write” his context profile. Claude asked him questions about how he makes decisions when two priorities conflict, how he communicates with members versus with investors, what he cares about when setting the week's agenda.

Evan answered. Claude wrote.

What came out was a document that captured how Evan actually operates — including patterns he hadn't consciously articulated before. The agents loaded with that profile produce outputs that require far less editing because they start from an accurate understanding of who Evan is and what he needs.

Context Files as Reusable Assets

Once you have the profile, it becomes an asset you can use everywhere.

Load it into Lindy's system settings for your automation workflows. Add it to Claude Projects for your writing and thinking work. Paste the relevant sections into any agent you're building.

The model I use: one central Google Doc that contains the master context profile. Every agent I build for a client gets that document. When something in the profile needs updating — a priority shifts, a communication preference changes — I update the doc once. Every agent that reads it gets smarter at the same time.

This is how context files become leverage. You build the asset once. It pays off every time you use AI, because your agents stop needing to ask the same clarifying questions and stop producing outputs that miss the mark.

One of my clients ended up with a 33-page context profile built over months of annual reviews, weekly reflections, and coaching sessions. Every AI he uses reads that document before doing any work. Generic AI becomes personalized AI. That's where the real performance difference is.

How to Build Yours This Week

Step 1. Open Claude or ChatGPT and give it a prompt like this: “I want to create a context profile for my AI agents. Please interview me on the following categories, one question at a time: [paste your headers]. After I've answered all the questions, synthesize my answers into a structured profile document I can reuse.”

Step 2. Answer the questions. Don't overthink it. Answer the way you'd talk to a person, not the way you'd write a document.

Step 3. When the interview is done, ask it to write the profile. Review the output and add anything it missed or adjust anything that feels off.

Step 4. Save it somewhere central — a Google Doc works well. This is your context asset.

Step 5. Load it into your agents. In Lindy, paste the relevant sections into system prompt settings. In Claude Projects, attach the document. In ChatGPT, add it to custom instructions.

Step 6. Test it. Ask the agent something it would have gotten wrong before. Notice the difference.

The whole process takes 30-40 minutes the first time. Every AI interaction after that benefits from the investment.

The Meta-Lesson

There's a pattern worth noticing here. The thing that makes AI useful is context. The thing that makes creating context feel like work is having to write it yourself. The solution is to use AI to help you create the context that makes AI better.

This is the kind of recursive improvement that becomes available when you start thinking of AI as a tool for building better AI systems — not just a tool for getting individual tasks done.

You don't have to write a context profile. You just have to answer questions.

I help founders and operators build personalized AI systems that actually know who they're working for. If you want to set up proper context profiles for your agents, reach out or check out my AI consulting and workshop programs.

“I really believe that people are now going a little bit too crazy on workflows and tools — and not actually getting any output.”

I'd been watching it for months. People in the AI space sharing their setups: MCPs stacked on top of each other, custom tool libraries, automations chained across six platforms. Beautiful, intricate systems. And I kept asking the same question: “What have you shipped recently?”

The answer was usually more workflow.

The Tool Collector Trap

There's a particular kind of activity that feels productive but isn't. You're making decisions. You're learning new systems. You're integrating things. It has the texture of work — it uses your brain, it takes time, it produces something you can show people.

But at the end of it, you haven't shipped anything. You've configured something.

Tool collecting in AI has become a version of this. Every new MCP is a small dopamine hit. Every integration feels like progress. Every new service added to the stack seems to expand what's possible. And technically, it does. But expanding what's possible and actually producing something are different activities, and they can crowd each other out.

The people who are most obsessive about their setups are often the people with the least to show for it.

What I Did About It

A few months ago, I ran an experiment on myself. I stripped everything down.

No MCPs. No third-party services layered on top. No custom tool configurations. Just native Claude Code, nothing else. And then I made a rule: I would add something back only when I hit a specific, real problem in actual work that genuinely required it.

Here's what I ended up keeping: Figma's MCP, which I use for front-end design work, and Playwright for browser automation when I'm building and testing interfaces. Two tools. Both kept because they solved concrete problems I ran into repeatedly in real projects, not because they seemed useful in theory.

Everything else stayed stripped.

What Happened

I shipped more in the three weeks after that than in the three months before.

Part of this is simple: removing friction. When you have fewer things to configure, you spend less time in configuration mode. You hit a problem and you solve it with what you have instead of thinking “maybe if I add X I could handle this better.” The constraint forces a different kind of thinking.

Part of it is also about clarity. A lean setup creates less noise. When something isn't working, there are fewer variables. You can see the problem more directly and fix it faster.

And part of it is just honesty. Stripping back forced me to admit that a lot of what I'd built was elaborate rather than effective.

The Distinction That Matters

I'm not arguing against using tools. I'm arguing for using them because you need them, not because they're interesting.

There's a concept I come back to — start small, iterate. The preferred path for building anything is small reliable wins first, then deeper complexity later. Most failures in AI systems happen not from lack of sophistication but from too much complexity too early, before you know what actually needs to be complex.

This applies directly to tool stacks. The right starting point isn't “build the best possible setup.” It's “what's the minimum I need to do the thing I'm trying to do?” Start from nothing. Add only when you hit a real wall.

This is harder than it sounds, because the instinct when building with AI is to reach for every available resource. More context is better. More tools unlock more. More integrations create more capability. And sometimes this is true. But more often, the simplest version that actually runs is more valuable than the sophisticated version that doesn't.

How to Apply This

The test I run now before adding anything to my stack:

1. Have I hit this problem before? Not “will I probably hit this problem someday” — have I actually hit it, recently, in real work?

2. Would native Claude not solve it? Most things that seem like they need a special tool can be handled with good prompting and clear context. If the native tool can do it, the native tool wins.

3. Is it going to stay useful? Tools have a habit of becoming liabilities. You add something because it's useful for one project, and then it clutters the stack for everything after. If I can't see myself using this in three different projects, it probably doesn't belong.

If something clears all three tests, I add it. Otherwise I keep looking for a way to solve the problem with what I already have.

The Bias That Actually Matters

The people doing the most interesting AI work right now are not the ones with the most sophisticated setups. They're the ones who have an overwhelming bias toward actually putting something out — even if it's rough, even if it's not optimized, even if the system behind it is janky.

Tool literacy matters. Knowing what's available, what different models are good at, when to reach for what — these are real skills.

But tool discipline matters more. The ability to resist adding complexity. The willingness to ship something imperfect. The habit of asking “what have I actually made?” instead of “what am I building toward?”

Start from nothing. Add only what you actually need.

And then show me what you've shipped.

I help founders and operators build AI systems that actually produce output — not just architecture diagrams and workflow screenshots. If you're building with AI and want a clearer path from setup to results, reach out or check out my AI consulting and workshop programs.

At some point, she stopped liking it.

Not in a dramatic way. More of a slow drift. The work that actually required her got crowded out by everything else: routine questions she'd answered dozens of times, standard reviews that didn't need her judgment, emails that could have been handled by anyone. She was busy every day. But less and less of it felt like the work she'd set out to do.

When we met, she had nine employees and was thinking about hiring more. The work kept expanding to fill the capacity she had.

We took a different approach.

What We Built

The core was a custom GPT trained on Amanda's firm — her processes, her way of thinking through tax scenarios, her communication style with clients, her internal standards. Not a generic AI assistant. Something specific to how her firm operates.

The goal wasn't to automate everything. It was to handle the work that didn't require Amanda.

When a client had a question about a standard tax scenario, the GPT could answer it — accurately, in Amanda's firm's voice, drawing on how she'd handled similar situations before. When her team needed to know how to process a specific type of return, they could ask the GPT instead of her.

She stopped being the first call for everything.

Her outsourced team in India noticed immediately. Her team lead asked where Amanda had gotten the training because the GPT was handling complex scenarios with a level of precision they hadn't seen before. (Amanda was strategic about not sharing all of it. It had become a competitive advantage.)

The Result Nobody Anticipated

Here's what I measure when working with clients: time saved, tasks automated, capacity freed up. These are real and worth tracking. Amanda went from nine employees to four while maintaining the same client volume and quality — that's a significant operational shift.

But the thing Amanda said that stayed with me wasn't a number.

“I've been using ChatGPT so heavily, and those custom GPTs — I can get it done in a way that doesn't feel heavy. It's highly effective, the clients are responding with fantastic results. And it's fast and timely. They're happy. So I feel happy again.”

Happy again. That's a different category of outcome.

Real Work vs Fake Work

There's a distinction I come back to a lot with clients: real work versus fake work.

Real work moves things forward. It's the work you're uniquely positioned to do — your judgment, your relationships, your expertise applied to problems that actually need it. It's why most professionals got into their field.

Fake work is motion without that progress. It creates the feeling of being busy and the reality of going nowhere strategically. It's answering the same question for the tenth time. It's being the bottleneck for things that don't need you. It's the administrative weight that accumulates around the edges of a job and eventually starts crowding out the center.

For most professionals, the ratio shifts over time. Not deliberately. Just because fake work expands to fill available attention. You hire someone, and they help, and then they generate new coordination overhead. You take on more clients, and more of your day goes to maintaining the work rather than doing it.

AI is very good at handling the fake work. The routine queries. The standard processes. The things that follow a pattern but don't require human judgment.

What I didn't fully anticipate when I started doing this implementation work was what happens when the fake work actually comes off someone's plate. The math is obvious — less time on routine tasks, more time for strategic ones. But the emotional dimension surprised me.

People get back something they didn't realize they'd lost.

What “Enjoying My Work Again” Actually Means

Amanda said she'd gotten into accounting because she liked helping clients with complex problems. When I asked what most of her day looked like before we started working together, it wasn't complex problems. It was everything around the complex problems.

When the GPT started handling the routine layer, Amanda got back the work she'd become a CPA to do. The clients who needed her actual expertise. The situations that required judgment. The relationships she'd built over years.

The work didn't feel heavy anymore.

This is the outcome that's hardest to measure and most worth having. Nobody puts “I started enjoying my work again” in a business case. But it's what drives people to keep using the systems they build, to invest in them further, to recommend them to colleagues. It's what makes the difference between an AI implementation that gets used and one that gets abandoned.

The Implication for Your Own Work

If you're a professional — a consultant, a lawyer, a doctor, a financial advisor, anyone doing complex knowledge work — there's probably a version of this pattern in your own day.

Work you became excellent at, crowded out by work that just needs to get done.

The question worth asking isn't “how do I automate my business?” It's closer to: what is the work that actually requires me? And what's in the way of doing more of it?

AI can help answer the second question in a concrete way. The fake work — the repeatable, the routine, the answerable — is increasingly handleable. The real work, the kind that took years to become good at, is where you still need to be.

Getting that ratio right is what Amanda found. It's a quieter outcome than “10x revenue” or “saved 40 hours a week.” But for the people who experience it, it tends to be the one that matters most.

I help professionals and service business owners build AI systems that free them up for the work that actually requires their expertise. If you're feeling buried by the operational layer of your business, reach out or check out my AI consulting and workshop programs.

He wasn't reading them.

The brief was a wall of text: 67+ one-hour meeting blocks crammed into a document. He'd open it, feel the weight of it, and close it. The information was technically there. It wasn't actually useful.

When we looked at why, the answer was simple: the brief was doing the wrong job. It was summarizing everything that happened. What Evan needed was something different — schedule conflicts for the coming week, actions he needed to take, and the themes that had been running through his conversations.

Not “here's what happened.” More like “here's what your week is telling you.”

That reframe is what led to the weekly transcript synthesis agent. And it's one of the most useful things I've built.

The Problem With Individual Meeting Notes

Most meeting automation follows the same pattern: meeting ends, transcript gets generated, AI produces a summary, you get a document.

This is genuinely useful. Having clean notes beats having nothing. But the unit of analysis is a single meeting, and that creates a blind spot.

The patterns that actually matter to how you're running your life and business — what you keep coming back to, what's chronically unresolved, where your energy is accumulating or draining — those patterns don't show up in any individual meeting.

They show up across a week of meetings.

You can't see them in the moment. You're too close. You move from one call to the next and each conversation feels like its own thing. But when you step back and read all of them at once, themes emerge.

“This week you talked a lot more about personal development issues than last week.”

That line came from an agent I was sketching out with Evan. And it was striking. Not because it's technically hard to produce — you're just asking an AI to read a set of transcripts and identify patterns. But because it's the kind of insight that nobody ever surfaced before AI made it possible. You'd have to read your own meeting notes cover-to-cover every week, all of them, to catch something like that.

Nobody does that. But an agent can.

What Weekly Synthesis Actually Surfaces

The weekly transcript synthesis agent reads all your meeting transcripts from the past seven days and produces something different from a collection of summaries.

The most useful outputs I've found:

Big ideas from the week. What concepts, opportunities, or problems came up more than once across different meetings? When the same idea shows up in three different conversations with three different people, that's a signal. Worth noticing.

What went well and what didn't. Not just individual meeting quality, but patterns. Are the same kinds of conversations going well while others keep stalling? That's information.

Unresolved issues. Things that were raised in meetings but never landed anywhere. A concern that got noted but not addressed. A decision that was deferred. These drift if nothing surfaces them.

Thematic shifts. The thing Evan's agent was built to catch. Not just “here's what you discussed” but “here's how this week's conversations differed from last week's.” More focus on operations. More energy on one client. Fewer conversations about the thing you said was a priority. The delta tells you something your moment-to-moment experience might not.

The Evan Story

The Friday brief problem had a few layers.

Evan runs Arena Hall, a co-working and event space in Austin. His week involves a lot of conversations: member check-ins, venue logistics, partner meetings, strategy calls, advisory sessions. A lot of different threads at once.

The original brief was built for completeness. Every meeting had an entry. Every entry had a summary. It was thorough.

It was also useless, because the cost of processing it was too high. A document that requires 45 minutes to extract value from is not a good document.

The redesign started by asking a different question: what does Evan actually need to decide and act on at the start of next week? That question pointed to:

• Calendar conflicts that needed resolving
• Specific actions only he could take
• The one or two themes worth carrying into the coming week

Once the brief was oriented toward those outputs instead of comprehensive recap, the length dropped by two-thirds. The reading time dropped to under ten minutes. He started actually using it.

The underlying insight: the problem wasn't that his brief was too long. It was that it was trying to be an archive instead of a planning tool.

How to Build This

If you have a meeting notetaker running — Granola, Otter, Fireflies, anything that produces transcripts — you have the raw material.

The setup I use:

Step 1. Route transcripts to a central location. A shared Google Drive folder works well. Granola can be set to auto-export; other tools have similar options. The key is that every transcript ends up in one searchable place, not locked inside individual apps.

Step 2. Build a weekly agent that reads the folder and produces the synthesis. The prompt matters here. Don't ask for summaries — ask for patterns. Specifically: big ideas that appeared more than once, meetings that went well versus ones that didn't, unresolved issues, and any notable shifts compared to typical weeks.

Step 3. Add a thematic comparison. This is the part that creates the “this week you talked more about X” output. It requires either keeping the last few weeks of synthesis on hand for comparison, or structuring the prompt to identify unusual concentrations of topic or energy.

Step 4. Orient the output toward action, not recap. The synthesis should end with three things: what needs to happen next week, what should probably be taken off the calendar, and one pattern worth paying attention to.

Running this weekly takes about 2-3 minutes once it's built. The manual version — reading your own notes looking for patterns — either doesn't happen at all or takes an hour and still misses things.

The Broader Point

There's a version of AI adoption that makes each individual task slightly better. Better meeting notes. Faster email drafts. Cleaner summaries.

That's real value. But there's another layer available that most people aren't using yet.

AI can read across your whole week — all your conversations, all at once — and surface things that no individual note would reveal. It can be a pattern-recognition layer, not just a faster note-taker.

The weekly transcript synthesis agent is one example of that. The value isn't “now I have better summaries.” The value is “now I can see patterns in how I'm spending my time and attention that I literally couldn't see before.”

Your transcripts are sitting there. Most of them never get used for anything beyond the meeting they came from.

The weekly agent changes that.

I help founders and operators build AI systems that surface the patterns in their business — not just automate individual tasks. If you're building this kind of intelligence layer and want an outside perspective, reach out or check out my AI consulting and workshop programs.

Visit www.asianefficiency.com for more productivity tips and tactics.

Go to HomeServe.com to find the plan that's right for you. Not available everywhere. Most plans range between $4.99 to $11.99 a month your first year. Terms apply on covered repairs.

For problems worth solving go to Claude.ai/tps.

Get 60% off personal and family plans at Keepersecurity.com/TPS.

Visit Upwork.com right now and post your job for free.

Cheat Sheet

• Top 3 Productivity Resources [2:29]
• The first category of apps about to be replaced by your AI chat window [7:17]
• The hidden feature that decides which apps survive the AI era [10:44]
• The boring task an Atlassian button quietly killed for Brooks [14:26]
• Brooks’s surprising “central hub” for everything he does — and it isn’t his task manager [20:52]
• Why Thanh ditched his task app for a spreadsheet (and let agents work the board) [25:37]
• The beautiful little app Thanh thinks AI is about to eat [30:55]
• The password manager trick that lets AI agents log in for you [35:48]
• The “tried and true” apps still earning their place after the AI takeover [37:32]
• The drag-and-drop trick that ended Brooks’s AppleScript problem for good [45:12]
• Why Codex might be a quietly great choice for desktop automation [47:43]
• The apps we’d build tomorrow if we had a free weekend [50:39]
• Inside the “mission control” dashboard Thanh built to fire off agents with one click [51:57]

Links

• HomeServe
• Claude
• Keeper
• Upwork
• 25X Productivity Coaching
• Mike Vardy
• Wispr Flow
• Elgato Stream Deck Pedal
• Granola
• MyFitnessPal
• Lose It
• OmniFocus
• Todoist
• Lindy
• Atlassian Rovo
• Obsidian
• Fantastical
• Airtable
• OpenClaw
• Hermes Agent
• Evernote
• Soulver
• OpenAI Realtime
• Day One
• TextExpander
• Spotify
• Tailscale
• NordVPN
• Jump Desktop
• HomeControl Menu for HomeKit
• Elgato Stream Deck
• Keyboard Maestro
• Setapp
• Bartender
• Dropzone
• OpenAI Codex

If you enjoyed this episode, follow the podcast on Apple Podcasts, Spotify, Stitcher, Overcast, Pocket Casts or your favorite podcast player. It’s easy, you’ll get new episodes automatically, and it also helps the show. You can also leave a review!

Luxury catering — private events, upscale clientele, the kind of food served at fundraisers and gallery openings. The copy needs to feel elevated. Considered. The kind of language that sits comfortably next to a curated wine list.

Personal chef meal prep — weekly deliveries, health-conscious clients, warm and practical. More like a knowledgeable friend than a Michelin-starred venue.

When we sat down to set up Lindy agents for her content and client communication, she asked a reasonable question: how do you get AI to write in the right voice when you have two of them that are nothing alike?

She'd already tried the obvious approach. Describing each voice to the AI. “Professional but approachable.” “Elevated but not stuffy.” Every content creator I've worked with has tried some version of this. And it never really works.

Why Describing Your Voice Doesn't Work

The problem with describing your brand voice to AI is that the descriptions are too abstract.

“Warm and professional.” “Conversational but authoritative.” Every brand thinks this about itself. When you type these phrases into a prompt, the AI produces something technically warm and professional — which is to say, generic. It's aimed at the middle of the target, not at your specific corner of it.

Your real brand voice is built from specifics: the particular words you reach for, the sentence length you default to, whether you use contractions, how you handle transitions, whether you open with a question or a statement. Most of these things are instinctive. They're in your existing content, but you can't easily articulate them.

So the description is always a blurry proxy for what you actually do.

The Better Approach: Let AI Extract the Patterns

What worked for Michelle was flipping the process.

Instead of describing her voice, she demonstrated it. For each brand, we pulled together 8 to 10 examples of existing content — emails to clients, social posts, website copy, catering menus, inquiry responses. Anything that represented the brand well.

We put those into ChatGPT and asked it to do two things:

1. Analyze the writing and identify the specific patterns — vocabulary, sentence structure, tone markers, recurring phrases, things the brand does and things it avoids
2. Write a prompt that captures those patterns — a prompt another AI model could use to write new content in that voice

The output wasn't a description. It was an operational brief. Something like: “Write in a warm, direct tone. Use short sentences. Favor specific details over abstract qualities. Avoid corporate language. Address the reader as ‘you.' Never use exclamation points. The writing should feel like advice from someone who knows what they're doing.”

For her luxury catering brand, the prompt was different: “Use measured, considered language. Write in longer, more complete sentences. Choose words that suggest craftsmanship and care. Avoid casual contractions. The reader should feel like they're in capable hands.”

Each prompt was a distillation of what she'd already created. Not what she thought she sounded like — what she actually sounded like.

We copied each prompt into Lindy's system settings for the relevant workflow. Luxury catering emails get one prompt loaded. Personal chef content gets the other.

One session. Two brand-specific AI agents writing in the right voice.

Why This Works Better

The “use AI to write the prompt for another AI” approach works because it bypasses the articulation problem.

You don't have to figure out what makes your brand sound like itself — that's genuinely hard to put into words, and most people get it partially wrong. Instead, you give AI a set of examples and let it do the pattern recognition. It's good at that. It will find things you'd miss.

The resulting prompt is grounded in real content rather than aspirational description. It reflects what your brand actually sounds like, not the idealized version you think it sounds like.

How to Do It

This takes about 15 minutes per brand. Here's the process:

Step 1. Gather 8 to 10 pieces of your best existing content. Emails, posts, copy, whatever most accurately represents the brand. The more variety in format, the better — the AI will find the common threads.

Step 2. Paste them into ChatGPT. Ask: “Analyze this content and identify the specific patterns in voice, tone, vocabulary, sentence structure, and style. Then write a prompt that would allow another AI model to write new content that matches this voice.”

Step 3. Review the prompt. Adjust anything that feels off. Add anything it missed.

Step 4. Load the prompt into your AI agent's system settings — whether that's Lindy, ChatGPT's custom instructions, Claude Projects, or wherever you do your writing work.

Step 5. Test it with a new piece of content. Refine the prompt based on what still doesn't sound right.

Most people get 80% of the way there in the first pass. The remaining 20% comes from a few rounds of testing and tweaking.

The Broader Point

If your AI content consistently sounds off — too generic, too formal, not quite you — the prompt is probably the problem. And the prompt problem is usually that you described instead of demonstrated.

Your voice is in your existing work. Let AI find it.

I help service business owners build AI content and communication systems that sound like their actual brand. If you're setting up content agents and want them to write in your voice, reach out or check out my AI consulting and workshop programs.

We kept calling it the Lindy Workshop. That was the accurate name. Lindy is the tool we were teaching.

But “Lindy Workshop” was the wrong name.

Nobody wakes up wanting to learn Lindy. They wake up wanting their email handled, their follow-ups done, their admin off their plate. They want their day back.

So we renamed it the Two Hour Workday.

Not because the program changed. Because the name finally said what it actually delivers: two hours of focused work every day, reliably, because the background stuff is taken care of.

The Actual Problem

Most people don't have a time problem. They have a focus problem.

There are enough hours in the day. The issue is that most of them get consumed by things that are necessary but not meaningful — email, follow-ups, status updates, scheduling, meeting prep, administrative tasks. The kind of work that keeps the wheels turning but doesn't actually move anything forward.

At Asian Efficiency, we've been thinking about this distinction for years. Real work moves goals and priorities forward. Fake work creates motion. Both feel like work, but only one of them actually matters.

The painful thing is that most people know the difference. They know which work matters. They just keep getting pulled away from it.

A typical day looks like: check email, respond to a few things, get into something real, get interrupted by follow-ups, check Slack, get back to work, handle an admin task someone flagged, glance at email again. By the end of the day, maybe 90 minutes of actual focused work happened, if that.

The 8-hour workday is mostly fake work. The real work is squeezed into whatever's left.

Where AI Fits

This is where the pattern becomes obvious: AI is exceptionally good at fake work.

Not because it's smarter at those tasks. But because email replies, follow-up messages, scheduling coordination, meeting summaries, and administrative workflows all follow patterns. They're predictable. They involve reading something, understanding context, producing a structured response. That's exactly what language models do well.

So the setup I teach is straightforward: build AI agents that handle the pattern work in the background. Email gets managed. Follow-ups go out. Meeting notes become action items. Scheduling gets coordinated.

All of this happens while you're doing something else — or nothing at all. The agents run on schedule. They work overnight if needed.

What that frees up: your actual hours.

Two Hours, Reliably

Two hours of focused work sounds modest. But for most people, it's more real focused work than they currently get in a full day.

The difference between 2 reliable hours and 2 hours you had to fight for is enormous. When the 2 hours are protected — not carved out of chaos, not interrupted by things the agent should have handled — you can actually go deep. You can work on things that require unbroken attention. You can make real progress.

The agents I help people build typically cover:

• Email management — reading, triaging, drafting replies to routine messages, flagging things that need attention
• Follow-ups — sending scheduled follow-up messages after meetings, proposals, or sales conversations
• Meeting preparation — pulling together context, research, and logistics before each meeting
• Post-meeting processing — turning notes and recordings into summaries, action items, and calendar entries
• Admin and coordination — scheduling, status updates, document routing

When all of that runs on its own, the math changes. You're not spending 45 minutes on email and then another 20 on follow-ups and then another 15 on meeting prep. That's gone. What remains is the work only you can do.

The Positioning Insight

When Mary and I changed the name from Lindy Workshop to Two Hour Workday, something clicked.

The old name told people what we were teaching. The new name told people what they'd get.

This is a pattern I see everywhere with tools and systems. People don't buy project management software — they buy organized teams and fewer missed deadlines. People don't buy meal planning apps — they buy less stress around dinner and healthier eating. People don't buy email AI agents — they buy their mornings back.

The tool is never really the point. The outcome is.

If you're building anything — a product, a service, a workshop — it's worth asking: am I naming this after what it is, or what it does for people?

The Two Hour Workday is what it does for people.

Getting Started

The simplest version of this is one agent, one job.

Pick the task that consumes the most time without requiring your actual judgment. For most people, that's email. For some, it's follow-ups or scheduling.

Build an agent that handles just that task. Run it for two weeks. See how your day changes.

Once that's working, add the next layer. Over a few months, the system compounds.

Two focused hours every day isn't a productivity hack. It's what happens when the background stuff stops needing you.

The Two Hour Workday is a program I run for founders and operators who want to set up AI agents that handle email, admin, and follow-ups so they can protect 2 hours of real work every day. If this is what you're looking for, reach out or check out the program details.

My instinct was ChatGPT. It's what I use most days.

I tested it. The results were fine but inconsistent. Some steps in the chain would stall. The synthesis at the end sometimes lost context from earlier steps. It wolosesked — but it felt like it was working harder than it should.

I switched to Gemini 3.0. Same workflow, different model. The difference was noticeable: faster, cleaner handoffs between steps, better at keeping the reasoning thread intact across all four actions.

I haven't switched back.

What Multi-Step Agents Actually Do

A lot of AI use is single-step: you give it a prompt, it gives you an output. That's fine for most tasks.

Multi-step agents are different. They chain several actions together in sequence, where the output of one step feeds the input of the next.

An example from the Arena Hall workflow:

1. Search Gmail for emails from specific contacts in the last 14 days
2. Check the calendar for meeting context and logistics
3. Pull web research on the person or company you're meeting
4. Synthesize everything into a one-page briefing

Each of those steps is its own action. The agent has to complete them in order, pass context forward, and produce something coherent at the end.

That chaining is where Gemini 3.0 currently shines. It's faster than ChatGPT on this pattern. It handles the context handoffs better. And because it's a Google product working with Google tools — Gmail, Calendar, Drive — there's a native integration advantage that isn't just marketing.

The Bigger Point: Route Work to the Right Tool

Here's what I've noticed watching people level up with AI: the ones getting the best results stopped being loyal to one model.

That sounds obvious. But most people — even people who use AI a lot — tend to have a primary tool they default to for almost everything. ChatGPT for most users. Claude for technical folks. Gemini for people deep in Google Workspace.

The better approach is what I call being multi-tool native: route work to whichever model handles that specific job best, rather than forcing your primary tool to do everything.

Here's roughly how I route things now:

ChatGPT — daily driver, general-purpose thinking, strategy, brainstorming. The most capable overall. Best for open-ended tasks that don't require specialized performance.

Claude — technical reasoning, code review, careful long-form writing, anything where the thinking process should be visible and auditable. Better at showing its work.

Gemini — multi-step agents, tasks involving Google products, image analysis and generation, and anything where you need fast output at scale. Currently the best model for chaining agent actions.

Perplexity — real-time research, anything where you need current information rather than trained knowledge.

Lindy — recurring automations that run without you. Once a workflow is proven, it moves to Lindy.

This isn't a fixed system — model capabilities shift, and I update the routing as things change. Gemini 3.0 wasn't always my answer for multi-step agents. It's the right answer now, and something better might come along next quarter.

Why Tool Loyalty Is the Wrong Mindset

The instinct toward one tool is understandable. Learning a new AI platform takes time. Building familiarity with its strengths and quirks takes repetition. It feels inefficient to spread that attention across multiple tools.

But the cost of tool loyalty is forcing the wrong model onto tasks it's not best suited for. You get mediocre results that require more correction. You miss performance improvements that are sitting right there in a different tool.

The people getting the most out of AI right now are the ones treating model selection as a skill — not just prompting, not just use cases, but knowing which model to reach for based on what you're trying to do.

From tool loyalty to tool literacy. That's the shift.

A Simple Starting Point

If you're building agents and you haven't tried Gemini 3.0 for multi-step workflows, that's the easiest experiment you can run.

Take a workflow that chains several actions together — email + calendar + research + synthesis is the classic combo — and run it in Gemini. Compare it to whatever you've been using.

You might find it works better. You might find the difference is minimal for your specific use case. Either way, you're building the routing judgment that separates good AI users from great ones.

I help founders and operators build AI systems that actually fit how they work — including figuring out which tools belong in which parts of the workflow. If you're building agents and want an outside perspective, reach out or check out my AI consulting and workshop programs.

The outputs are technically correct. The tasks get done. But something is off. The tone is generic. The recommendations don't quite match how you'd handle it. You spend time correcting and re-prompting when you could be using the output directly.

Most people assume this is a prompt quality problem. Write better prompts, get better outputs. And that's true up to a point.

But there's a deeper issue: the AI doesn't know who you are.

The Briefing Problem

Think about how you'd onboard a new employee. You wouldn't just hand them tasks on day one. You'd tell them how your business operates. What your communication style is. How you make decisions. What “good work” looks like in your context. What to escalate and what to just handle.

Without that briefing, they'd complete tasks competently while missing the nuance that makes the work actually useful to you.

AI agents have the same problem. Every time you open a new chat or deploy a new Lindy agent, the AI is starting from zero. It doesn't know your voice. It doesn't know how you make tradeoffs. It doesn't know that you want outputs in Google Docs, not email, or that you prefer short answers unless you specifically ask for depth.

So you re-explain. Every time. Or you correct. Or you accept outputs that are good-enough-but-not-quite-right.

The fix is a context profile.

What a Context Profile Is

A context profile is a plain text file that encodes the things your AI would need to know about you to work well. Not instructions for a specific task — context that applies across all tasks.

I was designing AI agents for Evan Baehr and his team at Arena Hall, a real estate and hospitality project in Austin with multiple buildings, events, and a team of people. We built agents for meeting prep, email management, and weekly synthesis. And every single one needed to understand the same baseline things about Evan: who he is, how the organization makes decisions, what format he wants outputs in.

We kept re-explaining this in every new prompt. So instead, we built one context file and loaded it into every agent.

The immediate effect was subtle but consistent. Agents started responding with less generic language. Recommendations got closer to what Evan would actually do. The time spent correcting went down.

I've done the same thing for myself. I have six context files:

• How I write (voice, sentence structure, things I never say)
• How I make business decisions (what I optimize for, what I avoid)
• Current priorities (so agents know what's important right now)
• Specific preferences (how to handle uncertainty, what format to use, when to escalate)
• Team and business context (who the key people are, what we're building)
• AI behavior guidelines (don't give me a summary at the end, don't use bullet points for narrative content)

None of these files is long. Most are a page or less. But I load them into any workflow that needs to produce work that sounds like me or knows how I operate.

Context Files as Reusable Assets

The key shift is treating context files the way you'd treat a good template or a reusable piece of code: build it once, use it everywhere.

Most people write context into individual prompts. “You are an expert assistant who writes in a conversational tone and…” That's fine for one-off tasks. But if you're running multiple agents — a meeting prep agent, an email agent, a research agent, a weekly review agent — you're repeating yourself constantly and getting inconsistent results because each agent has a slightly different understanding of who you are.

When Evan's team now deploys a new Lindy agent, the context file is one of the first things they load. The agent immediately has the baseline: how the organization operates, what Evan cares about, the communication format, the key contacts. They don't start from zero.

I call this treating context files as AI assets. They're not throwaway inputs — they're something you maintain, update, and reuse. When a business priority changes, you update the context file. That update propagates to every agent that uses it.

What Goes In a Context Profile

Here's a practical starting set of headers:

Voice and communication style. How do you write? What words do you use? What do you consciously avoid? If you have writing samples, summarize the patterns.

Decision-making guidelines. How do you make tradeoffs? What do you optimize for? What are automatic no's?

Values and priorities. What matters most in your work right now? What's a distraction?

Specific preferences. These are the things you'd tell a new assistant on day one. Output format, escalation criteria, communication channel preferences.

Business context. Who are the key people? What are you building? What are the current major projects?

You don't need all of these to start. Pick the one that would most improve your AI outputs right now.

Building It Without Writing It

Here's the fastest way to create a context profile: use AI to build it.

Give Claude or ChatGPT the category headers. Ask it to interview you by asking questions one at a time. Answer as you would in conversation. Then ask it to synthesize your answers into a structured context document.

The resulting file is usually better than what you'd write from scratch, because the questions surface things you'd forget to mention — preferences so obvious to you that you wouldn't think to write them down.

The Compound Effect

The improvement from a context profile in any single response is maybe 10%. That sounds small.

But 10% better, across every AI interaction, across every agent, every day — over weeks and months, that accumulates into a qualitatively different relationship with your AI tools. You stop correcting and start using. You stop re-explaining and start building.

The best time to build your first context profile is now. The second best time is after the next frustrating AI interaction where you think “this would be good if it just knew [thing about me].”

Write down that thing. Save it. That's the beginning.

I help founders and operators design AI workflows that actually fit how they think and work — not just technically correct outputs, but work calibrated to your voice, your decisions, and your priorities. If you're building an agent system and want it to feel more like you, reach out or check out my AI consulting and workshop programs.

Not suspected. Knew. She'd done the math on her time, compared her rates to what her work was worth in the market, and understood clearly that her best clients were paying rates she had set years ago when the firm was still proving itself.

And she still hadn't raised them.

This is the pricing paradox I see with consultants, freelancers, and service providers more than almost anything else: they know exactly what's wrong. The knowledge isn't the problem. The problem is that changing the price feels genuinely dangerous when the firm's income is the only thing between you and a financial problem.

When I sat down with Amanda to work through where she should focus, I gave her a counterintuitive answer.

Not: fix your operations. Not: build a better offer. Not: raise your prices.

Build a second revenue stream first.

Why Knowing You're Underpriced Isn't Enough

Most pricing advice misses the psychological side of the problem.

The standard advice is: know your worth, charge accordingly, and let bad-fit clients walk. This is technically correct. It's also not very useful when letting a bad-fit client walk means a real hole in your cash flow for the next quarter.

Amanda's situation was typical. Two long-term clients on rates from three years ago. Both sticky — they liked working with her — but both paying below what she'd quote to a new client today. New inquiries were going elsewhere because she was quoting her old rate (afraid to lead with the real number) or occasionally quoting the real number and losing people who balked.

The advice “just raise your prices” doesn't address why she hadn't already. The issue wasn't courage or clarity. It was that she needed every client she had.

The War Chest Idea

What changes when you have money coming in from somewhere else?

Everything, but specifically this: the asymmetry of the negotiation shifts. When your entire income depends on a client renewing, you're negotiating from a position of need. You hold the old rate because the risk of losing them is too high. You take the difficult call. You say yes to projects that aren't a great fit because you can't afford to say no.

But when you have $3,000 or $5,000 a month coming in from workshops, speaking engagements, or a course — money that doesn't depend on any of your existing clients — the conversation changes entirely.

Client pushes back on your new rate? You can quote it and mean it. They walk? You're covered.

You fire the clients you should have fired a year ago. You stop saying yes to work that drains you. You start quoting your actual number.

This is what I mean by “war chest.” The teaching income isn't just extra revenue. It's the financial cushion that makes running your primary business on your own terms actually possible.

Building the Teaching Revenue First

This is why my advice to Amanda was to invest in her personal brand and workshop program before touching her firm's pricing strategy.

The sequence matters.

If you raise prices before you have cushion, you're doing it under pressure. The first client who pushes back is terrifying. You might hold the line once. But you'll find reasons to make exceptions. You'll discount for “good clients.” You'll slowly drift back to where you started.

If you build the cushion first, raising prices is almost anticlimactic. You quote the new rate. Some clients accept it. Some don't. The ones who don't were probably not the right fit anyway. And you're fine either way.

The teaching income doesn't need to be massive to work. A few workshops a year can be enough. One speaking engagement. A small online course. The amount matters less than the fact that it exists and is independent.

The Invisible Benefit of a Personal Brand

Most people think about building a personal brand in terms of visibility — getting known, building an audience, attracting new clients through content.

That's all real. But there's a less-discussed benefit that might matter more: what it does to how you show up in every other business conversation.

When I started doing workshops in Austin years ago, I noticed a shift in how I operated. Not just that I was getting workshop revenue on top of consulting revenue. It was that knowing I had that income made me more confident in consulting conversations. I quoted my real number. I said no to projects that weren't right. I didn't scramble to fill every slot.

The personal brand revenue created pricing leverage in the consulting business. One stream funded confidence in the other.

The Practical Path

If you recognize yourself in this — you know you're underpriced, you're afraid to change it — here's a cleaner way to think about it:

What's one way you could teach what you know for money, independent of your current clients?

A workshop. A live training. A course. A talk at an industry event. These don't need to be elaborate. A half-day workshop at $500 a head with 10 people is $5,000. That's a meaningful cushion.

Build that first. Even a rough version of it.

Once you have consistent income from teaching, revisit your client pricing. You'll find it's a much easier conversation than you expected — because you'll actually be okay if it doesn't go your way.

I help consultants and service business owners design AI-assisted workflows and business models that give them more leverage — in their pricing, their time, and their client relationships. If this resonates, reach out or look into my AI consulting and workshop programs.

That sounds like a small thing, but it kept happening. Wrong numbers. Wrong building. Or no answer at all, just a vague “I don't have that information” from an AI that was theoretically loaded with every document we had.

We were setting up an AI system for Arena Hall — a real estate project with multiple buildings, each with its own history, files, and operational details. My instinct was to build one custom GPT and give it everything. Lease docs, floor plans, maintenance logs, contracts, renovation history. All of it.

Seemed efficient. One place to ask questions about the whole project.

It wasn't efficient. It was noisy.

Why Loaded-Up GPTs Underperform

Here's what I didn't fully appreciate at first: the context window isn't magic, and more files don't mean smarter answers.

When you load 80 files into a custom GPT and ask a question, it's searching through all 80 files every time. It doesn't automatically know which documents are relevant. It's weighing everything — lease agreements from the Gibson building while you're asking about the guest house, maintenance logs from three years ago while you need current specs.

The signal gets diluted. The GPT pulls in loosely related information, misses specifics that are buried somewhere in the pile, and produces answers that are… fine. Not wrong exactly. Just imprecise. And in real estate, imprecise is often worse than nothing, because you might act on it.

Our single Arena Hall GPT wasn't dumb. It was overwhelmed.

The Library Approach

Once we understood the problem, the fix was obvious: build smaller GPTs, not bigger ones.

One GPT for the Gibson building. Only Gibson building files — floor plans, lease, maintenance history, renovation specs. Nothing else.

One GPT for the guest house. Only guest house files.

One for the culinary operations. One for the real estate side generally.

Each GPT has a narrow job. It knows one thing well.

Now when someone asks about square footage, they open the Gibson building GPT. It doesn't have to sort through documents about three other buildings. It just has Gibson documents. The answer comes back fast and right.

The shift feels counterintuitive — shouldn't a bigger knowledge base produce better answers? But it's actually the same principle as hiring specialists instead of generalists for specific problems. You don't ask your accountant about your roof. You call a roofer.

How We Keep Track of It

A library only works if people know which book to open.

We track the whole GPT library in Airtable. Each row is one GPT:

• Name (descriptive, like “Arena Hall — Gibson Building”)
• Instructions (what it's for, how to use it)
• Files loaded (which documents are in it)
• Use cases (what kinds of questions it handles well)

Anyone on the team can look up which GPT to use before they start asking questions. Takes five seconds. Saves a lot of back-and-forth and wrong answers.

This part matters. Building the GPTs is only half the system. If people don't know the library exists or which specialist to summon, they'll default back to asking ChatGPT everything and getting mediocre answers.

What This Looks Like in Practice

Say we're doing a walkthrough of the guest house and we want to quickly check the last maintenance date on the HVAC system. Before: you'd open the big Arena Hall GPT, hope it had that file, and get an answer that may or may not be specific to the guest house.

Now: you open the guest house GPT. Ask the question. The GPT has maybe 15 files, all about the guest house. The HVAC answer is in there somewhere and it finds it.

Small context. Focused files. Better answer.

The Design Principle

Most people approach AI tools the same way they approach early software: one tool for everything. One spreadsheet. One folder. One assistant that handles all queries.

But AI assistants actually work better when scoped. A narrow, focused GPT is faster to query, more accurate in its answers, and easier to maintain. When you need to update information — new lease terms, a renovation — you update one GPT's files, not a massive shared document dump.

Before you finalize any custom GPT, ask: what's the smallest useful scope for this thing?

If you're building a GPT for a whole company, try building one per department first. If you're building one for a project, try one per major component. Fewer files per GPT. Cleaner answers.

The skill isn't building an AI that knows everything.

It's building a library and knowing which specialist to ask.

If you're designing AI systems for your business — whether that's document search, team knowledge bases, or client-facing tools — I help teams figure out the right architecture before they build. Reach out or check out my AI consulting and workshop programs.

The setup was straightforward: watch 20 AI-focused YouTube channels, get a summary of new videos delivered to Slack once a week. Instead of spending hours keeping up with what’s happening in the AI space, the agent does it automatically.

We were deep into the mechanics — which channels to track, how to structure the summaries, how to filter for signal versus noise — when I mentioned something I’d added to my own version of this workflow.

One extra prompt. One extra output. Almost zero extra cost.

The Second Prompt

Here’s what I told the agent, in addition to summarizing the video:

“If there’s a sponsor mentioned in this video, tell me who it is and log the company name to Google Sheets.”

Now, every week, alongside my AI research summaries, I get a running list of companies that are actively spending money to sponsor AI content.

That list goes straight to my podcast agency. I forward it with a simple note: I want to reach out to these.

The Productivity Show is always looking for the right sponsors. These companies have already demonstrated they’re willing to pay for AI-adjacent audiences. Finding them used to require manual research. Now the agent surfaces them as a byproduct of the research workflow it was already running.

The Principle: Secondary Intelligence

Most people design AI workflows around a single output.

The agent does the thing you built it to do, and that’s the end of the story. Which is fine. The primary job is worth doing.

But once an agent is reading content — processing a video transcript, scanning an email thread, reviewing a meeting recording — extracting a second signal from that same content is nearly free. The agent is already there. You’re just asking it to notice something else while it’s working.

A few examples of how this applies:

A meeting summary agent that already captures action items can also flag recurring objections your team hears from prospects.

An email monitoring agent that already drafts responses can also log unusual patterns — clients who suddenly stop responding, pricing questions that come up more often, complaints that appear in multiple threads.

A competitor monitoring workflow that already summarizes what competitors are publishing can also extract the tools, integrations, and partnerships they mention.

In each case, the second output costs almost nothing extra. The agent is already processing the input. You’re adding one more question to the same pass.

Why This Matters for How You Design Workflows

When you’re building an AI agent, the natural instinct is to define the job and ship it. The agent does X. Done.

The better habit is to pause before you finalize the design and ask: what other intelligence is already sitting in this content?

With YouTube videos, the answer was sponsor data. With emails, it might be sentiment signals or recurring topics. With meeting transcripts, it might be deal-risk indicators or the questions customers ask most often.

None of that requires building a separate workflow. It requires one more prompt in a workflow that already exists.

How to Implement the Sponsor Tracker

If you run a podcast, newsletter, or any content business that relies on advertising revenue, here’s the specific implementation:

Set up a YouTube monitoring agent for channels in your niche — the ones your potential sponsors are already buying. (Lindy, Make, and Zapier all support this kind of monitoring workflow.)

In the summarization step, add a prompt: “If a sponsor is mentioned in this video, extract the sponsor’s name and add it to a Google Sheet called [your sheet name]. If there is no sponsor, skip this step.”

Review the sheet weekly. Forward the names to your sales team or agency with context on which channels featured them.

The channels you’re monitoring are doing the market research for you. They’ve already sold ad slots to companies with budgets. Those companies are now visible to you, every week, automatically.

The Bigger Takeaway

Ilias was focused on the research angle — which was the right starting point. You build the primary workflow first, make sure it works, then layer in secondary extractions.

But the secondary extractions are often where unexpected value lives.

The primary job of the workflow was intelligence about AI developments. The secondary job turned out to be a weekly pipeline of sponsorship leads.

Build the thing you need. Then ask what else is already in there.

I help founders and operators design AI workflows that do more than one job. My AI consulting and workshop programs are where we build these kinds of layered systems. If you want to see what this looks like for your specific business, reach out.

It goes like this: “Before I start marketing or trying to grow, I need to get my systems in order. I need clean onboarding, a reliable team, and documented processes. Once I have all that, I’ll be ready to scale.”

Sensible, right? Take care of the foundation. Don’t build on sand.

The problem is that it almost always works in reverse. Founders who wait until operations are “ready” typically run out of runway before they ever get to growth. And the businesses that grow fast often do so precisely because they let operations catch up rather than leading with them.

The Conversation That Prompted This

A CPA I’ve been consulting with came to me wanting to focus on her internal processes before building her personal brand.

She had real reasons. Her team's systems were inconsistent. The onboarding flow had gaps. She’d lost a prospect recently because the client’s interaction with her team didn’t match the impression they’d gotten from Amanda herself.

Her thinking: fix the operations first. Then market. Then grow.

I pushed back.

Not because the operational problems weren’t real — they were. But because the order was wrong.

I’ve watched a lot of founders follow the “get ready, then grow” sequence. What usually happens is they spend months documenting processes, fixing internal workflows, preparing for volume that isn’t coming yet. Cash gets tighter. The urgency to grow increases. But now they’re operating from a weaker position than when they started, because they spent capital on operations instead of generating new revenue.

Why Revenue First Works Better

Here’s the counterintuitive thing about growing before your operations are perfect:

Revenue actually solves operational problems more effectively than operational work does.

When you have money coming in, you can hire someone to fix the processes. You can bring in a consultant. You can afford to take the time to document things properly. You can upgrade the tools.

When you don’t have money coming in, you’re trying to do all that operational work while also worrying about where the next client is coming from. Which means neither gets done well.

There’s also a specificity problem with fixing operations before growth. You’re optimizing for problems that might not be the real bottlenecks once volume arrives. The broken onboarding flow you spent three weeks fixing might turn out to be irrelevant when you have real clients — because the actual friction point was something you didn’t anticipate at lower volume.

Growth creates information. You find out what actually breaks when you have more clients, not when you’re imagining what might break.

What This Looked Like for Amanda

The path I laid out for Amanda was this: build the teaching and personal brand revenue first. Get paid for workshops, speaking, high-level strategy work. Use that income to fund the operational improvements — hire someone to run the day-to-day, build the systems you need, improve the team.

There was another benefit I mentioned that she hadn’t fully considered. Once she had revenue from teaching, she’d have a buffer that most service business owners never get. A buffer that lets you raise your prices without fear. That lets you tell a problematic client the relationship isn’t working. That lets you say no to work that doesn’t fit where you’re going.

Without the buffer, every client feels like you can’t afford to lose them. So you keep the bad-fit ones. You underprice to avoid losing business. You make operational decisions from anxiety rather than strategy.

Revenue creates options. Operational perfection without revenue just creates a more organized version of the same constraint.

The Broader Pattern

I saw this in my own business. Asian Efficiency started as a blog — no systems, no team, just writing and publishing. Revenue came from that content. Then I could afford to hire people, build processes, and invest in the infrastructure that made it run better.

The other path — spend the first year building infrastructure for a business that hasn’t found its audience yet — kills more companies than bad marketing ever has.

This applies everywhere. I worked with a logistics team once that had a long wish list for what they wanted to automate before they’d touch anything. My advice was the same: pick the one workflow that generates the most obvious ROI, make it work, then expand. Not because the other things don’t matter, but because the working thing funds everything else.

Do what pays first. Let the rest catch up.

The Practical Takeaway

If you’re sitting on a list of operational improvements you want to make before growing:

Ask yourself whether any of them directly produce revenue. If yes, do those first. If no, ask whether you can grow at all with operations as they currently are — not perfectly, but functionally.

If the answer is yes, grow first. Fix the rest with the proceeds.

If the answer is truly no — the operations are broken in a way that actively prevents delivering value — then fix the one thing that’s blocking delivery and nothing else. Then grow.

The goal isn’t perfect operations. It’s a functioning business that generates enough revenue to make the operations better over time.

I advise founders and service businesses on growth, AI systems, and building operations that scale. My consulting and workshop programs are built around a practical, revenue-first philosophy. If you want to explore what this looks like in your specific business, reach out.

Amanda, a CPA I’ve been consulting with, made it through her most recent tax season without a single one.

“I didn’t have to call tax software support. Not one time. After I created that GPT.”

And then she added something that stuck with me: “That’s unheard of. No tax practitioner would tell you they didn’t have to call the software company at all.”

She’s right. This isn’t a minor improvement. It’s the kind of thing that makes other CPAs in the industry do a double-take.

What She Actually Built

Before the season, we worked together to build a custom GPT trained specifically on her practice.

Not generic tax knowledge — she’s not trying to replace her own expertise with Wikipedia. The GPT was built around her specific methodology: how she structures S-corp entities for her client base, the deductions that come up most often, the error patterns she’s seen repeat across hundreds of returns, and the review criteria she applies when checking her team’s work.

The questions Amanda would normally escalate to software support — nuanced edge cases, situations where the software behavior wasn’t matching what she expected — the GPT already understood those. Because the GPT was built from Amanda’s own knowledge of how those situations play out in practice.

It’s a subtle but important distinction. Generic AI tools know a lot about tax law in general. Amanda’s GPT knows her firm’s way of handling tax situations specifically.

The Team Effect

The impact showed up in another way that surprised even her.

One of Amanda’s team members spent two hours trying to work through a complex tax scenario. They couldn’t get to a clear answer. Amanda ran the exact same question through the custom GPT.

Fifteen minutes.

This is the part of custom GPT builds that most people don’t anticipate when they start. You think you’re building a tool for yourself. What you’re actually building is a way to distribute your expertise across your team, available at any hour, for any question, at no marginal cost per use.

Amanda’s senior judgment used to be a bottleneck. Complex questions had to wait for her bandwidth. Now that same judgment is accessible to everyone on her team, whenever they need it.

What Most People Get Wrong About Custom GPTs

There’s a version of this that most people build — and it’s not this.

The typical approach: take a general-purpose AI tool, give it a generic prompt about your industry, and use it as a faster search engine. Ask it things. Get answers.

That’s useful. But it’s not what Amanda has.

When you build a GPT trained on your actual methodology — your documented approach, your historical cases, your review criteria — you’re doing something different. You’re codifying expertise that normally lives only in your head and making it deployable.

The software support team answers questions from tens of thousands of accounting firms. They know the software well. They don’t know Amanda’s firm, her clients, her preferred structures, her typical edge cases.

Amanda’s custom GPT does.

That gap is where the result comes from. It’s not that the GPT is smarter than the software support team. It’s that it knows things about Amanda’s practice that no generic support line ever could.

The Broader Principle

There’s a way to think about AI in professional services that goes beyond “using AI to speed things up.”

It’s this: your expertise is an asset. And like any asset, it can be structured so it works harder.

Right now, your expertise works when you’re working. It’s available when you’re available. It answers questions when you’re in the room. When you’re not, things wait — or get answered incorrectly by someone with less experience.

A well-built custom GPT changes that. Your judgment becomes available around the clock, to any team member who needs it, without requiring your direct involvement.

That’s what eliminated Amanda’s support calls. Not because the software got easier — it didn’t. But because her team now has access to a system that carries her knowledge of how to navigate it.

How to Start

If you want to build something like this for your own practice:

Start by identifying where the support calls or escalations actually come from. What are the questions your team asks you repeatedly? What are the scenarios that require you to stop and think through carefully before answering?

Those are your training materials.

Record yourself explaining your reasoning on complex cases. Document the patterns you look for in review. Write out your criteria for the decisions that come up most often.

Then build the GPT from those materials.

You don’t need to be technical to do this. What you need is your own expertise, structured and written down. That’s the hard part — and it’s the part that makes the GPT useful rather than generic.

Amanda went through that process with me over several months. By the time tax season arrived, the system was substantial enough that the software support line never rang.

That’s the goal: not faster answers to generic questions, but the right answers to your specific ones.

I help professional service firms build custom AI systems trained on their specific expertise. My AI consulting and workshop programs are where we do this work. If you want to see what this looks like for your practice, that’s the place to start.

The volume spikes. Deadlines compress. Clients are anxious. Every error has a real consequence. It’s the stretch of the year that separates practices that have their systems together from ones that are just hoping to make it through.

Amanda, a CPA I’ve been working with, went into her most recent tax season with one fewer person than she expected to have.

Her tax manager went on unpaid leave. And instead of scrambling to backfill the role, Amanda made a decision: she was going to find out whether AI could cover it.

It did.

“Without AI, it wouldn’t have been possible. It would have been humanly impossible.”

That’s her assessment after the season closed. Not a marketing claim. Her exact words.

What “Humanly Impossible” Actually Means Here

The phrase is worth unpacking, because “AI saves time” is such a tired framing at this point that people have stopped hearing it.

This isn’t a 20% efficiency gain. It’s not “we moved faster on the things we were already doing.”

A tax manager handles things like: catching errors in returns, researching complex deductions and entity structures, answering nuanced client questions, reviewing the work of more junior staff. It’s judgment-intensive work. The kind of thing you’d normally only trust to someone with years of experience in the field.

AI handled it.

Not as a replacement for expertise — Amanda has deep expertise herself — but as a force multiplier that made it possible for one experienced practitioner to do the work that usually requires a team.

What They Actually Built

Before tax season, we built a set of custom GPTs tailored specifically to Amanda’s practice. One for tax review and error-catching. One for complex case research. One for drafting client-facing answers to the kinds of questions that come up constantly during filing season.

The idea wasn’t to hand everything to the AI. It was to take the tasks that required hours of careful reading and cross-referencing — the kind of work that used to bottleneck on a senior person — and make them fast, reliable, and repeatable.

The results showed up in an unexpected place. Amanda’s outsourced team in India, who work with multiple American accounting firms, noticed the difference. Her team lead wanted to know where she was getting her training. Because Amanda was operating at a level that other firms weren’t matching, and the team could see it in the quality and speed of what they were being asked to review.

She was strategic about not giving away all her prompting techniques. But she let them use the tools. Because at that point, it was a competitive advantage — and she knew it.

The Metric Nobody Talks About

Most conversations about AI in professional services focus on time savings. “We cut our proposal time by 30%.” “We’re spending fewer hours on research.”

Those are real wins. But they’re not the most interesting question.

The more interesting question is: what becomes possible that wasn’t possible before?

Amanda didn’t save a fraction of a tax manager’s time. She covered the entire function during the highest-pressure period of the year. She went from a business that needed that role filled to a business that could operate without it — at least through the season.

That’s a different category of outcome.

And it changes the calculus around hiring. Because the instinct, when a key team member goes on leave, is to find a replacement or pull in a contractor. The assumption is that the role needs a human.

What Amanda found out is that the assumption isn’t always right anymore.

The Implication for Your Business

This doesn’t mean AI replaces professional expertise. Amanda’s own knowledge and judgment were essential to everything that happened. The AI isn’t independently practicing accounting.

But it does mean that one experienced person, with the right AI tools configured for their specific practice, can do what previously required multiple people.

The practical implication: before you hire for a role you think you need, find out what AI can actually do in that role.

Not in theory. Run the experiment. Build the tools. See what happens in practice.

A lot of business owners I talk to are planning hires for roles that AI can already cover — partially or fully. They just haven’t tested it yet. Because the assumption that the role requires a human is so deep they haven’t questioned it.

Amanda questioned it because she had to. The leave happened, the season was coming, and she needed to know.

But you can run that experiment on your own timeline, before the crisis forces it.

The Practical Path

If you want to replicate what Amanda did:

Start with the highest-volume, most repetitive judgment tasks in your practice. The questions clients ask constantly. The review steps that slow everything down. The research that takes hours because the answer is buried in a document somewhere.

Build a custom GPT or AI workflow for one of those tasks. Test it. See how accurate it is. Refine it.

Then expand from there.

Amanda didn’t start with a comprehensive AI system. She started with specific tools for specific bottlenecks. Over time, those tools compounded. By tax season, the system was substantial enough to cover a key role.

You don’t have to get there all at once. You just have to start.

I work with small businesses and professional service firms to design and implement AI workflows that change what’s possible in their operations. If you want to explore what this looks like for your specific practice, reach out through my consulting and workshop programs.

His name is Brooks. He ran a productivity blog. Same audience as Asian Efficiency, same topics, similar format. In any reasonable sense of the word, we were competitors.

I called him to offer him a job.

The Problem I Was Trying to Solve

For most of Asian Efficiency’s history, I was doing everything. Running the team, writing content, managing courses, and handling operations. All of it.

Which was fine when the company was small. But as it grew, I started noticing something: the work I loved — teaching, speaking, getting in front of audiences, thinking through big ideas — was getting crowded out by the work of running the business.

The irony of building a company around productivity is that you spend a lot of time doing things you’re not actually best at.

I wanted to be the person out front. Teaching live workshops. Doing partnerships. Building my personal brand. That’s where my energy was. That’s the work that felt like it actually mattered to me.

But the business needed someone running it. And that person couldn’t be me anymore — not if I wanted to focus on what I actually cared about.

Why a Traditional Operator Wasn’t the Answer

My first instinct was to find a COO or general manager. Someone with operations experience, management credentials, the usual profile.

But when I thought about what the job actually required, I realized those credentials weren’t what I needed.

Running Asian Efficiency meant understanding the audience. Caring about productivity as a topic. Being able to jump on a podcast, write a post, talk to customers — not just manage spreadsheets and processes. This wasn’t a pure ops role. It was a hybrid of operator and practitioner.

A traditional manager would need a year just to learn the space.

That’s when I thought about Brooks.

He’d already built it. He understood the audience. He cared about the subject matter. He’d been doing many of the same things I’d been doing — just in a smaller operation.

The Pitch

I reached out and made him a simple offer: run my company instead of your own.

Same work. Same industry. Same audience. But with an existing team, an established brand, and consistent six-figure income — instead of the roller coaster of building a solo business from scratch.

He was at the point in his solo journey where the income inconsistency was wearing on him. Two kids heading to college. A real desire for stability.

I wasn’t offering him a step down. I was offering him a chance to do the exact work he was already doing — at a bigger scale, without the financial uncertainty.

He said yes.

What Each of Us Got

Brooks got stability. A real paycheck. A team to work with. The ability to do the content and podcasting and customer work he loved — without the revenue anxiety of running a solo operation.

I got freedom. I could step back from day-to-day operations. Focus on the workshops, the speaking, the consulting clients, the personal brand work that I found most meaningful. Asian Efficiency kept running without me being the bottleneck for everything.

That’s a clean trade.

The Pattern I Keep Seeing

Since then, I’ve watched a lot of business owners get stuck in the same trap I was in. They’re the hero of their own company. Every decision flows through them. Every piece of work gets reviewed by them. Every client ends up talking to them eventually.

And the business can’t grow past their personal bandwidth.

The question most founders ask is: “How do I do all of this?”

The better question is: “Who already knows how to do this — and why would they want to?”

Sometimes that person is someone on a hiring platform. Sometimes it’s a referral. But sometimes… it’s someone who’s been doing a version of your job themselves, who would love to do it at scale with someone else taking the financial risk.

Your competitor might be looking for exactly what you’re offering.

What This Looks Like in Practice

If you’re a founder or expert service provider who wants to step back from operations:

The person you’re looking for probably already understands your work. They’ve been in your industry. They know your audience. They can step in fast — not because they’re a generalist manager, but because they already care about the same things.

Look at who’s running smaller versions of what you’ve built. Ask yourself: would they thrive doing this inside a larger operation with stable income? Would I thrive having them run this?

It’s not a conventional hire. But it works.

I advise founders and operators on business design, AI systems, and building companies that run without requiring your constant presence. My AI workshops and consulting programs are built around the same principles — clarity first, then systems, then freedom.

So when he came to me wanting to build a meeting processing agent, I skipped the usual explanation of how AI agents work and just asked him one question:

“If you were building a meeting table in Airtable, what columns would you want?”

He listed them without hesitating. Meeting ID. Date. Attendees. Action items. Who owns each one. Deadline. Project.

Thirty seconds, maybe.

“That’s your schema,” I told him. “Give that structure to the agent, and it’ll know exactly what to produce every single time.”

He got it immediately. Because it wasn’t really a new concept — it was the same thing he’d been doing in databases for a decade, just applied to an AI workflow.

The Problem Most People Have With AI Agents

When an agent produces inconsistent results — sometimes capturing action items, sometimes not; sometimes including owners, sometimes leaving them blank — the instinct is to fix the prompt.

So people rewrite the prompt. Try different phrasing. Add more instructions. Maybe switch models.

And they get marginally better results for a few runs before the inconsistency comes back.

Here’s the thing: inconsistency in AI output is almost never a prompt problem. It’s a schema problem.

The agent is inconsistent because it hasn’t been given a clear structure to fill. It’s improvising. Deciding for itself, run by run, what the output should look like.

The fix isn’t a better prompt. It’s a defined schema — the exact structure you want the agent to produce, every time, without exception.

Schema First, Execution Second

Think of it like building an Airtable table. Before you enter a single record, you define your columns. You decide what fields matter, what format they take, what’s required versus optional.

Once those columns exist, data entry is just execution. You’re not reinventing the table structure every time you add a row.

AI agents work the same way.

Define the output structure first — as a JSON schema, a markdown template, a set of required fields, whatever format fits the tool. Once the agent has that schema, it’s not guessing what you want. It’s filling in the blanks.

Meeting ID: [extract from transcript]
Date: [extract from transcript]
Attendees: [list names]
Action items: [list each item]
Owner: [assign from context]
Deadline: [extract or mark TBD]

That’s it. The agent runs the same logic, produces the same structure, every time.

What Happens When You Get This Right

I work with someone who was spending $9 per query on an AI workflow. The prompt was detailed. The model was good. But the architecture was wrong — the agent was trying to do too much in one shot, without a defined structure for what it should produce.

We didn’t change the prompt. We redesigned the schema. Broke the task into stages. Defined exactly what each stage should output. Gave the agent clear structured targets at each step.

Same AI. Same task. $0.07 per query.

That’s a 99% cost reduction from a schema fix, not a prompt fix.

The bottleneck was never the AI. It was the architecture.

The Agent Design Backwards Principle

My approach to building agents starts with the output artifact — the exact thing the agent should produce — and works backward from there.

What does the finished product look like? What fields does it have? What format does it take?

Once you can answer that, you define: what does the agent need to produce it? What inputs, what steps, what rules?

Most people do this in the wrong order. They start with the tool or the prompt and work forward, hoping a consistent output emerges.

It rarely does. Because the output structure was never defined. The agent is making it up each time.

Start with the schema. Everything else follows from there.

The Practical Question

Before you write another prompt, ask yourself: what is the exact output I want this agent to produce?

Not “summarize the meeting.” Not “extract the key points.”

What specific fields? What format? What’s required? What happens if something is missing?

Write that down. Turn it into a template. Give the agent that structure.

If you’ve ever built a spreadsheet or a database table, you already know how to do this. The skill transfers directly.

Evan got it in thirty seconds. His agent has been running consistently ever since.

I help founders and operators design and build AI systems that run reliably. My consulting and workshop programs are built around this design-first methodology. If you’re building agents for your own business, the process starts with getting the schema right.

In this encore episode, we break down the exact strategy used to build Asian Efficiency from the ground up — stacking high-leverage skills, building a network that opens doors you didn’t even know existed, and using coaching to close the gap between knowing what to do and actually doing it. Simple, actionable, and less than 10 minutes. Your future self will thank you.

Visit www.asianefficiency.com for more productivity tips and tactics.

Visit Upwork.com right now and post your job for free.

Links

• Upwork
• 25X Productivity Coaching
• Asian Efficiency
• Gary Vaynerchuk
• Michael Dell

If you enjoyed this episode, follow the podcast on Apple Podcasts, Spotify, Stitcher, Overcast, Pocket Casts or your favorite podcast player. It’s easy, you’ll get new episodes automatically, and it also helps the show. You can also leave a review!

She told me upfront that she was probably the least technically-minded person in the room. No coding experience. Barely used anything beyond basic apps. Came because a friend dragged her along.

By the end of the afternoon she had built a custom GPT that automated her weekly menu-writing process. Something that used to take her four hours was down to thirty minutes.

She wasn’t an outlier. She was the rule.

The Problem With Explaining AI

Here’s the pattern I see constantly: someone reads articles about AI, watches YouTube videos, maybe even takes a course. They understand, in the abstract, that AI is powerful. They know it can help with things like writing, research and automation.

But when you ask them what they’d actually build for their work? Blank stare.

The knowledge is there. The application is missing.

This is the “you don’t know what you don’t know” problem. You can’t imagine use cases you’ve never seen. The mental models haven’t formed yet. All the explanation in the world doesn’t fill that gap — because the gap isn’t information, it’s experience.

I figured this out early in my workshop days. I started teaching AI workshops in Austin because my online courses weren’t creating the same lightbulb moments for local people. At the first few workshops, I showed up with slides. Explanations of what AI could do. Clear frameworks for thinking about it.

Good content. But not the right format.

The shift happened when I started designing workshops around live demos instead of explanations. Not “here’s what you could do with AI.” But “watch me do it right now, in real time, on a real problem.”

What Happens During a Live Demo

When I do a live screen-share demo with a client or in a workshop, I usually don’t get more than about five minutes before someone interrupts.

Not because anything went wrong. Because they just had an idea.

“Wait — could you do that for my client reports?”

“That same thing would work for my research workflow, right?”

“Is there a way to apply this to the emails I get from vendors?”

The ideas come fast because seeing a workflow execute on a real task makes the possibility space concrete. Before the demo, they knew AI could “help with work.” After the demo, they know it can run their specific meeting follow-up, their specific content pipeline, their specific data problem.

I had a coaching call with Ilias — a structural engineer and investor — where instead of answering his questions about AI, I just shared my screen and started running my agents. Within ten minutes he had generated more actionable ideas for his own workflow than in any conversation we’d had before.

He didn’t need to understand the mechanics. He needed to see the shape of it.

Why Most AI Teaching Fails

Most AI content — articles, courses, even workshops — leads with explanation. Here’s what a large language model is. Here’s how prompting works. Here’s a framework for thinking about automation.

All of that is useful eventually. But it’s almost never the right starting point.

People don’t get excited about how AI works. They get excited about what it makes possible for them. And they can’t know what that is until they’ve seen something close enough to their own reality to connect the dots.

The chef in my workshop didn’t care how GPT worked under the hood. She saw me generate a structured recipe format from a few bullet points, realized that was exactly what she spent hours doing every week, and the rest was just her building her own version.

That’s the moment. That’s what demonstration creates.

The Principle Applied

This applies beyond AI teaching. It’s a principle about how people learn anything that requires imagination.

If you’re trying to help someone see what’s possible with a new tool, system, or approach, explanation creates awareness. Demonstration creates belief. And you need belief before anyone does anything.

So if you’re teaching AI — to clients, to a team, in a workshop — here’s the practical shift:

• Instead of explaining what AI can do for them, show them what AI does for you.

Run your actual workflows. Share your real screen. Use your live environment.

The imperfection is part of it. When something takes an unexpected turn or you have to troubleshoot in real time, that’s not a flaw — that’s the proof that this is real and you know how to navigate it.

The polished demo reel doesn’t create the same response as watching someone actually use their tools.

• Structure demos around their context, not yours.

If you’re coaching a lawyer, find the part of your workflow that maps closest to contract review or client intake or research. If it’s a restaurant owner, find the part that looks like menu planning or scheduling or marketing.

The closer the demo is to their actual work, the faster the ideas flow.

• Ask: “What in your work looks like this?”

After a demo, that’s the only question you need. It invites them to do the work of connecting their problems to what they just watched. Most of the time they already have three answers before you finish the sentence.

The Bottom Line

You can explain AI for an hour and people will nod along. Show them a 45-second workflow and they’ll interrupt you with ideas.

The gap isn’t knowledge. It’s experience. And experience comes from seeing, not hearing.

If you want people to believe in what’s possible, stop explaining and start showing.

I run hands-on AI workshops in Austin and online where the entire structure is built around live demos. If you’re building your own AI training program or want to develop this skill, the Two Hour Workday workshop covers the same demo-first methodology.

So I started hosting dinner parties. Small ones, six or eight people. I’d put together a mix of people I thought would genuinely connect, make a reservation somewhere nice, and just show up with good questions.

I did 50 of them over two years.

Not because I was building a business. Because I genuinely enjoyed it. Because I liked being in rooms where interesting people were meeting each other for the first time.

What I didn’t realize at the time was that I was running a service people would have paid for.

The Lightbulb Moment

Earlier this year, I was sitting in a workshop when a thought hit me out of nowhere. I started running through all the things I already do for the people in my network: make introductions, organize events, host investor dinners and cigar nights, and put together gatherings.

And then I thought: what if I just charged for it?

The idea is simple. Go to 20 people you know well — entrepreneurs, investors, operators, whatever your network looks like. Tell them: pay me $25,000 a year.

In return, you provide: monthly introductions tailored to what they’re building or looking for, quarterly in-person gatherings, and ongoing access to your network and your judgment about who should meet whom.

20 people × $25K = $500,000 per year.

Not for speaking fees. Not for coaching. Not for content. For doing the thing you were already doing anyway — just with structure, consistency, and a price.

I’ve started calling this the “productized connector” model.

Why This Works

The connector’s value proposition is different from most knowledge businesses. You’re not selling expertise or access to information. You’re selling access to a curated room and the judgment of someone who knows how to work one.

That’s genuinely rare.

Most people have networks. Very few people have networked intentionally enough that they can make introductions that actually change someone’s trajectory. When you’re good at this, the people around you feel it. They know that if you make an intro, it’s worth following up on.

That’s what the $25K is actually paying for. Not the event ticket. The trust and curation behind it.

There’s also a model here for people who already run events and wonder why it doesn’t feel like a real business. You can sell tickets. Or you can sell membership — ongoing access to a curated community with a person who’s responsible for the quality of the room.

Membership is a stickier, more valuable product than a ticket.

The Natural Networker Problem

Most people who would be great at this never build it because they give it away for free.

They make the intros because they enjoy it. They host the dinners because they love getting people together. They organize the gatherings because it’s genuinely fun.

That instinct is the whole point. You can’t manufacture a natural connector. The enjoyment is part of the value.

The shift isn’t about charging more for the same behavior. It’s about recognizing that the behavior has real worth and putting structure around it so it can be delivered consistently.

When I filled my first workshop, I didn’t run ads or write a lot of content. I personally texted and emailed about 20 people I thought would genuinely benefit. Not to pitch — to invite. Most of them came. Some referred others.

That’s the same muscle the productized connector is built on. The difference is that in the workshop model, the value is the content. In the connector model, the value is the room.

What It Actually Looks Like

Here’s a rough version of how you’d run this:

Membership tier: 20 members at $25K/year ($2,083/month)

What members get:

• 1-2 targeted introductions per month, personally vetted
• Quarterly in-person gathering (dinner, outing, casual event)
• Private channel or group for staying in touch
• Access to your judgment when they ask “who should I talk to about X?”

What you do:

• Know your members well enough to make good intros
• Organize 4-5 gatherings per year
• Say no to bad fits (membership quality degrades if you let in the wrong people)

The operational overhead is low. You’re not running a conference or a publication. You’re hosting dinners and making phone calls — probably things you already do.

The membership model also solves the awkwardness of asking for things. When someone pays to be in your network, they get to ask for introductions without feeling like they’re imposing. And you get to be the person who helps them without keeping a mental ledger of who owes what.

The Question Worth Sitting With

If you’ve been making introductions, organizing events, and being the person people call when they need to meet someone — you already have the asset.

The only question is whether you’re willing to structure it and ask.

Most natural connectors don’t, because it feels like monetizing a friendship. But the productized connector isn’t charging for friendship. It’s charging for professional curation and access — a service with real and measurable value.

The dinners I threw in Austin in 2014 weren’t a business. But the relationships I built doing it became the foundation for every workshop I’ve run, every partnership I’ve formed, every room I’ve been invited into since.

That’s what a well-run network is actually worth.

If you’re already running events or thinking about building a connector business, I’d be curious what model you’re using. Drop a reply.

Three days at a conference. Dozens of conversations. A stack of handwritten notes. Business cards in your pocket. A WhatsApp group you got added to. At least fifteen people you told yourself you’d reach out to.

Then you get home. Luggage gets unpacked. Email is backed up. Meetings are stacked. And somewhere in the chaos, all that conference momentum quietly dies.

I’ve done this enough times that I decided to build a system around it. I call it the conference commando workflow.

The Problem: You Have Better Conversations Than Follow-Up

Most conferences generate a lot of raw material. At a recent 3-day event, I came home with:

• A PDF membership directory with over 100 pages of attendees
• Granola transcripts from multiple small-group sessions — 10-person conversations that I’d recorded throughout the event
• Six pages of handwritten notes
• Photos I’d taken of whiteboards and session materials
• A WhatsApp group with names, numbers, and context

In the old world, turning all of that into something actionable would require hours of manual work: going through notes, looking up names, adding people to a CRM, writing down what we discussed. Realistically, most people never do it fully. The follow-up is partial, late, and weaker than the original conversation deserved.

The Capture Everything principle is the starting point: recordings, notes, PDFs, photos — all of it is raw material that has downstream value. The problem isn’t capturing it. Most people actually do capture things at events. The problem is what happens after.

The Workflow

Here’s how the conference commando workflow runs.

Step 1: Centralize everything into Google Drive immediately.

As soon as I’m home, all the materials go into one folder: the directory PDF, the Granola transcript files, photos of my handwritten notes. The WhatsApp group chat gets exported too.

The reason for Google Drive first is that it solves the “too much for a single chat window” problem. When I first tried feeding a 100-page guest directory directly into ChatGPT, it timed out and crashed. Drive acts as the intake layer — the materials are accessible to agents without requiring you to paste everything into a prompt.

Step 2: Run the Lindy workflow.

The Lindy workflow does four things:

1. Extracts every new person I met from across all the materials and adds them to Airtable (name, company, what we discussed, any notes)
2. Pulls the key ideas and learnings from each session transcript
3. Identifies project opportunities that came up in conversation
4. Generates a task list of actual follow-up items with context

The output isn’t a summary. It’s a structured brief. Every person I met has a record. Every conversation that had an idea in it has a note. Every commitment I made or intention I stated has a task.

Step 3: Review and send.

I go through the Airtable records, make any corrections, and start working the follow-up list. Most of the heavy lifting is already done.

Why This Works: The 80-20 Principle for Agents

The 80-20 agent building framework says to automate the tasks that happen regularly and cause the most friction — not the impressive one-off use cases.

Post-conference follow-up seems like a one-off, but anyone who attends multiple events per year knows it’s actually a recurring problem. The same friction hits every single time. And the cost of not solving it is compounding: missed relationships, unmade introductions, project ideas that never got off the ground.

Building the workflow once means it runs every time. The ROI compounds.

There’s also a timing insight worth naming. The reason most conference follow-up underperforms isn’t effort — it’s lag. The longer you wait, the colder the connection. People remember you well right after the event. Two weeks later, you’re a vague memory.

With the conference commando workflow, I’m usually back in contact with the most important people within 48 hours of getting home. Not because I’m faster, but because the system is.

What the Output Actually Looks Like

For a three-day event with about 80 attendees, the workflow produces:

• An Airtable base with every new contact, tagged by conversation type and follow-up priority
• A project ideas document pulling the most interesting threads from session discussions
• A task list with specific actions (email X about Y, connect A and B, read the paper Z mentioned)

The whole thing runs in about 30 minutes once the workflow is set up.

Compare that to the alternative: hours of manual work, or — more often — a pile of notes that sits untouched until the next event makes you feel guilty.

The Real Insight

The conference commando isn’t about networking automation. It’s about not wasting the networking you already did.

You went to the event. You had the conversations. You exchanged contact information. All of that value is sitting in a pile of raw materials. The workflow just unlocks it — quickly, completely, and while the relationships are still warm.

That’s the thing most productivity advice misses about conferences. The ROI isn’t in going. It’s in what you do in the 72 hours after you get home.

This workflow uses Lindy, Airtable, and Granola. If you want to build something similar, the Two Hour Workday workshop covers the full agent design process including how to structure multi-source ingestion workflows.

And it’s true. Mostly.

But there’s a condition attached to it that almost nobody mentions, and it’s the reason most people’s morning routines stop sticking within two weeks of starting them.

Routines only set you free when they’re built around what you actually value.

The Values-Routine Gap

A few months ago, I was coaching Patrick through how he designs his days. He’s an entrepreneur, multiple projects, genuinely motivated person. He had a values list — health, family, growth, deep work. Written down. Filed somewhere.

But when we looked at how his days were actually running, the list and the life didn’t match.

Health was first on the list. His last three weeks had no scheduled exercise. Growth was up there too. His learning time had been swallowed by meetings.

He wasn’t being lazy. He wasn’t dishonest about his values. He just had a values list he wrote once and a routine he’d assembled by accident over years. The two never talked to each other.

I’ve seen this pattern across hundreds of conversations. Most people have two separate operating systems running simultaneously: the values they say they hold and the habits that actually fill their days. They drift apart, and nobody notices until the frustration gets loud enough.

This is what I call the values-routine gap. And closing it is what “routine sets you free” is actually about.

Why Discipline Isn’t the Answer

The default fix people reach for is willpower. I just need to be more disciplined. I need to wake up earlier. I need to want it more.

But this is treating a design problem as a character problem.

When your routine isn’t aligned with your values, following it requires constant internal negotiation. Every day you’re overriding some other pull to show up to the thing. That’s exhausting. It’s why New Year’s routines die in February — not because people lack commitment, but because the routine was designed around what sounds impressive, not what they actually care about.

The AE principle I keep coming back to here is simple: happiness and wellbeing are prerequisites, not rewards. You don’t earn the good life by grinding through routines that drain you. The structure of your days should make you more yourself, not less.

Reverse-Engineering From Values

The Ideal Week method I use with clients starts in the opposite direction from most productivity systems. Instead of asking “what do I need to get done?”, we ask “what matters most to me, and what does a day look like when I honor that?”

Here’s how the process works:

1. Write down your top four or five values. Not aspirational ones — real ones. Health, family, creative work, community, learning. Whatever is actually true for you right now.
2. Ask: what does each value look like in a week? If growth is on the list, maybe that’s 30 minutes of reading each morning. If serenity is on the list, maybe that’s protected evenings with no screens and no work.
3. Block those things first. Before meetings. Before deliverables. The values get the best time, not the leftover time.
4. Then build the rest of your week around what remains.

When I walked through this with someone recently, two values kept coming up that had never made it onto her calendar: serenity and adventure. So we built them in. Serenity time became 8-9 PM on four evenings — no devices, no work, wind down. Adventure moved to Wednesday evenings: something physical, outdoors, or social. Saturday protected for longer social time.

Her week didn’t change dramatically in terms of output. But the hollow feeling lifted pretty quickly.

The Calendar + Credit Card Test

There’s a simple diagnostic I use to find the gap. Pull up your calendar from the last two weeks. Pull up your recent transactions. Then compare both against your values list.

Where does your time actually go? Where does your money actually go?

Most people find the mismatch almost immediately. The client who says health is her priority but hasn’t worked out in three weeks. The person who says family comes first but whose evenings are wall-to-wall with work catch-up. The entrepreneur who values creativity but hasn’t had an uninterrupted creative block in a month.

The gap isn’t a moral failure. It’s a design failure. And it’s fixable.

What Alignment Actually Feels Like

When your routine and your values are running on the same engine, the daily friction drops. You stop having to convince yourself to do the things. The structure carries you.

That’s what “routine sets you free” is actually describing. Not the liberation of habit for its own sake. The liberation that comes from designing your days so that who you are and how you live are pointing in the same direction.

It doesn’t require a dramatic overhaul. One or two changes per week, consistently applied, compound faster than any reset.

The question to sit with: of your daily routines right now, how many actually reflect something you genuinely care about?

If you want help building a week that matches your values, the Ideal Week process is part of the Asian Efficiency Productivity Academy. It takes a single afternoon and gives you a template to iterate on every week.

I’ve seen it in clients. I’ve felt it myself. You close the laptop, look back at the day, and you can’t point to a single thing you actually moved forward. The day blurred past. You were responsive. You showed up to things. You put in the hours. But the hollow feeling is there anyway.

The problem isn’t effort. It’s currency.

Progress Is a Currency

I was coaching Patrick, an entrepreneur who runs a busy operation — clients, team, projects. He described the same pattern: full weeks, but a kind of emptiness at the end of them. Lots of motion, not much feeling of momentum.

I told him: progress is the currency of fulfillment at work.

When you make real progress, you feel it. You went into the day knowing what you wanted to do, you moved it forward, and you can see the difference. That’s the feedback loop that makes work feel meaningful.

But progress has two requirements — and you need both.

First: clarity. You have to know what you’re actually trying to accomplish. Not “work on the project.” Not “catch up on stuff.” A specific, declared intention. Something you could measure at the end of the day.

Second: forward movement. You have to actually advance it. Even a small step counts, as long as the thing moved.

Most people have execution without clarity. They work hard all day. They just don’t know what they were working toward. So the effort doesn’t register as progress. It registers as busyness. And busyness doesn’t pay in fulfillment.

Why Busyness Feels Empty

In the TEA Framework — Time, Energy, Attention — attention is the hardest currency to manage. You can have time on your calendar and energy in your body, but if your attention is scattered across twenty things, nothing gets finished. Nothing counts.

Busyness often looks like an attention problem. Technically the time was spent. But it was spent in fragments, on reactive work, on things that didn’t line up with what you actually care about.

The fulfillment signal doesn’t fire when you answer emails. It doesn’t fire when you sit in meetings. It fires when you finish something you set out to do. When you look back and see that the thing moved.

I used to experience this myself. I’d have a long to-do list, tackle five or six things during the day, and end it feeling like nothing was actually done. Just tasks half-finished, next day same story. Once I shifted to identifying the one thing I wanted to move forward each day — and protecting time to actually do it — the end-of-day feeling changed completely.

The Ten-Second Fix

Before you start your day, answer one question:

What’s the one thing, if I move it forward today, I’ll feel good about tonight?

That’s it. One question. Ten seconds.

The answer becomes your anchor. Everything else on the list can fight for whatever time is left.

Then do three things:

1. Block time for that one thing — even 90 minutes is enough
2. Do it first, before the day pulls you elsewhere
3. At the end of the day, ask yourself: did it move?

You won’t always hit every item on your list. Some days the reactive work is unavoidable. But if the thing you cared about most moved, even a little, the day counted.

This Is What Theme Days Are For

One of the things I coach on for people with multiple projects is the theme days approach. Monday for strategy and planning. Tuesday for client work. Wednesday for content. And so on.

The reason it works is the same reason clarity matters: when you sit down on a Tuesday knowing today is for client work, you have an anchor. You’re not making decisions about what to do — you’ve already made them. You just show up to the theme.

That pre-decided structure is what protects the attention currency. You’re not fighting yourself about what to work on. The day has a reason. And that reason is what makes progress visible.

Without that structure, every day becomes a negotiation. And negotiating with yourself burns attention before you even start.

The Compound Effect

Progress builds on itself.

A week of days where you moved the thing forward feels completely different from a week of full schedules and hollow evenings. The momentum is tangible. You can point at what grew.

That’s what makes progress the currency of fulfillment — it compounds. A good day leads to a better tomorrow, because you can see what you’re building. The work connects.

Busyness doesn’t compound. It just resets every morning.

Start simple. One question before you start each day. One thing you’re moving forward. One block of protected time.

The hollow feeling doesn’t have to be the default.

If you want a system for protecting deep work time and making sure every week has real progress in it, the weekly review process at Asian Efficiency is a good place to start. It takes about 20 minutes and changes how every week begins.

The answer wasn’t the model. The answer was the information.

Every morning Evan started fresh. New chat. Re-explained what Arena Hall does, who was involved in the project, and what the goals were. The AI would give a decent answer. He’d close the tab. Next morning, same thing.

It’s like hiring a really smart assistant who has amnesia every day. They can do good work. But they spend the first 20 minutes of every conversation just catching up to where you left off.

The Fix: One Shared Google Doc

The concept sounds simple because it is. You create one Google Doc. Call it your master context document. It becomes the central memory layer for all your AI work.

Mine has:

• Who I am and what I’m building (business overview, current offers)
• Active projects and what stage each one is at
• How I like to make decisions and work through problems
• Key relationships — who I’m working with and on what
• Current priorities for the quarter

That’s it. No complicated system. Just a doc.

Then every Lindy agent I build gets pointed at that document. When I open Claude or ChatGPT for a real task, I paste the doc in as context. Instantly the AI has everything it needs.

In AI terms, I call this Centralized Context — agents and tools perform better when they share a single durable memory layer instead of operating as isolated chats. The preferred setup is a readable document, not some opaque hidden state that lives inside a tool you can’t see or update.

The Part That Makes It Actually Update

Here’s the part most people miss. A static document goes stale fast.

The second ingredient is a Lindy agent that keeps the document current. After every significant meeting, I run a transcript through a simple Lindy workflow: read the transcript, identify anything worth adding to the master doc, and write those updates in.

So the document is always current. It reflects what I decided last Tuesday. What changed this morning. What project just moved to the next phase.

During the session with Evan, I described the flow: “I have a chat with a new transcript, decide what’s worth keeping, then send a memo to Lindy which writes the decision into the master document.” He got it immediately. That’s the whole system. Inputs flow in. The document stays alive.

When I started running this setup across multiple tools, something changed. My AI interactions went from feeling like briefing a new contractor on every job to working with someone who actually knows the business. The questions got sharper. The outputs got closer to what I actually needed.

This Is Context Engineering

There’s a lot of talk about prompt engineering. How to write better prompts. How to structure your requests. It’s worth learning.

But context engineering is where the bigger returns are. The idea is simple: the quality of what AI can do for you depends almost entirely on the quality of information you give it. A mediocre prompt with rich context often beats a perfect prompt with no context.

Context Files as AI Assets is a framework I teach in workshops. Context files are reusable text files that encode your identity, writing style, decision patterns, business context, and working style. You build them once, maintain them over time, and load them whenever you need them. The master context document is the cornerstone of that library.

The activation signal that tells you this is missing: when your AI consistently sounds generic, when you find yourself explaining the same background over and over, or when an answer could have been written by anyone in your industry.

A Simple Starting Point

You don’t need Lindy to start this. You don’t need any special software.

Open a Google Doc. Write three paragraphs:

1. Who you are and what you’re building
2. What you’re working on right now
3. How you like to work and make decisions

That’s your first context document. Load it into your next AI conversation. See what changes.

Most people notice the difference immediately. The AI stops asking clarifying questions you’ve answered a hundred times. The suggestions get more specific. The work feels less like a back-and-forth and more like collaboration.

From there, you can add more detail over time. Connect it to agents that keep it updated. Expand it into a full library of context files for different types of work.

But the starting point is one doc. Three paragraphs. Do it before your next AI session.

If you want to build this out properly, I walk through the full setup in my Two Hour Workday workshop. We cover context engineering, Lindy agent design, and the exact workflow I use to keep a master document current with zero manual effort.