This week: the double-booked Friday, and the machine that couldn't hear

The weekly edition works like this: what I'm doing, what I'm watching, what you should do about it, and one meme. Paid members get the playbook at the bottom. Let's work.

On the bench

Two stories from the same week, and they turned out to be the same story.

First: my field-services business started capturing customer phone calls through the new phone system this week. Real calls, real customers. My agent transcribed the recordings, matched each caller against existing leads, and pulled out the scope of work. Useful, but not the interesting part. The interesting part is what it did next: it noticed I had verbally promised two different customers a site visit on Friday, checked the schedule, and found a full-day job still sitting on that same Friday.

Here's the wart. I had already texted that customer and confirmed moving his job to Thursday. I just never updated the scheduler. In my head, Friday was clear. In the system of record, Friday was triple-booked. A verbal promise on a phone call is a commitment your calendar never heard about, and I make those promises standing in a pasture with a customer, not sitting at a desk. The machine's job was to make the calendar hear them. It did. I fixed the scheduler in about ninety seconds, and Friday went from a quiet disaster to a normal day.

Second story, same week, opposite direction. The follow-up email engine for past customers is built. Sends are templated, capped, approved by me one at a time. I wanted to flip it on. My agent talked me out of it, and its argument is the thesis of this issue: the system can send, but nothing is built to read the replies yet. Opt-outs would sit unprocessed. "Not interested" would sit unread while the system scheduled the next touch. And the best possible outcome, a customer replying "actually yes, can you come look?", would be buried in an inbox while the machine kept marketing to someone who already said yes.

So the switch stays off until the inbound loop exists. That stung for about a minute. Then I remembered the first story: the whole win there was a system that listened. An automation that can speak but can't hear isn't a colleague. It's a megaphone on a timer.

The gauges

Three things I watched this week, and what I actually think:

An operator published six months of running a one-person company on AI agents, including everywhere it broke. This landed in r/AI_Agents this morning: I have run a one-person company on AI agents for 6 months. Here is the 10-part framework that fell out of it (and everywhere it broke). Marketing, sales, CRM, outreach, all run by agents out of a single git repository. Should you pay attention? Yes, and specifically to two details. The operation lives in plain files the operator owns, which is exactly the portability posture I keep arguing for. And the honest half of the title is "everywhere it broke." His line "roughly the same number blew up in my face" is the most trustworthy sentence in the post. Anyone showing you agent operations without the blowup list is showing you a demo.

A guy who sold $350k of AI automation says selling it is an inbound game. From r/AiAutomations, with real discussion in the comments: Selling AI Automation is an Inbound Game. Should you pay attention? Yes, twice. Once as a buyer: when the people selling automation admit that cold outbound doesn't close, be skeptical of any pitch that leads with automated outreach volume. And once as an operator: your version of inbound is your reputation and your past customer list, which is why the reply a customer sends you is worth more than the ten messages you send them. The sellers figured out listening beats broadcasting. Same lesson, bigger invoice.

"Small businesses should be able to own their AI, not just rent it" is now a thread in small-business corners of the internet. The post is here: r/NateBuildsAI, arguing businesses should own AI the way they own their trucks and tools. Should you pay attention? Directionally, yes. I'd sharpen it though: the thing worth owning isn't the AI. Models get replaced every quarter. What's worth owning is the operational memory you feed it: your customer records, your pricing history, your decision log, in files and formats you control. Rent the brain, own the memory. When this vocabulary starts showing up in small-business forums, the market is about to get noisy with people selling you "ownership." Check what you'd actually hold if you left.

Your move

Ten minutes this week: list every channel your business sends on autopilot. Emails, texts, review requests, reminders, invoices. For each one, write down who or what reads the replies, and how fast.

Any channel where the answer is "nobody" or "me, eventually" is a channel where a customer can say STOP, or "wrong person," or "yes please come out" and your business keeps talking anyway. You don't have to build anything fancy this week. Even "replies forward to my phone and I check at lunch" is a listener. The unacceptable answer is a send channel with no ears, because that's the exact configuration where automation quietly turns a customer into a former customer.

The meme

Gru built the send path. Gru did not build the listen path. Don't be Gru.

The playbook: the send-readiness checklist

Operators: this is the exact checklist my agent and I now run before any outbound automation gets its switch flipped. It exists because we almost flipped one this week that would have passed every demo and still embarrassed us. Run it against anything that sends on your behalf: email sequences, review requests, SMS reminders, re-engagement campaigns, a VA with a template doc.

1. Is the kill switch per-channel or global? One master switch that arms email AND text at the same time means you can never launch the safe channel without arming the risky one. Demand separate switches per channel. If a vendor's platform only has one, that's a design smell: they built for demos, not operations.

2. Where is the cap enforced: when messages are written, or when they're sent? This one nearly got us. Our daily cap was enforced at drafting time, but sixteen already-approved messages were sitting in the queue. Flip the switch and all sixteen dispatch in the first pass, cap technically never violated. Ask the question exactly this way: "If the queue is full when I turn this on, what goes out in the first hour?" If nobody can answer, assume the answer is "everything."

3. Does the inbound loop exist yet? Three kinds of replies, in rising order of cost when missed:

• Opt-outs. "STOP" or "unsubscribe" must halt every channel for that contact, automatically and permanently. If opt-outs are processed by hand, the system will send touch two before a human catches the reply to touch one. That's not just rude; on text messaging it's a compliance problem.
• Negative replies. "Already had it done," "not interested," "wrong number." Each is a free data point that should end the sequence. Ignored, each becomes evidence to that customer that nobody's home.
• Re-engagement. "Actually yes, when can you come out?" This is the entire reason the automation exists, and it's the reply most systems handle worst: it lands in an inbox while the next automated touch stays scheduled. Selling to someone who already said yes is how you unsell them.

No inbound loop, no launch. A minimal one is fine: replies forwarding to a phone with a same-day check beats a dead inbox. But it must exist before the first send, not after the first complaint.

4. What happens on an ambiguous send? Sometimes the system genuinely can't tell whether a message went out: timeout, crash mid-send, provider hiccup. The correct behavior is quarantine: mark it for review, stop that contact's sequence, and keep the evidence. The wrong behavior is guessing. A system that assumes "probably sent" double-sends; one that assumes "probably failed" also double-sends. Ask your vendor, or your own code, what state a message lands in when the answer is unknown. If the answer is anything other than "a human looks at it," you'll eventually send the same message twice to the one customer who screenshots things.

5. Are there quiet hours and a daily ceiling? Boring, decisive, and the difference between "professional follow-up" and "9:40pm text from a land company." Hard quiet window, hard daily cap per contact and per day overall, templates only. Free-form generation writing directly to customers is a different risk class; don't mix it into your first launch.

6. Run the dead-listener drill before go-live. Send one message to yourself. Reply "STOP." Reply "yes, interested." Time how long each takes to change the system's behavior. Minutes: launch. "It doesn't yet": you just found the rest of the project. The send path is the easy 80%. The listen path is the 20% that decides whether the whole thing was worth building.

Steal this: before flipping on anything that sends automatically, write one sentence: "When a customer replies, ___ reads it within ___ and the sequence stops within ___." If you can't fill all three blanks, the switch stays off. That sentence is the whole checklist in miniature, and it's free.

Hit reply and tell me what's on your bench this week. I read every one. I'm the inbound loop.

— Justin