Rivett · Field Notes

What 30 Days Of Approval Logs Teach You About Your Business.

Fred Style — Sat, 30 May 2026 00:00:00 GMT

TL;DR: Your approval log is the most honest document in your company. It records what you said yes to, what you edited, what you rejected, and what you ignored. Read 30 days of it and three patterns surface every time: over-correction, drift, and capacity. Each one diagnoses a different part of the business. None of them are about the agent.

You set up an approval gate three weeks ago.

Every draft your agent writes lands in your inbox. You approve, edit, or reject. The agent learns. The drafts get better. The system feels like it is working.

Then you actually read 30 days of the log end to end. What you see is not a story about the agent. It is a story about you, your team, and the business.

What Is An Approval Log Actually Recording?

Three streams of information, all of them useful and only one of them obvious.

The obvious stream is the agent's output quality. Did the draft make sense. Was the recipient right. Was the tone close enough to ship. Most operators read the log looking only for this signal. That is the boring part.

The second stream is your judgment. Where you say yes fast, where you say no fast, where you spend two minutes editing, where you let drafts sit for a day. Your decision pattern is a fingerprint of what you actually care about, not what you say you care about.

The third stream is the gap between what the agent thinks the business is and what the business actually is. The agent's model of the world is encoded in its drafts. Your edits and rejections are the diff between that model and reality. Read 30 days of diffs and you have a portrait of where the agent is wrong, where you are wrong, and where the business itself is unclear.

This is the same diagnostic principle behind the executive assistant queue post. The queue is a decision surface. The log is what falls out the other side.

What Patterns Show Up In The First 30 Days?

Three patterns, every time, in roughly the same order.

Pattern one: over-correction. There is a category of decision where you reject or heavily edit the agent's output almost every time. The agent has tried 20 drafts. You have approved 1 cleanly. The remaining 19 are 60% rewrites. The agent is not getting smarter on this category, and you are not getting faster.

This is rarely a model problem. It is almost always a category where your judgment is the product and you do not trust delegation yet. A common example: pricing replies. The agent drafts a price. You always rewrite the price. That is not the agent failing. That is you correctly refusing to delegate the part of the business that is actually your job.

The diagnosis: pull this category out of the agent's scope. Stop drafting. Move it back to your own queue. Free up the agent for the categories where your edits are light.

Pattern two: drift. A category where the agent used to be approved cleanly is now getting edited more and more. Three weeks ago, the drafts were 90% ship-ready. This week, they are 60%. Something changed.

Drift is usually not the agent. It is the world. A pricing change, a new offer, a shifted ICP, a new tone the team adopted in person and forgot to write down. The agent is still drafting against the old model. The reality moved.

The diagnosis: update the memory file. Add the new pricing. Add the new tone. Add the new offer. This is exactly the layer we wrote about in your CRM looks full but feels empty. Memory is the document the next message gets written from. If memory is stale, drift is inevitable.

Pattern three: capacity. A category where drafts are landing in your inbox faster than you are reviewing them. The queue grows. Approvals slip. Drafts age. Some get sent late. Some never get sent at all. The agent is preparing more work than the human bottleneck can absorb.

The diagnosis: the agent is not the bottleneck. You are. The fix is either to delegate the approval to a second human, raise the agent's autonomy threshold on low-risk patterns, or reduce the volume of drafts the agent prepares. All three are valid moves. Doing nothing is not.

How Do You Read The Log Without Drowning In It?

Cap the review at 30 minutes a week.

Open the log. Sort by category. For each category, count four numbers:

Drafts prepared.
Approved without edit.
Approved with edit.
Rejected or skipped.

If "approved without edit" is over 70%, the agent is ready for more autonomy on that category. Raise the threshold.

If "approved with edit" is over 50%, the agent is doing useful drafting work but the memory file is probably stale. Update it.

If "rejected or skipped" is over 30%, this category is in over-correction territory. Pull it back from the agent's scope.

Three numbers, three decisions, every week. That is the discipline.

This is also what we mean by the kill switch post. The kill switch is not just a panic button. It is a category-by-category dial that you turn based on log evidence. The log is the input. The dial is the output.

What Does The Log Teach You About The Business Itself?

More than any quarterly review will.

A few things that tend to surface in the first 30 days, and rarely surface anywhere else:

The categories where your judgment is the product. These are the parts of the business you cannot delegate yet, and probably should not try to. They are not bottlenecks. They are the thing customers are paying for.
The categories where the team has a tone you never wrote down. The agent keeps writing in the wrong register. Your edits keep moving the register. Somewhere in the company there is a voice rule that nobody documented, and the log is now documenting it for you.
The categories where the business has changed and the marketing has not. The agent is still drafting around old positioning. Your edits are pulling toward new positioning. Read those edits in aggregate and you have a clear picture of what the next version of your messaging should be.
The categories where you are the only person who can say yes. If the log shows you as the sole approver on every draft, the business is more dependent on your inbox than you realized. That is a hiring or delegation issue, not an agent issue.

None of these are model problems. They are business problems the log has politely surfaced.

What Is The One Question An Operator Should Sit With?

If you handed your approval log to a stranger, what would they conclude about your business that you have not yet admitted out loud?

For most operators the honest answer is uncomfortable. The log shows what the deck does not. Where the pricing wobbles. Where the team has stopped caring. Where the founder is the bottleneck. Where the agent is the only thing keeping a category alive.

This is what Rivett looks for when we read a business. Not the dashboards. Not the slides. The places where the work actually flows through human approval, and the places where it stalls. Every revenue leak we have ever found is visible in one of those two places.

If you have an approval log and you have not read 30 days of it, that is your next 30 minutes. It will tell you more than the last three meetings did.

FAQ

What if my agent does not have an approval log? Add one. The simplest version is a shared sheet where every draft lands with timestamp, category, the agent's output, and the human action taken. This is the same shape as the seven-day follow-up queue. The log is the audit trail. Without it, you are running the agent blind.

Should I share the approval log with my team? Yes, in summarized form. Weekly snapshots by category, with the three numbers. The log itself often contains sensitive customer or pricing detail and should stay restricted. The lessons should not.

How long until the patterns are clear? Usually 14-21 days. Before that, the sample is too small. After 30 days the patterns are stable enough to act on. Beyond 90 days the log gets long enough that you should be summarizing rather than re-reading.

What if the log shows the agent is wrong almost everywhere? Then the scope was too wide. Cut the agent's permissions to the two or three categories where it is closest to ship-ready, and rebuild trust from there. Trying to fix five categories at once is how phase three kills a deployment. We wrote about this in the boring middle of AI.

Does this only apply to AI agents, or to human assistants too? It applies to any role with an approval boundary. A new chief of staff. A new EA. A new SDR. A new contractor. The log shape changes but the diagnostic is the same: over-correction, drift, capacity. Three patterns, three fixes, one discipline.

The Boring Middle Of AI Is Where The Money Is.

Fred Style — Fri, 29 May 2026 00:00:00 GMT

TL;DR: Every AI deployment goes through four phases: the demo, the first production, the trust erosion, and either quiet success or quiet death. Most projects die in phase three because nobody owns the boring middle. Gartner now expects 40% of agentic AI projects to be canceled before 2027. The teams that win are the ones who plan for the middle, not the demo.

The demo always works.

Someone shows the AI doing the thing. The room nods. A decision gets made. A budget gets approved. A vendor gets selected. Eight weeks later the system is running in production and nobody is happy.

The model did not get worse. The work between phases did not get done.

What Are The Four Phases Of An AI Deployment?

Every deployment, in every category, goes through the same arc.

Phase one: the demo. The model performs above expectations. Edge cases are conveniently absent. The audience leaves convinced. This is where the budget gets signed.

Phase two: first production. The system goes live. The first week is genuinely magical. People share screenshots. Adoption is high. KPIs move. Champagne.

Phase three: trust erosion. Around week three or four, something goes wrong. The model writes an embarrassing email. It updates the wrong record. It misses an obvious follow-up. Suddenly every user is double-checking the output. Time saved evaporates. Half the team quietly stops using the tool.

Phase four: quiet success or quiet death. The project either gets rebuilt around the lessons from phase three, or it gets quietly defunded. Most projects die in phase four because the lessons from phase three never get owned by anyone.

This is the curve Gartner is describing when it forecasts that 40% of agentic AI projects will be canceled before the end of 2027. It is not a model quality problem. It is a phase three ownership problem.

Why Does Phase Three Kill So Many Projects?

Because phase three is boring, unglamorous, and politically uncomfortable.

The first failure in production exposes a gap nobody wanted to talk about. Maybe the model needs better context. Maybe approvals were too loose. Maybe the team never agreed on what success looked like. Maybe the data the agent reads from is dirtier than the demo data was.

Whatever the cause, the fix is small, tedious, and not exciting. There is no demo for "we tightened approvals on three actions." There is no announcement for "we fixed the memory file." There is no LinkedIn post about "we read 30 days of approval logs and adjusted the prompt." These are the upgrades that save the project, and they do not generate applause.

Most operators have nobody whose job is to do that work. The vendor moves on to the next demo. The internal champion moves on to the next initiative. The system runs without an owner, slowly losing trust, until it gets quietly turned off.

What Does Owning The Boring Middle Look Like?

It looks like one person whose job is to read the system every week.

Not the model. The system around the model. The approval logs. The drift between drafted and sent. The actions that get repeatedly skipped. The threads that decay because the queue did not catch them. The patterns the operator can see but the agent cannot.

This is the same instinct behind the kill switch post. The agent is not the unit of accountability. The control plane is. And the control plane needs a human owner, not a vendor relationship.

The shape of the owner's week:

Read the approval log on Monday. Count what was approved, edited, rejected, and skipped.
Pick one pattern to fix. Either tighten an approval, loosen a permission, or update the memory file.
Note one thing the agent missed that a human caught. Add it to next week's calibration.
Talk to the two heaviest users. Ask what they are double-checking. That is the real trust problem.
Talk to the two lightest users. Ask what they stopped using and why. That is the silent kill.

Twenty minutes a week. The cheapest, highest-leverage role in the entire deployment.

Why Do Vendors Sell The Demo And Skip The Middle?

Because the demo closes deals and the middle does not.

The economics are honest: a vendor's marketing budget goes to the moment of decision. Demos, case studies, benchmarks, conferences. None of those reward "we have great phase three support." Phase three is hidden inside the customer's organization. It does not show up on a billboard.

This is also why the AI SDR category collapsed. As we wrote about in the AI SDR crash post, the vendors who sold the demo and skipped the middle lost. The vendors who sold the operating discipline survived.

A buyer who understands phase three asks different questions during the sale:

"Show me a customer who has been in production for a year. What did they change between week 4 and week 52?"
"What is your average customer's approval rate at month 3 versus month 12?"
"Who on your team owns the phase three calibration with each customer?"

Most vendors cannot answer those questions cleanly. The ones who can are the ones worth buying from.

What Do Quiet Successes Look Like?

Unremarkable from the outside. Decisive from the inside.

A quiet success is a system that runs every day, gets reviewed every week, and produces a small accumulating advantage that compounds over months. Nobody writes case studies about it because there is no breakthrough moment to capture. It just keeps working.

The teams running quiet successes look slow during the demo phase and look unstoppable two years later. They did not buy the most exciting tool. They bought the tool whose middle they could own.

This is also why the 90-day SDR agent results post was not about model capability. It was about what we changed in the middle. What we learned from approvals. What we tightened. What we let the agent do more of, and what we pulled back.

The boring middle is the only place a sustainable advantage was ever built. The demo is rented. The middle is owned.

What Is The One Question An Operator Should Sit With?

If you froze your AI vendor's roadmap today, would your deployment still be improving in six months?

If the answer is no, you are paying a vendor to do work that should be living inside your business. Vendor roadmaps are a multiplier on top of your internal middle. They are not a substitute for it.

The teams that win the next 12 months will not be the ones with the best vendor. They will be the ones whose internal owner read their approval logs every week, kept their memory files current, and noticed the patterns before the trust eroded.

That work is boring. It is also where the money is.

FAQ

Should we even start an AI project if we cannot staff the middle? Probably not at full scale. Start small enough that the middle takes 20 minutes a week of operator attention. If the project survives 90 days at that scale, expand. If it does not, you saved a year of false confidence.

Who should own the boring middle? A senior operator with judgment. Not the most technical person, and not the most junior. Someone who can read patterns in approvals and translate them into prompt or workflow changes. This is often a Chief of Staff, a Head of Operations, or the founder during early deployments.

How do you tell the difference between phase three and an unfixable project? Look at the trend in approval rate over weeks. If the rate is improving, you are in phase three and the middle is working. If the rate is flat or declining for four straight weeks, the project may be fundamentally mismatched to the work, and the right move is to narrow the scope rather than to keep tuning.

Does this apply to off-the-shelf AI tools or only to custom builds? Both. Even a shrink-wrapped AI assistant has a phase three. The owner's job is the same: read the logs, talk to the heavy and light users, tighten approvals, update prompts. The tool changes. The discipline does not.

What if our vendor refuses to give us approval log access? That is a red flag. A vendor who will not give you access to your own approval data is selling you the demo and hoping you do not look. Either negotiate access into the contract or pick a vendor whose data model treats you as the operator, not the audience.

Your Email Signature Outperforms Your Homepage. Check Your Own Data.

Fred Style — Thu, 28 May 2026 00:00:00 GMT

TL;DR: I run an audit business. Pulled our numbers this morning and got annoyed at myself. 117 people came to the homepage in 30 days. 2 scrolled past the fold. 3 ran the audit form. Meanwhile the four lines of text I auto-stick at the bottom of every email I send was the only channel that drove a real diagnostic booking in the last 7 days. I've been sweating the wrong artifact.

I pulled our analytics this morning and got fucking annoyed at myself.

117 people came to the Rivett homepage in 30 days.

2 scrolled past the fold.

3 filled in the audit form.

That's the page I've been polishing for weeks. The page I redesigned twice. The page I argue about with my designer at midnight.

Meanwhile, the four lines of text I auto-stick at the bottom of every email I send, the ones I set up months ago and haven't opened since, did more work than that homepage. In the last 7 days my sig was the only channel that drove a real booking on our diagnostic page.

I've been sweating the wrong artifact for months. So have you.

What Does the Data Actually Say?

Numbers are mine. PostHog, last 30 days, no rounding.

117 unique visitors to rivett.tech. 2 of them scrolled past the fold. 7 triggered the audit memo event. Of those 7, 3 were real prospects. The rest were bots, my own QA hits, and one click from a mate who I'd sent the URL to.

It gets worse. The audit form on the homepage is technically broken for any prospect whose site sits behind Cloudflare. Headless browser times out at 12 seconds, throws a red error box, prospect leaves. So the page that's meant to be my front door is actively pissing off the highest-intent visitors I have.

Now the signature. Same 30 days. One single link, in plain text, at the bottom of every email I sent. That link was the only thing that drove a real /diagnostic page view that converted into a booking in the last 7 days. Not LinkedIn. Not the blog. Not paid. The sig.

One line, at the bottom of every send, outperformed the entire homepage I've been building.

I read it twice. Then I closed PostHog and rewrote my sig.

Why Does an Email Signature Beat a Homepage?

Because the audience is already paying attention.

Do the math on yourself. If you're a founder running outreach, replies, customer support, partnerships, and the occasional cold pitch, you're sending somewhere between 800 and 1,500 emails a month. Every single one of them lands in an inbox where the recipient already knows you exist. They wrote to you. You wrote to them. Someone CC'd them on you. The attention is already paid for.

Compare that to the homepage. Random traffic. Cold visitors. Most of them bounce in under 8 seconds because they don't know what you do and you have to earn the next click from a stranger.

The conversion math on cold traffic is brutal. You start from zero context.

The signature audience starts from full context. They know who you are. They opened the email because they cared about the thread. By the time their eye drops to the bottom of your message, you've already won the attention battle. The sig only has to hand them the next thing.

That's why the conversion rate is silly in your favour. You're shoving a CTA into a moment of attention you already earned. The homepage has to earn that same moment from scratch every single time, against a tab the visitor was already considering closing.

The math isn't close. It's a slaughter. And you've been ignoring it.

What Should a Signature Actually Do?

Most signatures answer "who I am."

Name. Title. Phone. Company logo. The LinkedIn URL nobody clicks. That's a business card from 2003. It works fine if your only goal is to remind someone of your job title. It does zero work for your pipeline.

A working signature answers a different question: what do I do that you might need right now.

Three lines that actually pull weight:

One credential line. Past-tense proof, not titles. "Previously: Growth at Somewhere (Nick Huber's company)" beats "Founder at Rivett" because one is a fact and the other is a label. Show me what you've done, not what you call yourself.
One CTA pointing at the strongest single thing you own. Not your homepage. Not your Calendly. The artifact that does the convincing for you when you're not in the room. For us it's a pre-baked audit memo. For you it's whatever your single best proof asset is: a case study, a teardown, a 90-second Loom, a one-pager.
One scarcity line, if it's real. "Taking 2 clients in June." If you're not actually capacity-constrained, skip it. Fake scarcity from a stranger reads exactly like fake scarcity from a stranger.

My old sig had "AI below the judgment layer" sitting in the middle of it. The kind of jargon you write when you're trying to sound smart to people who aren't your buyer. I killed it this morning while writing this post. The new version sends every reader straight to our strongest pre-baked audit, with a credential line above it and a scarcity line below.

Change took 6 minutes. It will outperform a homepage redesign that takes 6 weeks. That's not a guess. It's already happening. I just wasn't looking.

How Do You Test This in Your Own Business?

Open whatever analytics you use. Filter by utm_source=email_signature for the last 30 days.

If you're like most operators, you have zero events. Not because the sig isn't doing work, but because you never tagged the link. Your sig traffic is being eaten by $direct, which is the same bucket as people typing your URL, people coming from LinkedIn (which strips the referrer), and people clicking from Slack. You can't see the sig because it's wearing the same costume as everything else that converts.

Fix is one minute. Append ?utm_source=email_signature&utm_campaign=sig_v3 to the link in your sig tonight. Save. Send your next email.

Wait 30 days.

Then come back and compare that single tagged link to your other channels. Compare it to your last Google Ads spend. Compare it to the LinkedIn posts you've been agonising over. Compare it to the homepage you keep rebuilding.

We wrote about this attention gap before in the seven-day follow-up queue post. Most operators don't have a measurement problem, they have a tagging problem. The signal exists. You just never built the lens to see it. The sig is the worst version of this because it's been sitting under your nose for years and you've never once asked it for receipts.

Why Did You Miss This?

Because homepages look like work. Signatures look like nothing.

You see the homepage every time you open your laptop. You forward it to people. You argue with designers about the hero copy. It feels important because it has visual weight, a URL you can point at, and a deploy you can watch.

The sig is four lines of text at the bottom of an email client you barely look at. No Figma file. No agency pitches you on it. So it sits there for years, untouched, quietly doing more work than any of the things you obsess over.

This is the operator pathology in miniature. The visible artifact gets the attention. The compounding artifact gets ignored. Same reason you fuss over your office layout while your invoicing system silently misses payments. The thing in your face is not the thing doing the work.

Honest question, because this one wrecked me and I'd be a bad sport not to pass it on:

If you forwarded yourself every email you sent in the last week, and read only the bottom four lines of each, would you click anything?

If the answer is no, your sig is wallpaper. And your homepage is probably losing the silent race to your wallpaper.

That's the part that should annoy you.

FAQ

Doesn't a long signature make me look pushy? Yes, if it's long. 5 lines is the cap. Name, credential, CTA, scarcity if real, link. Anything past that is noise and people stop reading. The discipline is editorial, not visual. Cut hard.

What about plain-text rendering? Build the plain-text version first, then layer the formatted version on top. Most cold prospects open in dark mode on mobile in clients that strip images and break HTML tables. If your sig only works in pristine formatted email, your sig only works for the people who already know you. Which defeats the point of having one.

Should the CTA be a calendar link? No. Calendar links ask for a commitment from someone who hasn't been sold yet. The first click should be the artifact that does the persuading: a sample, a case study, a teardown, a proof. The meeting is the second click, after they're convinced. Sending strangers to your Calendly is asking them to marry someone they haven't dated.

What if I'm B2C? Math holds and probably gets stronger. Every customer service reply, every order confirmation, every onboarding email has a sig. B2C operators send more emails per customer than B2B operators, not fewer. Use the sig to sell the next product, the referral, the upgrade, the review request. You already wrote the message. Add the line.

How often should I update the signature? Every quarter, minimum. The CTA should reflect what your business actually wants more of right now. If the asset it points to is the same one you were promoting 6 months ago, your sig is a fossil and you're paying for it with every email you send.

Isn't this just A/B testing 101? A/B testing assumes you've tested something at least once. Most operators have never tested their sig. They wrote it in their second week of running the business, never measured it, and treated it as background noise for the next decade. Measurement comes before testing. Tag the link tonight. Look at the number in 30 days. That's the whole job.

Build A 7-Day Follow-Up Queue Without Touching Your CRM.

Fred Style — Thu, 28 May 2026 00:00:00 GMT

TL;DR: Most pipeline leaks are not lead quality problems. They are follow-up problems hiding behind a busy week. You do not need a CRM rebuild to fix this. You need seven days, one shared sheet, and a daily 12-minute review. By the end of the week, you will have caught revenue you would have missed and built a queue your team can run forever.

It is Monday morning.

You opened a tool last week to fix follow-up. It needed an integration. The integration needed a workflow. The workflow needed a meeting. The meeting got rescheduled. The week ended. Nothing got followed up on.

This is how most pipeline leaks survive. The fix is too big for the week available.

The version below is not a tool. It is a seven-day operator habit that catches what your current system is dropping. Do it once, keep the parts that worked, throw away the rest.

What Are You Actually Building This Week?

You are building a daily decision surface for follow-up.

Not a CRM module. Not a new tool. Not an automation. A single place that answers one question every morning: who is waiting on me, what are they waiting for, and what should happen next?

Three columns. One sheet. Twelve minutes a day. That is the whole product.

This is the same shape as the executive assistant queue post. The queue is not the assistant. The queue is the thing the assistant feeds, the operator reviews, and the day runs off.

Day 1 - Catch The Open Loops

Open your inbox, your text messages, and your calendar from the last 14 days.

Make a list of every thread where a real human is waiting on a reply from you. Not newsletters. Not vendor outreach. Real conversations with a specific person where the ball is in your court.

Write each one as a row. Name, source, last touch date, what they are waiting for, why it matters, suggested next action. Five columns. Plain text is fine. If you finish in 30 minutes you went too fast. If you finish in 3 hours you are also writing replies, which is the wrong job today.

Most operators find 20-40 open loops on day one. The number is uncomfortable. That is the point.

Day 2 - Rank By Decay, Not By Importance

Sort the list by how fast the opportunity is dying, not by how big it would be.

A small deal that decays in 24 hours outranks a big deal that decays in 30 days. Speed-to-reply beats size. This is the math behind why your leads are not cold, they are decaying. Demand has a half-life. Big deals do not exempt you from the clock.

For each row, mark a decay band:

Today - opportunity dies if not touched today.
This week - opportunity loses 50% of its value if not touched this week.
This month - opportunity is durable but waiting.
Park - opportunity is real but not active right now.

Sort the sheet by decay band. The top of the list is now your real day.

Day 3 - Add The Approval Lane

Add one new column to the sheet: "Draft ready."

For every row in the Today and This Week bands, draft the reply. Not a sketch. A real, sendable message. Paste it into the row. Mark it ready.

Do not send yet. Drafting is one job. Sending is a different job. Mixing them slows you down and makes the work feel heavier than it is.

Set aside 90 minutes for this. If the drafts are good enough that you can hit send tomorrow without rewriting, you did it right.

Day 4 - Send The Top Of The List

Open the sheet. Read each Today and This Week draft. Send the ones that are still right. Edit the ones that need a touch. Skip the ones that have already resolved.

Watch the clock. This should take 45 minutes. If it takes longer, your drafts were too rough.

Then update each row. Sent date. Status. New next-action date.

The sheet now has a heartbeat. It is no longer a list. It is a system.

Day 5 - Plug The Source

Look at where the original loops came from. Inbox. Texts. Slack. A form. A call.

For the sources that produced more than three open loops in week one, write down what would have caught them earlier. A daily inbox sweep. A Slack channel reaction. A weekly call-notes pass. A standing 15-minute "open promises" review on Friday.

Pick one. Add it to next week's calendar.

This is the part most operators skip. The queue catches the current backlog. The source plug stops the backlog from rebuilding. Without the source plug, you are running a one-time recovery, not a system.

Day 6 - Add Memory For The Top 10 Accounts

For the ten most important rows on your sheet, write a five-line memory note next to the row.

Last meaningful interaction. What they care about. What they hate. Live constraints. Voice rules.

This is the file the next message gets written from. Not a CRM field. A small block of context that makes the next reply feel like a continuation. If you read your CRM looks full but feels empty, this is the memory layer in its smallest possible form. Ten accounts, five lines each, fifty lines of text. That is the whole upgrade.

Day 7 - Read The Week And Decide What Stays

Sit with the sheet for 30 minutes.

Count the threads you would have lost without the queue. Count the meetings booked that came from it. Count the replies that landed. Count the drafts you killed because they were not worth sending.

Then answer three questions:

What part of this is worth keeping forever?
What part needs to live in a tool eventually, not a sheet?
What part should never have been on the sheet in the first place?

Most operators find the queue itself is the thing worth keeping. The drafts and the memory notes are upgrades. The sheet format is throwaway. The habit is the asset.

The question worth sitting with: if you ran this version every week for a year, with no new software at all, how much of the pipeline you currently chase with tools would just resolve on its own?

For most operators the honest answer is "most of it." That is the bet.

What Should You Not Do This Week?

A few traps worth naming.

Do not move your CRM data. The queue is a layer on top of the CRM, not a replacement for it. Migrating data is a different project. This week is about catching the open work.

Do not automate prematurely. Day 4 should be done by a human. Day 6 should be written by a human. The agent layer comes later, after you know which decisions are repeatable. This is also why you do not need more agents, you need a kill switch. Build the queue first. Automate only what proves itself boring.

Do not let the sheet become a CRM. It is meant to hold today's decisions, not the durable record of every relationship. When a row resolves, archive it. Do not let it grow forever.

What Does Week Two Look Like?

Shorter. The queue is now warm. Your day starts with the sheet. Each morning you spend ten minutes ranking, ten minutes drafting, ten minutes sending and updating. Half an hour. Same shape as week one, fraction of the time.

By week four, the source plugs from Day 5 are catching most new loops before they reach the queue. By week eight, you are deciding whether the next upgrade is a real tool, a hire, or a workflow change. By week twelve, the people on your team who used to drop balls are running their own version of the sheet.

You did not buy software. You built a habit. The habit is the system.

FAQ

Should the queue replace my CRM? No. The CRM holds records of truth: companies, deals, contracts, renewals. The queue holds today's decisions. They are different jobs. Keeping them separate is the upgrade. Collapsing them onto one surface is what made the CRM feel heavy in the first place.

Can my team share one sheet? Yes, if the team is small. Five operators or fewer can run a shared sheet effectively. Past that, every operator should have their own queue with a weekly roll-up review. The point of the queue is daily ownership, and daily ownership at scale needs individual surfaces.

What if I already use HubSpot or Salesforce? Build the queue as a single view inside that CRM. The view shows only "what needs a decision today." Hide the other 80 fields. The queue does not require a new tool. It requires a new view, plus the daily habit of reading it.

Should I use AI to draft replies in Day 3? You can, if the drafts are reviewed before they go out. The point of the human in Day 4 is approval, not typing. If an agent prepares better drafts than you would write cold, use it. If the drafts feel generic, write your own. Either way, nothing leaves without a human signing it.

How do I keep this from becoming admin work? Cap the daily review at 12 minutes. If it takes longer for more than two days in a row, the queue has too many rows or the drafts are too rough. Both fixes are workflow problems, not effort problems. The queue should make your day lighter, not heavier.

The Right Amount of Terrified

Fred Style — Thu, 28 May 2026 00:00:00 GMT

TL;DR: AI agents are a political spectrum now. Far right: OpenClaw, Hermes, 14 autonomous agents at 2am, trust the machine. Far left: "I will never let AI touch my customers, my CRM, my billing." Both confidently wrong in the way political extremes always are. The middle is the queue: agent prepares every action, human approves it. 80% of the productivity, 5% of the blast radius.

AI agents are a political spectrum now.

Far right: OpenClaw, Hermes, 14 unsupervised agents running at 2am, the founder's tab count as the only governance.

Far left: "I will never let an AI agent touch my customers, my CRM, my billing, or my reputation."

Both loud. Both confidently wrong in the way political extremes always are. The middle is the sane place. Live there.

What is the right wing actually saying?

That something has changed. They're correct about that.

A founder in 2026 who refuses to use AI is competing with one whose Claude is drafting the first version of every email, the first read on every ticket, the first audit on every prospect. The gap is real. It widens weekly.

The right wing has noticed. They are sometimes annoying about it. They are also, often, not running businesses with customers, payroll, or legal exposure. The blast radius of their best agent screwing up is their evening.

If you only listen to the right wing, you will eventually let an AI send the email that costs you a customer. The right wing considers this acceptable collateral. You probably don't.

What is the left wing actually saying?

That an unsupervised system inside a real business can do real damage. Also correct.

One wrong refund. One wrong customer email. One wrong CRM update. The cleanup takes a week and the founder is explaining to the team that yes, the AI did that, and yes, it was technically authorised because nobody specifically said it couldn't.

The left wing has watched what unsupervised humans do to systems and correctly extrapolated. Their mistake is conflating "unsupervised" with "AI at all." Plenty of AI usage is supervised, queued, approved, audited. They've thrown the whole category out because the loud version is reckless.

If you only listen to the left wing, you stand still while operators around you compound their AI advantage. The left wing thinks standing still is safe. It isn't.

The middle position

The agent should not be autonomous. It should prepare every action.

That is the whole centrist platform.

The agent reads the inbound lead, classifies it, drafts the response, surfaces it. The human sends it.

The agent reads the support ticket, suggests the refund or workaround, drafts the message. The human approves it.

The agent watches the funnel, spots a drop-off, drafts a remediation, ranks the options. The human picks.

This is not "less agentic." It is more leveraged. You get 80% of the productivity at 5% of the blast radius. The agent does the work. The human keeps the judgment. The audit trail is clean because every action that left the building was approved by a named human.

We've written about the same pattern in you do not need more agents, you need a kill switch and the AI executive assistant is a queue, not a chatbot. Different angles, one idea: the queue is the product. The agent is incidental.

The right wing will say this isn't really autonomous. Correct. They've confused autonomy with value. The value is the work that got done, not the absence of a human in the loop.

The left wing will say they still don't want AI near their customers. They've missed the trick. In a queue, the agent never touches the customer. The human always does. The risk has been removed.

Why do most operators end up on the extremes?

Because the middle is boring to talk about.

"I let my agents run free" is a Twitter post. "I will never trust AI with my business" is a LinkedIn humblebrag. "I built a queue where the agent prepares actions and I approve them in batches" is operating work. It doesn't go viral. It doesn't draw an audience.

The extremes get the airtime. The middle gets the results.

This is true of most political positions, in fairness. Centrism is unfashionable for the same reason every time: it doesn't feel like a stance. It just feels like adults thinking carefully about a thing. Nobody throws a parade for that.

What does centrism actually require?

A small amount of effort up front. Most operators have never tried the middle path because nobody is yelling at them to.

The right wing wants you to install OpenClaw and turn it loose. The left wing wants you to ignore the whole thing. Neither asks you to do the slightly harder thing, which is: pick one workflow you currently do manually, have an AI tool draft the next action every morning, review the drafts before lunch, send only the ones that look right.

That's the entire centrist program. You can ship it this week. You don't need a runtime, a course, or a Twitter following.

What's your actual position?

If you're on the right, when did you last check what your agents did overnight? When did one of them last touch a customer or a system without you noticing? Is the comfort earned, or just lucky?

If you're on the left, when did you last let an AI prepare a single decision for you to approve? Not run autonomously. Just prepare. If the answer is never, you're not protecting your business. You're protecting your discomfort.

Most operators picked their camp tribally, before they thought about it carefully. The interesting move in 2026 is to defect to the middle.

It is, as ever, where normal people live.

FAQ

Isn't a queue just "human in the loop" with a fancier name? Yes. The fancier name matters because "human in the loop" got used to describe everything from "the human supervises an autonomous agent" to "the human approves a single sentence." Calling it a queue is more honest about the shape: a ranked list of prepared items waiting for human action, with context attached. It's the difference between a kitchen ticket and a vibe.

What if I trust my agent because it's been "tested"? Testing tells you the agent does the right thing in the cases you tested. It doesn't tell you what it does in the case you didn't think of. The queue model means you don't have to predict every edge case in advance. The human catches the case the test didn't.

Doesn't this slow everything down? Less than you think. Approving prepared work is roughly 5x faster than authoring it from scratch. If your agent prepared 50 things overnight, you can approve all 50 before lunch. The throughput goes up, not down.

Where do I actually start? Pick one workflow that currently lives in your head or a manager's. Write down the steps. Identify which one is "preparing the next action" - most of them are. Hand that prep to an AI tool you already have. Review the output every morning. That's tier 1. The fancy agent runtimes are tier 2 and can wait until tier 1 is a habit.

Isn't this just a CRM with extra steps? A CRM is a database. A queue is a daily list of prepared, ranked, context-attached actions waiting for approval. The CRM tells you "you have 47 leads." The queue tells you "here are the 6 worth opening today, here's what to send each, here's why now." Same information. Different verb. The verb is the value.

You Paid for Permission, Not Skill

Fred Style — Thu, 28 May 2026 00:00:00 GMT

TL;DR: You're not buying knowledge from the AI/marketing/startup gurus you follow. You're buying permission to start. Claude already has the knowledge, and it's free. The guru tax is paying $497 for the feeling that you're allowed to try. Two examples: Corey Haines and Greg Isenberg. Both real operators. Both have figured out that the durable product in 2026 isn't skill transfer. It's courage.

You bought the course in January.

You saved 47 threads from Greg Isenberg about startup ideas.

You opened the Corey Haines email about Coding For Marketers.

You don't remember any of them.

You remember feeling like you were doing something. Which, if we're being honest, was the actual product.

What Are You Actually Buying?

Not the information. The information is free. It's been free for a year.

Open Claude. Tell it what you want to build. Ask it for the next step. It will tell you with more specificity than any thread, more patience than any course, and more relevance to your exact situation than any cohort program. It costs $20/month and answers at 3am.

So if you keep buying the threads and the courses and the cohorts anyway, you're buying something else.

You're buying permission.

Permission to start. Permission to call yourself a builder. Permission to try the thing you've been circling for two years. Permission to skip the part where you sit alone with an idea and feel uncertain about whether you're allowed to do it.

That's a real product. It's worth real money. Some people genuinely need a $497 ticket to feel they have the standing to start.

But you should know what you're buying. Because if you think you bought "the skill to build a startup" or "the knowledge to code as a marketer" or "the playbook for AI businesses," you're going to wonder in six months why nothing changed.

Permission doesn't compound. Skill does. They feel identical in the moment of purchase.

Why Did This Become A Business?

Because AI killed information scarcity, and the guru economy adapted faster than operators noticed.

For thirty years, marketing courses were valuable because the knowledge wasn't on Google. You actually couldn't figure out how to run a webinar funnel without someone showing you. So the courses sold the information and people learned the skill and got better.

Now the information is in Claude. The funnel diagrams, the email sequence templates, the cold outreach scripts, the SaaS pricing frameworks, the YC essays distilled into bullet points, the entire library of Hormozi clips reorganised by topic. All of it. For $20 a month. Answered in real time, customised to your exact situation, in your tone of voice.

The gurus who survived didn't double down on information. They pivoted to feeling. The product became identity, accountability, courage, community, status, and the warm hand on the back that says "yes, you can do this, here's where to start."

Most of them don't say this out loud. They still sell the surface product as "the course" or "the system" or "the playbook." But the underlying transaction has shifted. You're paying for the feeling that comes with the receipt.

It's a fucking smart pivot. The product is more durable than information because it can't be commoditised by the next model release.

Why Do Corey and Greg Specifically Work?

Different gurus. Same trick.

Corey Haines runs Coding For Marketers. It's a course teaching marketers to use Cursor and Claude to build small tools. In 2024 that was a real skill gap. In 2026, it's a Tuesday afternoon with Claude open and the patience to type for an hour. The course did not become unnecessary because Corey got worse. It became unnecessary because the underlying tools got better. Most operators who buy it now are buying the courage to open the terminal, not the syntax.

Don't take my word. We ran his own marketing site through our audit this afternoon. Scored 37 out of 100. One page indexed by Google. DMARC missing. The marketing teacher's marketing site is technically broken in ways the course would catch. Not a gotcha. Just a data point: even the people teaching the skill aren't reliably applying it.

Greg Isenberg posts startup ideas on X to a half-million followers. The threads are "10 AI businesses to build this weekend" and "100 niches that will mint money in 2026." His public output is high-volume idea content packaged as guidance. His audience consumes the threads, saves them, never builds anything, and comes back next week for the next thread.

Greg has real operating chops. He founded and exited real companies. He runs Late Checkout, which is a real studio that has shipped real products. The critique isn't that he's a fraud. He's not.

The critique is that the thing his audience buys (free threads, the podcast, the saved bookmarks) is fundamentally a content habit, not an operating transformation. His followers feel adjacent to startup-building because they consume content about it daily. The ratio of "saved threads" to "businesses started" in his audience is not flattering to the audience.

Both Corey and Greg work because they're talented at the marketing layer. That's actually the most honest praise you can give a 2026 guru: they understood faster than their audiences did what product they were really selling.

What's The Honest Receipt?

Look at the last 90 days of content you've consumed from any of them.

How many saved threads? How many newsletter opens? How many course modules half-completed? How many podcast episodes finished while you did the washing-up?

Now: how many things did you actually start as a direct result?

If the second number is zero or one, you didn't buy skill. You bought a content habit dressed up as a skill investment. That's fine if you knew what you were buying. It's expensive if you didn't.

This is the same trap we wrote about in you do not need more agents, you need a kill switch. Operators love to add more inputs because adding inputs feels like progress. It isn't. The compounding behaviour is execution, not consumption.

The guru economy thrives on a specific class of operator: the one who has confused "knowing about a thing" with "doing the thing." Most of us are that operator some of the time. The gurus aren't doing anything sinister. They've just noticed that this confusion is durable and well-funded.

So What Should You Do?

Stop buying permission. Open Claude. Tell it what you actually want to build. Start.

When you hit a wall, ask Claude what to try next, not which course to buy. The course will not teach you anything Claude can't teach you in five minutes of patient conversation. The course will, however, make you feel like you tried. That feeling is the product you're being sold. Decide consciously whether it's worth $497 to you.

If after all that you still want to buy something from a guru, fine. Buy it knowing what it is. It's the courage product, not the knowledge product. Some people need the courage product more than they need another evening of Claude prompts. There's no shame in that.

But stop confusing the two. And stop letting the gurus confuse you about which one you're paying for.

The honest question to sit with:

Look at your saved bookmarks. Look at the courses you bought in 2024 and 2025. Look at the newsletters you open and the threads you screenshot.

If a single one of them had been replaced by a quiet hour with Claude and a real attempt at the thing, would you be further along right now than you actually are?

If yes, you bought permission. The next question is whether you keep buying it.

FAQ

Aren't all teachers technically selling permission? Some of it, yes. The good ones also sell a real skill transfer that compounds after you stop paying them. The 2026 guru shift is that the skill-transfer part has been outcompeted by free AI, so what's left is mostly the permission and the community. That's a smaller, more honest product than what's usually advertised on the sales page.

Is this just sour grapes from someone who doesn't have 500K followers? Could be. You don't have to take my word for it. The receipt is in your own bookmarks folder. Count the threads. Count the businesses you started because of them. The math doesn't care who's doing it.

Are courses ever worth buying then? Yes. Courses that teach a specific, scarce, hands-on skill from someone who's the actual operator are still worth buying. The test: would the seller's daily work fall apart if they had to stop teaching this and just do it for a living? If yes, the course is probably real. If they'd be fine because the teaching IS the business, you're buying permission.

What about communities and accountability groups? Communities can be excellent. They're explicitly selling community, not skill, so the product matches the price. The trap is paying course money expecting skill and getting community instead, then telling yourself it was always about community. If you want community, buy a community. If you want skill, build with Claude.

Why pick on Corey and Greg specifically? Convenience. They're the two who came up in the kitchen this week. The post would work with any number of swaps. Hormozi, Justin Welsh, Dan Koe, half the SaaS marketing Twitter list. They all run the same trick in slightly different costumes. Corey is the cleanest "AI-killed-my-niche" example. Greg is the cleanest "high-volume content as a substitute for operating" example. Together they cover the spectrum.

Are you not also selling something? Yes, but not this. We do audits. We find revenue leaks. We charge for finding and fixing the leak. We don't sell you a course on how to find your own leaks, because the audit is the work, not the doctrine. If we did sell a course, this post would be deeply hypocritical. Hold us to that.

Your CRM Looks Full. It Feels Empty.

Fred Style — Wed, 27 May 2026 00:00:00 GMT

TL;DR: A CRM that looks full of contacts but feels empty in pipeline is not a data problem. It is a category error. CRMs are records of truth. Operator queues hold today's decisions. Agent memory holds context for the next action. One tool cannot do all three. The fix is to stop pretending it can.

Open your CRM. Look at the contact count.

Now count the contacts you would bet real money are still real. The right title. The right company. The right inbox. The right reason they were ever in there.

The gap between the two numbers is your real pipeline. Most operators do not want to do that math.

Why Does A Full CRM Feel So Empty?

Because most CRMs are doing three different jobs badly at the same time.

There is the record-keeping job. Who is this person, what company, what role, what was the source of the contact. That data needs to be accurate, durable, and queryable. It changes slowly.

There is the queue job. Who needs a reply today. Who promised something on a call. Who is one nudge from a yes. That data needs to be live, ranked, and reviewed daily. It changes hourly.

There is the memory job. What did we last say to this person. What did they care about. What context will make the next message useful instead of generic. That data needs to be searchable by the agent or assistant about to draft an action.

A CRM was built for the first job. It is being asked to do all three. The contact count grows because nothing ever leaves, and the pipeline feels empty because the live decisions are buried under the records.

What Should Actually Live In The CRM?

The answer is records of truth. Nothing else.

A useful CRM holds the durable facts of the relationship. The right person. The current company. The deal value. The close date. The source. The contract terms. The renewal date. The owner.

If the field would still matter to the business in six months, it lives in the CRM. If the field is "what should we do about them this week," it does not.

This is the same instinct behind the executive assistant queue post. The CRM is the inbox. The queue is the decision surface. The mistake is letting the inbox become the decision surface, and then complaining that the inbox feels heavy.

What Should Live In The Operator Queue?

Whatever needs a decision today.

The queue has a different shape. It is short. It is ranked. It is reviewed every morning. It holds:

People waiting for a reply, with why they matter and the suggested next action.
Meetings that need prep, with the open loop and the likely ask.
Promises overdue, with what was promised and to whom.
Drafts ready to send, sitting in approval.
Threads about to decay, with a recommended save.

The queue does not need to be a tool. It can be a markdown file. It can be one Airtable view. It can be a spreadsheet with five columns. The format does not matter. The discipline does.

What matters is that the queue is the thing you look at in the morning, not the CRM. The CRM has 8,400 contacts. The queue has 18 decisions. One of those is where the day happens. The other one is where the records live.

What Should Live In Agent Memory?

Context for the next action. Not records. Not decisions. Context.

Memory is the file the agent reads before drafting. It holds:

The last three meaningful interactions with this person.
Open promises, in their own words.
What they care about, what they hate, what they have asked for.
Live constraints on the deal: budget, timing, internal politics.
The voice rules of how we write to this account.

Most teams do not have this layer at all. They have a CRM full of fields and a sales team full of stories. The stories live in the heads of two reps and disappear when the reps leave. The fields are technically searchable and practically useless for the next message.

A useful agent memory is not the CRM with more fields. It is a small, curated file per active account that gets updated after every meaningful touch. It is the document the next email is written from.

If you have read about the anatomy of an AI agent, this is what we mean by soul. Memory is the thing that makes the next action feel like a continuation of the last one, not a fresh stranger writing in.

How Do You Split These Without Building Three New Tools?

You do not build three new tools. You build a workflow.

The CRM keeps doing the record-keeping job it was built for. You do not migrate. You do not rebuild. You just stop expecting it to be a queue or a memory.

The queue is a single view that pulls from the CRM and adds the "what to do today" layer on top. Salesforce can do this. HubSpot can do this. Airtable can do this. A markdown file can do this. The point is that you have one place where today's decisions live, and it is updated by whoever (or whatever) prepared the work.

Memory is a per-account file. One small document per active account. Updated after every call, every reply, every meeting. Lives wherever your team already reads documents. Read by humans before they write, and by agents before they draft. This is also the layer that should hold the why your leads are not cold, they are decaying signal, because decay is a memory question, not a record question.

The mistake is trying to consolidate. Three jobs, three artifacts. Different shapes, different refresh cadences, different audiences. The CRM is for the company. The queue is for today. The memory is for the next action.

What Question Should An Operator Sit With?

If your CRM disappeared overnight, how much of your real revenue motion would actually stop?

For most operators the honest answer is: a few reports would break, the renewal calendar would go fuzzy, and most of the daily work would continue uninterrupted. Because the daily work was never living in the CRM. It was living in inboxes, heads, Slack threads, and post-it notes.

That answer is not a complaint about the CRM. It is a diagnosis. The CRM was always doing one of three jobs. The other two have been homeless. Until you give them their own home, the pipeline will keep feeling empty even when the database keeps growing.

FAQ

So is the CRM useless? No. The CRM is doing one job well: durable records of the relationship. Stop asking it to do queue work or memory work and it becomes useful again. The frustration most operators feel is not with the tool. It is with three jobs collapsed onto one surface.

Where should the queue actually live? Wherever the operator already looks every morning. Notion, Airtable, a spreadsheet, a markdown file, a single Salesforce view. The format is less important than the cadence. Reviewed daily, updated as decisions get made, archived weekly.

What goes into agent memory that does not go into the CRM? The unstructured stuff. The "she mentioned her board is pushing back on AI spend" kind of detail. The voice rules. The open promise made on a Friday call. The thing that will make the next email feel like a continuation, not a cold start.

Can one tool handle all three jobs eventually? Maybe. Some vendors are heading that way. The risk is the same one that produced the current mess: collapsing three jobs onto one surface saves money in licensing and loses money in clarity. Better to keep three artifacts and one workflow than one tool and three blurred jobs.

How do I get my team to actually maintain the queue and memory? Make the queue the thing they read first in the morning, not the CRM. Make the memory file the document they write the next email from. Habits follow the artifact that gets opened most. If the CRM is the only thing they open, the CRM will keep eating the work.

The AI SDR Crash Was Always Going To Happen.

Fred Style — Tue, 26 May 2026 00:00:00 GMT

TL;DR: The AI SDR market just hit its first reckoning. 50-70% of tools churn within a year. Reply rates collapsed even as send volume multiplied seven times. The story being told is "AI got worse." The truth is the product was never an SDR. It was a volume hack with a chatbot face, and the volume hack broke.

It is 6:11am and your inbox shows 47 unread.

Twelve of those came from AI SDRs pretending to be people. You can spot them now. The same opening line variant, the same false familiarity, the same broken context. You delete most without reading. You roll your eyes at one. You forward another to a friend who will also delete it.

The AI SDR was supposed to give you back your week. Instead it gave a thousand other people the same script to send you, and you developed an immune system.

What Just Broke?

The AI SDR economy hit its first proper reckoning, and the numbers are not subtle.

Industry analysts now report 50-70% annual churn on AI SDR tools, with only 2% of deployments lasting more than a year. 47% of programs hit a deliverability wall in the first 90 days because the playbook scaled sending past what inboxes will tolerate. Per-rep monthly outbound went from 1,150 emails to 7,400 with AI in the loop. Raw reply rates fell from 4.7% to 2.9% in the same period.

Gartner now forecasts that more than 40% of agentic AI projects will be canceled before the end of 2027, mostly because the business case never materialized.

These are not edge cases. This is the curve.

Why Did The Math Work In 2024 And Stop Working In 2026?

Because the AI SDR was never an SDR. It was a volume multiplier, and the multiplier hit its ceiling.

In 2024 a generative model wrote five emails that sounded better than your interns wrote. Reply rates lifted 2-3x. Vendors called it the future of sales. Operators believed them. Procurement spent $30k-$200k a year on tools that mostly added to a sequence.

What no one priced in: inboxes recognize patterns. Subject lines, openers, P.S. lines, broken-record formatting. By 2025 the recipient was already trained to spot the shape of an AI-written cold email. By 2026 the same shape was getting routed to the promotions tab, marked as bulk, or filtered at the domain level.

The vendors who survived stopped calling themselves SDR replacements. The ones who did not, churned.

What Is Actually Working Instead?

The hybrid pod is winning, and the margin is not close.

Recent benchmarks: pods with one human SDR per two AI seats book 1.9x more meetings per dollar than pure AI configurations, and 2.4x more than all-human teams. Cost per qualified opportunity fell from $487 in human-only pods to $224 in hybrid setups. The economics show up where you would expect them. The human owns judgment. The AI owns preparation. Nothing leaves the building without a human approving it.

This is the same pattern we wrote about in the kill switch post. The agent is not the unit. The control plane is. AI SDR vendors who built spray-and-pray tools lost. Vendors who built operator queues with approvals and memory survived.

It is also why our own 90-day SDR agent results showed up as more meetings booked per hour of operator attention, not more emails per day.

What Should Operators Actually Do This Quarter?

Tear out the auto-sender. Keep the agent. Move the work to a queue.

The shape of the change:

Audit current send volume. If your AI SDR sends more than 30 cold emails per business day per inbox, deliverability is already eroding even if it has not surfaced yet.
Cut the prospect list by 70%. A tighter ICP outperforms wider AI-personalized lists every time. The volume hack is no longer the unfair advantage.
Replace autonomous sending with assisted drafting. The agent prepares, ranks, and drafts. The human reviews and sends. This is not slower. It is the only thing that still works.
Add a heartbeat and an approval log. Every draft, every action, every skip should be logged so you can read patterns later.
Score by meetings booked per inbox, not opens. Opens are a vanity number when half of them are bots.

This is also why your leads are not cold, they are decaying. The bottleneck is not the volume of outreach. It is the gap between signal and approval.

Was This Predictable?

Yes. The shape of every volume hack is the same. A few players exploit a window of asymmetry, then the asymmetry closes.

Email blast was a thing once. Cold calling at scale was a thing once. LinkedIn automation was a thing once. Every one of them collapsed when the inbox learned. Every one of them was followed by a rebuild around fewer touches, better evidence, and a human in the room when the message went out.

The AI SDR is following exactly the same path. The next 12 months will be the rebuild.

The question worth sitting with: if your outbound was forced into 30 emails a week instead of 300, would your pipeline collapse, or would it look almost identical?

Most operators do not want to answer that question. The ones who do tend to find they are paying for tools that produce noise the market is now filtering.

How Does Rivett Think About This?

The same way we have thought about it from the start. The operator's job is judgment. The agent's job is to prepare decisions. The tool is the queue, not the broadcast.

Our own SDR work runs on a queue, an approval log, and a memory file. It is boring on the surface. It catches threads the inbox would have lost. It books meetings the noise version never would have.

If you are looking at your outbound this quarter and the math has stopped working, the answer is not a new vendor. It is a smaller queue with a human in it.

FAQ

Are all AI SDR tools dying? No. The ones repositioning as hybrid copilots with strong approval flows are still gaining ground. The ones still selling "AI replaces your SDR team" are the ones churning. The category is not over. The category is being rebuilt around human judgment instead of pure automation.

Should we keep our AI SDR tool? Run a 30-day test. Cut send volume by half, route every draft through human approval, and score by meetings booked per inbox. If those numbers hold or improve, keep the tool. If they fall, the tool was doing volume work, not selling work.

Does this mean we should hire more humans? Not necessarily. Hire fewer humans with better leverage. The hybrid pod data shows that one operator with two AI seats outperforms larger teams without the same control plane. The cost per opportunity drops because preparation gets free while judgment stays expensive.

Is this only true for cold email? No. The same dynamic is showing up in LinkedIn outreach, cold call dialing, and AI-personalized direct mail. Any channel that depends on the recipient not noticing the pattern is now in trouble.

How fast should we move? Quickly. Deliverability damage compounds, and recovering a domain takes months. If your current tool is sending more than 30 cold emails per inbox per day, slow it down this week, not next quarter.

Your AI Executive Assistant Should Be A Queue, Not A Chatbot.

Fred Style — Tue, 12 May 2026 00:00:00 GMT

TL;DR: The useful AI executive assistant is not a chat window with a better prompt. It is a small operating system: one inbox, one calendar, one task queue, one daily readout, and clear approvals. Build the queue before the personality. The founder does not need another assistant to manage. They need a system that prepares decisions.

It is 8:43am and your first call starts in 17 minutes.

There are 19 unread emails, 4 Slack threads, a missed voice note, 2 calendar invites with no context, and one prospect who replied late last night.

The wrong AI assistant says, "How can I help?"

The right one already has the queue open.

What Should The Assistant Actually Own?

It should own loose threads.

Not your whole life. Not every app. Not a fake person with a friendly name. The first useful AI executive assistant should own the work that falls between inbox, calendar, CRM, and memory.

Give it four jobs:

Daily brief: what matters today, who needs context, which meetings are underprepared.
Follow-up queue: who is waiting, what they are waiting for, what should happen next.
Meeting prep: the last conversation, open promises, useful context, and the likely ask.
Decision log: what you approved, declined, delayed, or asked to revisit.

That is enough.

A founder does not need a general helper on day one. A founder needs a system that catches the work humans forget when the day gets loud.

What Inputs Should You Give It?

Give it the smallest set of inputs that explains your day.

Start with calendar, email, task list, CRM or pipeline board, and one folder of company context. Add Slack or WhatsApp only when the first loop works. More inputs make the assistant look smarter in a demo and harder to trust in production.

The input map should be plain:

Calendar: read events, guests, notes, and links.
Email: read threads, draft replies, never send without approval.
CRM or Airtable: read records, suggest updates, never overwrite without approval.
Tasks: read open items, create draft tasks, never delete.
Company memory: offer, ICP, pricing, active clients, voice rules, current priorities.

Whether you build this in OpenClaw, Hermes, a hosted agent platform, or a custom MCP setup, the architecture is the same. Tool access is not the strategy. The strategy is deciding what the assistant can see, what it can prepare, and what it must ask before doing.

What Should The Daily Readout Look Like?

The readout should fit on one screen.

If it takes 12 minutes to read, you built a report. The executive assistant should create a decision surface.

Use this structure:

Today
- 3 meetings that need context
- 2 decisions waiting
- 1 person who needs a reply before noon

Follow-ups
- Name, why they matter, last touch, suggested next action

Meeting prep
- Meeting, objective, last interaction, open loop, suggested stance

Risks
- Promises overdue
- Calendar conflicts
- Replies that could decay

Approvals
- Drafts ready to send
- CRM updates ready to approve
- Tasks ready to create

This is the difference between an assistant and another inbox.

An inbox asks you to inspect everything. A queue asks you to decide.

Where Does Human Approval Belong?

Approval belongs at every point where the assistant can change the outside world.

It can read. It can summarize. It can rank. It can draft. It can prepare. It can recommend.

It should ask before it sends an email, books or moves a meeting, updates a CRM source of truth, creates a client-facing task, spends money, deletes anything, or marks a promise complete.

This is not fear. It is operating design.

The same logic sits behind the approval gate. The system does the hidden work. The founder keeps judgment. That is how you get speed without handing your reputation to a black box.

For the first 30 days, assume every external action needs approval. After that, look for actions with a 95% approval rate and low downside. Those are the first candidates for automation.

Not because the assistant became magic. Because the pattern became boring enough to trust.

How Do You Build Version One This Week?

Build the morning queue.

Do not start with the full EA. Start with the 8am readout.

Day 1: write the assistant brief. Name the job, inputs, outputs, approval rules, and shutdown step.

Day 2: connect read-only calendar and email. Ask for a daily brief with no actions.

Day 3: add a follow-up queue. Every item needs a person, source, last touch, why it matters, and suggested next action.

Day 4: add meeting prep. Every meeting gets objective, context, open loop, and suggested stance.

Day 5: add draft replies, but keep them in approval.

Day 6: add a memory file. Every approval, edit, rejection, and note becomes calibration for the next run.

Day 7: review what it caught that you would have missed.

That last question is the point. Not whether the prose sounded impressive. Whether the system found a loose thread before it became expensive.

If you want the deeper agent shape, pair this with the anatomy of an AI agent: skeleton, heartbeat, soul, and memory. The EA version uses the same four pieces, just aimed at founder attention instead of sales volume.

What Is The 7-Day Test?

The test is trust under a normal week.

Run the assistant for 7 days and score five things:

How many useful follow-ups did it catch?
How many meeting briefs saved you time?
How many drafts were usable with light edits?
How many recommendations were wrong or noisy?
Would you let it run while you were in back-to-back calls?

If the assistant saves 30 minutes a day but creates 45 minutes of cleanup, kill it or narrow the job.

If it saves 30 minutes a day and catches one real revenue thread a week, keep building.

The operator question is not "can AI act like an EA?"

It is: which part of your week is predictable enough that a system should prepare it before you arrive?

Answer that, and the tutorial becomes simple. Build the queue. Add the heartbeat. Keep approvals. Let trust accumulate where the work repeats.

FAQ

Is an AI executive assistant just a better prompt? No. A prompt can produce a useful answer when you ask. An assistant has a recurring job, defined inputs, a queue, approvals, memory, and a schedule. The schedule is what turns it from a chat into a system.

Should the assistant send emails automatically? Not at first. Let it draft replies and follow-ups, then hold them for approval. Automatic sending should only come after you see repeated low-risk patterns with a high approval rate.

What should founders automate first? Automate preparation before action. Daily brief, meeting prep, follow-up queue, and draft replies are safer first moves than calendar control or autonomous outbound.

Do I need OpenClaw, Hermes, or MCP to build this? You need a runtime that can read the right tools, run on a schedule, keep memory, and respect approvals. OpenClaw, Hermes, MCP-based builds, and hosted platforms can all fit if the workflow design is clear.

How do I stop this becoming another system to manage? Give it one daily output and one owner. If the assistant cannot make the morning easier in one screen, reduce its inputs, narrow its job, or remove it from the workflow.

You Do Not Need More Agents. You Need A Kill Switch.

Fred Style — Tue, 12 May 2026 00:00:00 GMT

TL;DR: The agent story changed last week. Serious vendors are no longer only selling smarter AI. They are selling control planes, telemetry, permissions, and shutdown paths. For operators, the lesson is blunt: the business does not need 10 more AI demos. It needs one agent you can trust enough to run.

On Tuesday, May 5, ServiceNow said the quiet part out loud.

If an agent goes off script or acts beyond its permissions, the system should be able to shut it down.

The useful question is simpler: if an agent touched your pipeline tomorrow, who could stop it?

What Changed In The News?

The news was not one launch. It was a pattern.

ServiceNow expanded AI Control Tower on May 5, with discovery, observability, governance, security, measurement, and a shutdown path for agents that break permission.

Collibra launched AI Command Center on May 6, framing the problem as agent sprawl outpacing oversight. It tracks ownership, behavior, decisions, and risk.

OpenAI published its Codex safety playbook on May 8, and the interesting part was the operating posture: sandboxing, approvals, managed network access, credential handling, rules, and agent-native logs.

Microsoft had already set the tone by making Agent 365 generally available on May 1, positioned as a control plane to observe, govern, manage, and secure agents.

The market is voting with product: control is what people buy after the first agent works.

Why Should A 40-Person Operator Care?

Because enterprise risk arrives the moment an agent can touch money, prospects, customers, credentials, or brand voice.

A 40-person company with an outbound agent can create the same class of problem as a 4,000-person company: wrong contact, wrong claim, wrong list, wrong permission, wrong spend, wrong follow-up.

One bad campaign can burn a niche market. One wrong CRM update can poison a pipeline review. One unlogged AI action can leave the team arguing about what happened instead of fixing it.

Control is not an enterprise concern. It is an operator concern.

What Is A Kill Switch In Plain English?

A kill switch answers 4 questions.

What is this agent allowed to touch?

What must it ask before doing?

Where is every action logged?

Who can stop it today?

That is it.

For a small business, version 1 can be a spreadsheet with 8 columns: agent name, owner, job, tools, allowed actions, approval triggers, log location, and shutdown step.

If you cannot fill that in, the agent is not ready for production.

This is the same argument behind the approval gate. Approval does not make the system weak. It makes the system usable. The agent does the work. The human keeps judgment and accountability.

The kill switch is the approval gate's harder sibling: stop now, before this becomes expensive.

Where Does This Hit Revenue First?

It hits anywhere AI moves from drafting to acting.

An AI assistant that rewrites a LinkedIn post is low risk. Annoying if wrong, but recoverable.

An agent that enriches prospects, scores leads, drafts outreach, updates CRM fields, creates tasks, or recommends budget changes is different.

That means the operator has to measure more than output volume. Fifty drafted emails mean nothing if nobody can answer why those 50 people were chosen. Ten campaign recommendations mean nothing if the source data is broken.

This is where most AI enthusiasm gets soft.

People want agents because they are tired of manual work. Fair.

But the first agent worth building is the one with the clearest boundary.

Give it one job, one owner, 3 tools, a log, an approval gate, and a shutdown path.

Then run it for 30 days and count what changed.

What Should You Build Before Another Agent?

Build the control layer first.

A small operating layer your team can use this week.

Start with 5 pieces:

Agent registry: A list of every agent or recurring AI workflow in the business.
Permission map: The tools, folders, accounts, and records each one can read or change.
Approval rules: The actions that require a human before they happen.
Action log: A place where prompts, decisions, outputs, and human approvals are captured.
Shutdown path: A named person and a specific step to pause, revoke, or disable the agent.

That is enough to separate operating infrastructure from AI theater.

The operator question is not "how many agents can we launch?"

It is: which workflow would we let run for 30 days if we could see every action, cap every permission, and stop it in 30 seconds?

Answer that, and the next agent becomes easier to trust. Avoid it, and every new agent adds speed without accountability.

Speed without accountability is not automation. It is risk with a better interface.

FAQ

Do small businesses really need AI governance? Yes, but not enterprise ceremony. If an agent can affect prospects, customers, spend, data, or brand, it needs ownership, permissions, approval rules, logs, and a way to stop.

What is the difference between an approval gate and a kill switch? An approval gate stops specific actions until a human says yes. A kill switch stops the agent or workflow itself. One prevents bad actions. The other contains a bad pattern.

What is the first revenue agent to build? Start with a workflow that produces a reviewable queue rather than an automatic external action. Lead research, inbound triage, campaign anomaly detection, or CRM cleanup are good first candidates.

How do I know if an agent is ready for production? Ask whether you can name its owner, inputs, allowed tools, approval triggers, action log, cost cap, and shutdown step. If any are missing, it is still a demo.

Your Leads Are Not Cold. They Are Decaying.

Fred Style — Tue, 12 May 2026 00:00:00 GMT

TL;DR: Most teams blame lead quality when pipeline goes quiet. The harder truth is that leads decay in the gap between signal and follow-up. The first agent worth building is not a salesperson. It is a queue that catches demand, adds context, and asks a human to act before the moment disappears.

Someone fills in the form.

Someone clicks the booking link and does not finish.

Someone reads three pages, checks pricing, disappears, then comes back two days later from LinkedIn.

Your system calls all of that traffic.

It is not traffic. It is demand with a timer on it.

Why Do Good Leads Go Cold?

Because the moment that made them act does not last forever.

A lead is not a static record in a CRM. It is a person inside a narrow window of intent. Something happened. A problem got painful. A budget opened. A competitor moved. A meeting exposed a gap. They looked for help because the problem was alive.

Then your process made them wait.

The form went to an inbox. The booking click sat in analytics. The pageview became a dashboard number. The sales note needed context. The founder was in meetings. The agency reported the conversion next Friday.

By then the lead did not become cold. It decayed.

That distinction matters because "cold" makes the lead sound like the problem. Decay makes the system the problem.

What Actually Decays?

Context decays first.

In the first 15 minutes, you can still know what happened. Which page they read. Which offer they clicked. Which company they came from. Which campaign or post moved them. Which problem they were probably trying to solve.

After 24 hours, the record still exists, but the story is weaker. Someone has to reconstruct intent from fragments.

After 7 days, it is just a name, an email, and a vague sense that "we should follow up."

The lead did not lose all value. But the easy part of the value disappeared. The moment became admin.

This is why lead quality arguments get so slippery. A slow system can make good demand look mediocre. A fast system can turn ordinary demand into a useful conversation because it arrives with timing, context, and a next step.

Why Does Your Team Miss The Window?

Because every handoff is manual until proven otherwise.

Marketing generates the signal. Sales owns the conversation. Ops owns the CRM. The founder owns the standard. The agency owns the report. Nobody owns the 30 minutes after intent appears.

That is the leak.

It is not that nobody cares. It is that the workflow depends on a human noticing, interpreting, prioritising, researching, writing, and remembering at the exact right time.

That is not a pipeline. That is a memory test.

We already wrote about this in You Delegated Everything. Except the Part That Actually Scales You.. Most operators have delegated people work. They have not delegated the moments where revenue needs a system to wake up.

What Should Happen Instead?

Every intent signal should land in a follow-up queue.

Not a spreadsheet. Not a Slack message. Not a weekly report. A queue.

The queue should answer five questions before a human opens it:

Who is this?
What did they do?
Why might it matter?
What is the next best action?
What needs approval before anything goes out?

That is the first agent most teams should build.

Not an autonomous salesperson. Not a black-box closer. A follow-up agent that watches for demand, enriches the record, writes the first useful summary, drafts the next step, and waits for a human to approve.

The human still decides. The system stops letting the moment rot.

If you want the deeper architecture, start with the anatomy of an AI agent: skeleton, heartbeat, soul, and memory. In this case, the heartbeat is simple. Wake up every few minutes, check for new intent, prepare the next action, and escalate anything worth human judgment.

Why Is This Better Than More Lead Gen?

Because more leads through a slow system create more waste.

Most teams respond to weak pipeline by buying more traffic, posting more content, hiring another agency, or asking sales to follow up harder. That can work if the machine underneath is sound.

But if the problem is decay, more volume makes the leak louder.

You do not need 100 more leads if the current 20 are not being handled while they are still warm. You need to know which 5 are alive right now and what action should happen before the window closes.

This is where the owner math changes.

A lead that gets same-day context, same-day routing, and same-day follow-up is not the same asset as a lead reviewed next week. Same person. Different value.

The source did not change. The system did.

What Is The Owner Question?

Ask one uncomfortable question:

If a qualified prospect showed intent at 9:17 this morning, what exactly would happen by 9:32?

Not eventually. Not when someone checks the CRM. Not in the Friday report.

By 9:32.

Who sees it? What context do they get? What does the system know? What does the human approve? What happens if nobody acts?

If you cannot answer that, your pipeline has a decay problem.

The fix is not always a bigger campaign. Sometimes the first fix is a queue that refuses to let demand become admin.

FAQ

Are slow follow-ups always the main problem? No. Some leads are bad, some campaigns are poorly targeted, and some offers are unclear. But if your system cannot explain what happens in the first 15 minutes after intent appears, you cannot fairly judge lead quality yet.

Does this mean every lead needs an instant sales call? No. Speed does not mean panic. It means the signal is captured, enriched, routed, and prepared while the context is still fresh. Some leads need a call, some need a useful email, and some should be ignored.

What is a follow-up queue? A follow-up queue is a live list of intent signals with context and recommended next actions. It should show what happened, why it matters, who should act, and what needs human approval before anything is sent.

Can an agent send follow-up automatically? It can, but that is not where most teams should start. Start with drafts and approvals. Let the agent prepare the decision, then let a human approve, edit, or reject it until the standards are clear.

How do you know whether lead decay is happening? Measure the time between intent and first meaningful action. Then compare conversion, reply rate, or booked-call rate by response window. If same-day signals outperform delayed signals, you are not looking at lead quality alone. You are looking at decay.

What Is DESIGN.md? The Brand Memory File AI Agents Needed.

Fred Style — Thu, 07 May 2026 00:00:00 GMT

TL;DR: DESIGN.md is a Markdown file that gives AI coding agents your visual rules before they generate UI. It combines exact tokens with written design intent. For operators, the lesson is bigger than design: AI work improves when taste, rules, and context live in memory instead of prompts.

You ask an AI agent to build a landing page.

The first screen looks surprisingly good.

Then you ask for pricing, a mobile view, a lead form, and a follow-up email. By the fourth output, the design has drifted. The colors are close but wrong. The spacing feels different. The buttons look like they came from another product.

That is the problem DESIGN.md is trying to solve.

What Is DESIGN.md?

DESIGN.md is a plain-text design system for AI agents.

Google describes DESIGN.md as a way for Stitch to export or import design rules from project to project, so the tool understands the reasoning behind a design system and can generate interfaces that match the brand. Google has also open-sourced the draft specification so it can work across tools and platforms, not just inside Stitch.

The Google Labs DESIGN.md repo defines it as a format for describing a visual identity to coding agents. The file has 2 layers:

YAML front matter with machine-readable tokens.
Markdown prose with human-readable design rationale.

The tokens give the agent exact values: colors, typography, spacing, corner radius, and component properties. The prose explains what those values mean and when to use them.

In plain English: it is a style guide an agent can actually use.

Why Does A Markdown File Matter?

Because agents already understand Markdown better than most design artifacts.

A Figma file is useful for designers. A PDF brand guide is useful for a workshop. A token file is useful for a build system. None of those, by themselves, tell an AI agent what the design is trying to do.

Markdown does.

It is readable, version-controlled, editable in a repo, and easy for an agent to load with the rest of the project context. That matters because AI design work fails less from missing pixels and more from missing intent.

The agent does not only need #8FBF3F. It needs to know whether that green is the primary action color, a highlight color, a success state, or a decorative accent that should be used once per screen.

That difference is taste. And taste has to be written down before an agent can respect it.

What Goes Inside DESIGN.md?

A useful DESIGN.md file should contain both values and rules.

The official spec points toward sections like overview, colors, typography, layout, elevation, shapes, components, and do's and don'ts. The exact structure will evolve because the format is still young, but the operating idea is stable.

Start with these 8 blocks:

Overview: What should the interface feel like? Who is it for?
Colors: Hex values, semantic roles, and usage limits.
Typography: Font families, sizes, weights, line heights, and where each level belongs.
Layout: Grid, max width, spacing scale, and mobile rules.
Depth: Borders, shadows, tonal layers, or the rule that you avoid them.
Shapes: Radius rules for buttons, cards, inputs, and panels.
Components: Button, card, input, nav, badge, and state rules.
Do's and don'ts: The hard guardrails that stop generic output.

The last block is more important than it looks. Agents need negative instructions. "Use the accent sparingly" is weaker than "Do not use the accent for backgrounds, gradients, or decorative blobs."

That is how a design system becomes operational.

How Is This Different From A Style Guide?

A style guide tells a human how to judge the work. DESIGN.md tells an agent how to produce closer work before the human reviews it.

That does not make designers less important. It makes their decisions portable.

Most small companies have design taste trapped in 3 places: the founder's head, a few good pages, and the one person who says "that does not feel like us." The agent cannot read any of that unless you turn it into memory.

We made the same argument about voice in Your Brand Voice Is Trapped in Your Head. Generic AI output is usually not a model problem. It is a missing-memory problem.

DESIGN.md is that argument applied to visual identity.

What Should Operators Do First?

Do not start by building the perfect design system.

Start by documenting the 20 decisions that would stop the next AI-generated page from looking wrong.

Pull up your best homepage, landing page, sales deck, and email template. Then write down:

The 5 colors that matter and what each one is allowed to do.
The 4 text styles that show up most often.
The spacing pattern that makes the work feel like your brand.
The button and card rules you never want broken.
The 10 things the agent should not do.

That first version might be 80 lines. Good. A short file that gets used beats a beautiful guide nobody reads.

Then test it. Ask the same agent to build the same page twice: once with the DESIGN.md file and once without it. Count how many corrections you make in each version.

The number of avoided corrections is the business case.

Where Does DESIGN.md Fit In An Agent System?

DESIGN.md is one layer of agent memory.

It should sit beside the other files that explain how your business works: audience, offer, proof, voice, objections, and approval rules. Together, those files become the operating context for AI work.

Without them, every prompt starts cold.

With them, the agent starts with your rules, not the internet's average.

This is the bigger shift. The best AI systems will not be the ones with the longest prompts. They will be the ones with the clearest memory, the sharpest constraints, and the cleanest approval loop.

DESIGN.md is useful because it teaches that pattern in one visible place.

FAQ

What is DESIGN.md in simple terms? DESIGN.md is a Markdown file that describes your design system for AI agents. It includes exact design tokens and plain-language rules so an agent knows what colors, typography, spacing, and components to use.

Is DESIGN.md only for designers? No. Designers should own the quality of the decisions, but operators benefit because the file reduces repeated correction. If AI is producing pages, decks, ads, and product surfaces, someone needs to give it reusable design memory.

Does DESIGN.md replace Figma? No. Figma is still the visual workspace. DESIGN.md is the translation layer that turns design decisions into text an agent can read, version, and apply during generation.

Can I use DESIGN.md with Codex or Claude Code? Yes, if the agent can read files in your project. Put the file somewhere obvious, reference it in your project instructions, and ask the agent to follow it before generating or editing UI.

How long should the first DESIGN.md be? Short enough to stay useful. For a small operator, 60-120 lines is a good first target. Capture the core colors, typography, layout rules, components, and forbidden moves before writing a long brand manual.

Your AI Cost Problem Is a Payroll Problem

Fred Style — Wed, 06 May 2026 00:00:00 GMT

TL;DR: Agent cost feels wrong because operators compare it to software subscriptions. A $150 run is not competing with a $20 seat fee. It is competing with senior hours, waiting time, and missed cycles. The right question is not what the tokens cost. It is what payroll they compressed.

You see the invoice before you see the avoided meeting.

One agent run cost $150. Your first instinct is to flinch.

That instinct comes from the wrong column in your P&L.

Why Does $150 Feel Expensive?

Because you are comparing it to software, not work.

The SaaS habit trained operators to anchor on seats. $20 per month feels normal. $80 per month feels premium. $150 for one run feels reckless, even when that run produced research, strategy, drafts, and a decision queue.

That is the wrong comparison.

In Greg Isenberg's April 2026 interview with Howie Liu, Liu described using an agent to help prepare a board memo. The work cost about $150 in model tokens and took roughly a tenth of the time. The useful question is not whether $150 is expensive. It is what the same memo would have cost in executive hours, research support, and delay.

If the answer is "half a day of senior attention," $150 is not expensive. It is cheap payroll.

Which Ledger Should Agent Spend Live In?

Agent spend belongs closer to labor cost than software cost.

That sounds obvious until the invoice arrives. Operators still treat AI bills like subscriptions because the vendor sits in the software stack. But the output is not access. The output is work.

A CRM seat gives a human somewhere to log activity. An agent run enriches leads, reviews accounts, drafts a campaign, summarizes calls, or prepares a board memo. Those are payroll-shaped tasks.

The accounting question should change:

How many human hours did this remove?
How much waiting time did this compress?
What quality bar did it meet?
Did the output create a reusable system, or only a one-off artifact?

That last question matters. A $150 one-off deck is only a cheaper deck. A $150 agent run that becomes a scheduled workflow is a new operating asset.

How Do You Price an Agent Run Against Payroll?

Start with the fully loaded cost of the person who would have done the work.

If a senior operator costs $150,000 per year fully loaded, one hour is roughly $75 before you include management drag, context switching, or the opportunity cost of waiting. If the agent saves 4 hours, the labor math is already favorable. If it saves 4 hours every week, the math stops being interesting and starts being obvious.

The sharper version is throughput math.

If an agent checks inbound leads every 15 minutes, that is 96 checks per day. You cannot hire a person to do that attentively. You can hire someone to review the agent's queue each morning.

That is the shift. Humans stop producing the first pass and start judging the output.

We already wrote about this in the numbers behind agentic marketing: the gains come from better signal, faster enrichment, tighter feedback loops, and less human time spent sorting. The bill is not the story. The work moved is the story.

Where Does This Change the Business Model?

It changes pricing, margins, and team shape.

If your service business bills by hours, agent spend feels like a margin tool. You keep the same retainer, spend less time producing, and pocket the gain. That works until clients notice the work is cheaper to produce and ask why they are still paying for a headcount model.

If your business prices on outcomes, agent spend becomes an advantage. You can produce more signal, more tests, more follow-up, and more reporting without adding the same human cost.

The operator question is simple: who captures the efficiency?

If AI cuts production time by 70%, either your margin expands, your price changes, your output improves, or your competitor uses the same math to undercut you. Pretending the cost structure stayed the same is the slowest option.

This is why agent cost is not a finance footnote. It is a business model question.

Which AI Costs Should Still Make You Nervous?

Any run with no defined output should make you nervous.

Tokens are cheap when they move a known job. They are expensive when they wander. A vague prompt that burns $40 and leaves you with "interesting ideas" is worse than a $150 run that produces a decision-ready customer list.

Three costs deserve scrutiny:

Repeated one-off runs that never become workflows.
Agent work with no approval gate or quality check.
Outputs that save time but do not affect revenue, margin, or delay.

The answer is not to spend less by default. The answer is to demand a clearer job.

Before you complain about the token bill, write down the payroll it replaced. If you cannot name it, the agent did not have a job. If you can, the bill probably belongs in a different column.

FAQ

Is $150 really a normal agent cost? Not for every task. Simple summaries, drafts, and lookups should cost far less. The point is that higher-cost runs can still be cheap when they replace senior research, strategy, analysis, or repeated multi-step work.

Should I cap AI spend tightly? Yes, but cap it by job, not by vibes. A lead enrichment agent should have a target cost per qualified lead. A reporting agent should have a target cost per report. Spend without a defined output is where bills get silly.

How do I know whether an agent run paid for itself? Compare it to the human path. Estimate the hours avoided, the delay removed, and the revenue or margin affected. If the agent saved 4 senior hours and produced usable work, the cost is probably justified.

What if the agent output is worse than a human's? Then the cost is not the main problem. Add an approval gate, tighten the prompt, narrow the task, or move the agent to a more measurable workflow. Cheap bad work is still bad work.

Where should an operator start? Start where the payroll comparison is easiest: lead research, reporting, inbox triage, customer follow-up, campaign monitoring. If you can name the person, frequency, and output, you can price the agent properly.

Enterprise AI Is Insurance. SMB AI Is Throughput.

Fred Style — Wed, 06 May 2026 00:00:00 GMT

TL;DR: Enterprise AI buying is partly defensive. Nobody wants to be the executive who did nothing. SMBs have a better path: put agents into lead routing, research, reporting, and follow-up this month, then measure the work moved. The prize is not an AI strategy. It is throughput before committee drag arrives.

The board asks the AI question before the sales team asks for better follow-up.

Someone wants an answer by Friday.

So the company buys a program.

Why Does Enterprise AI Look Like Insurance?

Because doing nothing now carries career risk.

That does not mean every enterprise AI program is fake. It means the buying motion is often defensive before it is operational. The CEO needs a board answer. The CIO needs governance. The transformation team needs a roadmap. The vendor sells certainty.

McKinsey's 2025 State of AI survey shows the split clearly: 88% of respondents say their organizations use AI in at least one business function, but nearly two-thirds have not started scaling AI across the enterprise. For agents specifically, 23% are scaling somewhere and another 39% are experimenting.

That is the enterprise picture: high activity, uneven deployment, lots of pressure to show movement.

Insurance is not a stupid purchase. It protects the buyer from being the person who ignored the shift. But insurance is not the same as throughput.

What Does SMB AI Look Like Instead?

It looks like one queue getting shorter this week.

The smaller company does not need a 40-slide AI transformation roadmap before anything changes. It needs the inbound lead enriched before Monday. It needs the client report drafted before the account manager opens Slack. It needs the competitor changes summarized before the sales call.

This is where SMBs have the unfair opening.

They can turn one repeated workflow into an agent and measure it immediately:

Did response time drop?
Did the team review more opportunities?
Did campaign checks happen more often?
Did fewer follow-ups slip?
Did the owner get 3 hours back?

That is not AI theater. That is work moved.

Why Do Smaller Teams Move Faster?

Because the approval path is shorter than the work itself.

In an enterprise, a lead-routing agent may touch security, legal, procurement, RevOps, data, CRM ownership, and brand risk. In a 25-person company, the same workflow may need the founder, the sales lead, and one person who knows the CRM.

That does not make the smaller company safer. It makes it faster.

The job is to use that speed responsibly. Start with work that has a clear input, output, frequency, and approval gate. Lead enrichment. Meeting prep. Daily performance checks. Quote follow-up. Lost-deal review.

The goal is not to replace the team. The goal is to stop wasting human attention on first passes. For the difference between a helpful AI tab and a real agent, see You're Not Running an Agent. You're a Fast Typist..

What Should You Build Before Buying a Strategy?

Build the thing your team already avoids.

Every operator has one of these. The work is not strategic enough to get protected time, but too important to ignore. Pipeline hygiene. Account research. Weekly reporting. CRM notes. Competitor monitoring. Customer follow-up.

That is the first agent.

Not the sexiest workflow. Not the one that makes the best demo. The one with a clear before and after.

Before:

Leads wait 18 hours.
Reports take Friday morning.
Account research happens only for big deals.
Follow-up depends on memory.

After:

Leads are enriched every hour.
Reports are drafted by 8am.
Every target account has a brief.
Follow-up lands in an approval queue.

That is a better AI strategy than a strategy document.

Where Does This Get Dangerous?

It gets dangerous when SMBs copy enterprise buying without enterprise resources.

A big company can survive a vague pilot. It can spend 6 months aligning stakeholders and still call that progress. A smaller company does not have that cushion.

The trap is buying the category instead of assigning the job.

Sequoia has framed the AI shift as service-as-a-software: companies selling work rather than seats, with services markets measured in trillions. That is the useful lens for an SMB. Do not ask which AI platform sounds most advanced. Ask which work should no longer require a human first pass.

If the answer is unclear, wait. If the answer is obvious, build.

Enterprise AI can afford to be insurance for a while. SMB AI has to pay rent.

FAQ

Does this mean enterprise AI is useless? No. Large companies have real governance, integration, and change-management problems. The point is that their buying motion often starts with risk. SMBs can start closer to the workflow.

What is the first agent an SMB should build? Pick a repeated workflow with clear inputs and outputs. Lead enrichment, reporting, meeting prep, inbox triage, and follow-up queues are good candidates because the work is frequent and easy to inspect.

How small is too small for agentic systems? If you have repeated knowledge work, you are not too small. A 5-person company can benefit from an agent that checks leads daily. The constraint is not company size. It is whether the workflow is clear enough to hand over.

Should SMBs buy a platform or build custom agents? Start with the fastest path to a working queue. A platform is fine if it gets you to a measurable workflow quickly. Custom work makes sense when the workflow touches proprietary data, specific systems, or a high-value revenue process.

What should the owner measure? Measure time-to-response, number of items reviewed, hours saved, error rate, and revenue movement where possible. If none of those move, you bought AI activity, not throughput.

Your AI Tool Stack Is Not a Marketing Operating System.

Fred Style — Tue, 05 May 2026 00:00:00 GMT

TL;DR: The interesting thing in the latest agent demos is not that AI can write code. It is that the interface is becoming a campaign workspace. Research, briefs, assets, QA, browser work, and scheduled follow-up are collapsing into one operating layer. If your marketing still depends on you connecting every tab, you do not have an AI system. You have faster errands.

You have one AI tool for research.

Another for copy. Another for images. Another for video. Another for dashboards. Another for project management.

You call that a stack. It is really a set of tabs waiting for you to become the operating system.

What Is Actually Changing?

The AI interface is moving from a prompt box to a workbench.

That is the part most marketers are missing. The model is not just answering. It can read files, open browsers, use plugins, generate assets, update project boards, test outputs, and come back with work that is closer to finished.

The creator demos from the last two weeks all point in the same direction. One agent researches. One builds. One produces the launch asset. One tests. One keeps notes for the next run.

That is not a better copywriter. That is a different operating model.

The marketer's job changes from writing every prompt to designing the workbench: what context exists, what tools are connected, what the agent is allowed to do, and where judgment enters the loop.

Why Is Your Current Stack Still Manual?

Because you are still the handoff layer.

Your AI researcher finds the competitor angle. You paste it into a doc. Your copy tool drafts the landing page. You paste it into Webflow. Your image tool makes the mockup. You send it to the designer. Your video tool makes the clip. You upload it somewhere else.

Every step got faster. The system did not.

The constraint moved from production speed to orchestration. You are no longer waiting for copy. You are waiting for someone to remember what the copy was for, where it goes, what brand rule applies, what campaign it belongs to, and what happens after it ships.

That person is you.

So here is the uncomfortable question: if you disappeared for 48 hours, which campaign jobs would keep moving?

What Does A Marketing Operating System Need?

It needs memory, tools, roles, approvals, and a heartbeat.

Memory means the system knows your market, offer, voice, objections, claims, examples, and past campaigns. Without memory, every asset starts cold.

Tools mean the agent can do more than write. It can inspect a page, generate a diagram, render a video, update a task, check a source, or prepare a launch package.

Roles mean the work is split cleanly. Researcher. Strategist. Copywriter. Designer. Video producer. QA. Operator. Not because you need seven agents on day one, but because each job has a different definition of done.

Approvals mean the human keeps judgment without doing the grunt work. This is the same architecture we use in our approval gate thinking: the system prepares the decision, the operator makes the call.

A heartbeat means the system wakes up without you. Every morning, every hour, every Monday. No heartbeat, no operation.

What Should You Build First?

Build the campaign brief machine.

Not the full autonomous marketing department. Not the agent that runs your whole business. One machine that turns raw inputs into a usable brief every week.

Inputs:

Customer calls
Competitor pages
Saved posts
Search terms
Sales objections
Product notes

Output:

One campaign thesis
Three angles
Five proof points
Landing page outline
Email sequence direction
Social hooks
Risks and approvals needed

That workflow touches enough of the operation to matter, but not enough to burn the building down. It forces you to build memory. It forces you to define voice. It forces you to connect research to production.

Once that works, the next machines become obvious.

Why Does This Matter For Small Teams?

Because small teams cannot win a headcount race.

The enterprise version of this will be expensive, governed, and slow to implement. The operator version should be narrower and meaner. One workflow. One folder. One approval queue. One weekly output that would have taken six hours and now takes twenty minutes to review.

That is the wedge.

The point is not to say "we use AI." Everyone says that now. The point is to point at a campaign that kept moving while you were in meetings.

If your AI stack cannot do that, it is not a system yet.

It is a collection of talented interns with no manager.

FAQ

Is this different from just using several AI tools? Yes. Several AI tools make isolated tasks faster. A marketing operating system connects context, tools, approval, and scheduled work so the campaign moves across steps without you manually carrying every handoff.

Do I need one app to do all of this? No. One app can help, but the operating system is the workflow. If your memory, files, tools, and approval gates are clear, the system can span multiple tools. If they are not clear, even the best super-app becomes another tab.

What is the first workflow to automate? Start with weekly campaign briefing. It has repeatable inputs, a clear output, and low downside if a human reviews before anything ships. It also exposes every missing piece in your current marketing process.

Where does human judgment belong? At the approval gate, not at every production step. The agent should gather, draft, compare, and prepare. The operator should decide what is true, what is risky, and what is worth shipping.

What if the output is generic? That is usually a memory problem, not a model problem. The system cannot sound like your business if your business only exists in your head, old Slack threads, and a few scattered docs.

Your Brand Voice Is Trapped in Your Head.

Fred Style — Tue, 05 May 2026 00:00:00 GMT

TL;DR: Your AI content sounds generic because your business context is not written down in a form an agent can use. The voice is in your head. The objections are in sales calls. The proof is buried in old work. Until you build brand memory, every model starts cold and every draft comes back looking like everyone else.

You open the model and ask for a landing page.

It gives you something clean, competent, and dead.

Then you blame the model. Wrong target.

Why Does AI Marketing Sound Generic?

Because the agent has no memory of what makes you specific.

It does not know the customer who bought after three months of silence. It does not know the objection your sales team hears every Thursday. It does not know the founder phrase you use because it came from a real deal, not a positioning workshop.

So it reaches for the average.

That is what generic output is. The average of everyone else's internet, lightly dressed in your prompt.

You cannot prompt your way out of missing memory. You can only document the business until the agent has something real to work with.

What Is Brand Memory?

Brand memory is the operating context your agent needs before it writes a word.

Not a brand book. Not a PDF with hex codes and a mission statement. Useful memory.

It should include:

The customers you want more of
The customers you do not want
The objections that kill deals
The proof that closes them
The phrases your audience actually uses
The claims you can defend
The claims you will not make
The posts, ads, emails, and pages that sounded right
The ones that sounded wrong and why

That last part matters. Taste is not a vibe. Taste is a set of decisions logged over time.

This is where most teams break. They have brand taste, but no brand memory. The founder knows when something sounds wrong. The agent does not, because nobody gave it the pattern.

Why Is This A Pipeline Problem?

Because bad memory creates slow approvals.

Every generic draft comes back to the founder, the head of growth, or the one person who "gets the voice." They rewrite it. The team learns nothing. The agent learns nothing. The next draft repeats the same mistake.

That is not content production. That is a human correction loop.

We wrote about this distinction in why co-work is not an agent. If the system only works while you are there correcting it, you have not built scale. You built a faster way to create review work.

The question is simple: how many pieces of marketing could your team ship this week if you were not allowed to rewrite the first draft?

For most operators, the answer is ugly.

What Should Go In The Vault First?

Start with the things you repeat most often.

Do not begin with a massive knowledge base. Begin with the 20 pieces of context that would stop the next draft from being embarrassing.

The first vault should have five files:

audience.md: who this is for, who it is not for, and what they already believe.
offer.md: what you sell, what it replaces, what it does not replace.
proof.md: numbers, examples, client stories, failures, before and afters.
voice.md: words you use, words you avoid, strong examples, weak examples.
objections.md: the reasons people hesitate and the answers that actually work.

That is enough to change the output.

Not because the model became smarter. Because it stopped guessing.

How Do Agents Use Memory Without Making A Mess?

They need layers.

Layer one is always-on memory: the few rules that should appear in every task. Voice, audience, claims, banned phrases, positioning.

Layer two is project memory: campaign goals, source material, current offer, target segment, launch date.

Layer three is retrieval memory: old posts, sales calls, transcripts, competitor research, customer language. The agent should pull this only when needed.

Layer four is decision memory: what got approved, what got rejected, and why.

That fourth layer is the one most teams skip. It is also the one that compounds. Every approval becomes training data for the next campaign. Every rejection becomes a rule. Every edit becomes a signal.

This is how an agent gets closer to your standard without pretending the model retrained itself overnight.

What Changes Once Memory Exists?

The first draft stops being blank-page theater.

The agent can produce a campaign brief with the right customer, the right objection, the right proof, and the right tone before you touch it. The editor is no longer rebuilding the context. They are judging the work.

That is the operational shift.

Without memory, AI creates more drafts. With memory, AI creates fewer bad drafts.

There is a difference.

FAQ

Is brand memory the same as a style guide? No. A style guide tells people how writing should look. Brand memory tells the agent what the business knows, what it believes, what proof exists, what customers say, and what claims are safe to make.

Where should brand memory live? Anywhere the agent can reliably read it. A repo folder, Notion, Obsidian, Google Drive, or a structured project folder can all work. The location matters less than consistency and access.

How much context is too much? If every task gets every document, it is too much. Keep the always-on layer small and let the agent retrieve deeper material when the job requires it. Memory should sharpen the work, not bury it.

Who should own brand memory? The operator who approves the work. If the founder is the final taste gate, the founder's decisions need to become memory. Otherwise the whole system keeps depending on their mood, calendar, and patience.

How often should you update it? Weekly at first. Add approved examples, rejected patterns, new objections, and new proof. Ten minutes a week is enough if the team treats it as operational infrastructure, not documentation theater.

90 Days Running My Own SDR Agent. The Real Numbers.

Fred Style — Fri, 01 May 2026 00:00:00 GMT

TL;DR: Before I offered Aragorn to any client, I ran it on my own pipeline for 90 days. I would not ask anyone to trust a system I had not trusted myself. Here are the numbers, the failure modes I caught, and the one thing I would change if I were starting again.

I built it. Then I used it. For 90 days, before I offered it to anyone.

That was not a soft launch or a beta. That was the only way to trust it enough to put my name on it.

Here is what I learned.

What ran through the system.

Aragorn ran against my own prospect list across multiple verticals. Construction, financial services, B2B SaaS, real estate, and professional services. All real prospects. All personalised to specific signals. All held in the approval queue before sending.

The pace out of the gate was 10 prospects processed per hour. Not contacts made. Prospects fully enriched, email drafted, and ready for approval in the queue. No manual research. No copy-paste. Just review and approve.

At full operation, the approval queue ran at roughly 80 decisions per day. Not 80 emails sent. 80 reviewed. Some approved, some declined, some edited before sending. The decline rate was highest in the first two weeks and fell steadily as the system learned the standard.

The failure modes.

The first version of the ICP filter was too tight. Zero qualified prospects out of the first fifteen. I caught that myself, rebuilt the filter, and relaunched. That failure cost about a week. If a client had experienced it, it would have cost the relationship.

That is the real reason you run it on your own pipeline first.

The second failure mode was tone. In the early weeks, some emails were technically accurate but read as too formal for the operator audience I was targeting. The signal was right. The register was wrong. I fixed it by adding more examples to the persona calibration and enforcing the review discipline on every email, not just the ones I was unsure about.

The third failure mode was volume creep. The system was finding more signals than I had bandwidth to review properly. I tightened the signal criteria rather than rushing the review. A queue you cannot keep up with is a queue you stop trusting.

What the approval rate said.

Approval rates are a quality signal more than a volume metric.

In week one, I approved about 60% of drafts and declined the rest. By week 12, the approval rate was above 85%. That improvement is not the system getting smarter in an abstract sense. It is the system learning my specific standard through the pattern of every decision I made.

The approval gate is a training mechanism as much as a quality filter. Every decline teaches the system what I will not send. Every edit shows it how I want the message adjusted. After 90 days of this, the calibration was close enough to trust.

What I changed before offering it to clients.

One thing. The approval interface.

When you are the person approving 80 decisions a day, you immediately know what information is missing and what is redundant in the review card. The first version showed too much context you did not need and not enough of what you actually wanted to see before making the call.

I rebuilt the interface based entirely on the experience of being the person who had to use it every day. No amount of user research replaces that.

The second thing I added was the decline-with-reason workflow. Being able to mark a decline with a category. Wrong tone, wrong signal, wrong timing. That gave me data on where the system was missing. That data drove the improvements that got the approval rate to 85%.

What I would change next time.

I would define the signal criteria before writing the first line of agent code.

I spent time adjusting the ICP filter mid-operation when I should have locked it down first. The signal definition is the foundation everything else runs on. Getting that right before you start running is the highest-leverage thing you can do.

Read about why I built Aragorn for myself before offering it to clients, and the specific failure mode that taught me most about agent design.

FAQ

How long before you trusted it enough to approve without reading every word? I never stopped reading every word. The approval gate is a deliberate design choice, not a temporary measure. As the system improved, reviewing got faster. Reading stopped getting skipped.

What was the response rate on approved outreach? Better than cold email benchmarks, lower than warm referrals. Which is exactly where good cold outreach should land. The specific numbers varied by vertical and signal type.

Did the system ever send something without approval? Never. The queue architecture makes this structurally impossible. Unapproved emails do not exist in the send path.

How much time did the approval queue take per day? At 80 decisions, approximately 20 to 30 minutes when operating at pace. Longer in the early weeks when the decline rate was higher and each decision required more thought.

What happened to the prospects you declined to contact? They stayed in the system. Some were requeued when a better signal appeared. Some were archived. Declining an email does not mean writing off a prospect. It means the timing or the message was not right yet.

Can I see the actual email templates you used? The emails are not templates. They are generated from signal data on each individual prospect. There is no template to share because the personalisation is structural, not cosmetic.

You Delegated Your Calendar. Why Is Your Pipeline Still Manual?

Fred Style — Tue, 28 Apr 2026 00:00:00 GMT

TL;DR: You already delegate your calendar, your accounting, your inbox triage. You made those decisions because you understood the math - your time is worth more than those tasks. Your pipeline is the same math. The reason you haven't delegated it yet is trust, not belief. Here is the specific design choice that solves the trust problem.

You have a VA who manages your calendar.

You use software for accounting.

You have someone handling your inbox triage, your travel booking, your admin stack.

You made all of those decisions because you understood something: your time has a rate, and anything someone else can do for less than that rate should be done by someone else. That is the delegation model. You know it. You have probably paid for a course that explained it.

So why is your pipeline still you, manually, at 11pm?

Why Do Operators Who Believe in Delegation Keep Running Pipelines Manually?

Not because they do not believe in delegation. They already delegate more than most people.

The reason is trust. Specifically: you do not trust a system to represent you in a first contact with a prospect. You have seen AI-generated emails. You know what they look like. You are not willing to have your name on one.

That is a reasonable position. It is also a solvable problem.

What Is the Design Choice That Makes This Trustworthy?

The approval gate.

Every email the system generates sits in a queue. Nothing sends until you read it and approve it. You are not trusting the system to represent you. You are trusting the system to do the research and the first draft, which you then review and approve.

That is exactly what you do with a good EA. They draft the email. You read it, sometimes edit it, and hit send. The work is delegated. The judgment is yours.

An SDR agent works the same way. Gollum finds the signal. Aragorn does the research and writes the email. You spend 2-3 minutes reviewing and approving. Nothing goes out without your eyes on it.

The trust problem is not solved by trusting the AI. It is solved by keeping the human in the decision seat.

What Does the Actual Workflow Look Like?

Signal detection runs continuously in the background. When a prospect triggers a signal - a hiring announcement, a funding round, a leadership change - the agent enriches their profile automatically and writes a personalised outreach email based on that specific signal.

That email appears in your approval queue. You read it. If it is good, you approve it and it sends. If it misses, you decline it with a reason. The system learns from every decision.

On a normal day, reviewing the queue takes about 20-30 minutes. Not because there are hundreds of emails. Because the agent is selective. Quality over volume is the design.

How Is This Different from What a Junior SDR Would Do?

A junior SDR works business hours, gets sick, goes on holiday, needs management time, and costs you $40-60k per year before benefits.

The agent runs continuously, never has an off day, requires no management overhead, and costs a fraction of a junior hire. The output is comparable in quality when the approval gate is functioning correctly, because quality control is built into the workflow rather than depending on an individual.

This is not a replacement for senior sales talent. It is a replacement for the repetitive prospecting and drafting work that junior talent does - and often does inconsistently.

What Should You Actually Do This Week?

If you believe in delegation and you have not yet applied it to your pipeline, the gap is the approval gate design, not AI capability.

Build a system where the agent does the research and the draft, and you make the call. You already do this for your calendar, your finances, and your operations. The pipeline is the same problem with the same solution.

Read about how we built the approval gate into Aragorn and why running it on our own pipeline first was the only way to trust it enough to offer it to anyone else.

FAQ

Does the agent decide who to contact or do I? Both. The agent detects signals and enriches prospects, but the ICP filter is set by you. The agent only works within the criteria you define. Approval of individual emails is also yours.

What if I want to edit an email before sending? Yes. Review, edit, approve. The queue is not binary. You can modify anything before it goes out.

How long does it take to get the system to a standard you trust? About 90 days of running the approval queue. You see the patterns, decline what misses, and the system calibrates to your standard. Most operators trust it within the first 30 days for straightforward outreach.

Is this appropriate for high-value or sensitive prospect relationships? The approval gate exists specifically for this concern. For your highest-value targets, you review more carefully. For volume prospecting, you move faster. The system adapts to how you use the queue.

What does this cost to run? Significantly less than a junior SDR headcount. The infrastructure cost is modest. The real investment is 20-30 minutes per day on approvals, which replaces the hours you were spending doing this manually.

Why Inbound Alone Is Leaving Money on the Table

Fred Style — Fri, 24 Apr 2026 00:00:00 GMT

TL;DR: Inbound marketing captures people already in buying mode who happen to be searching for you. That is maybe 3% of your total addressable market at any given time. Signal-based outbound reaches the other 97% - companies actively entering buying mode who do not know you exist yet. Both layers are necessary. Most operators only have one.

You have probably invested in inbound. SEO, content, paid ads, maybe a newsletter.

That investment is not wrong. Inbound works. It captures people who are already searching, already have a problem defined, already know enough to look for a solution.

But inbound has a structural ceiling you cannot market past.

What Is the Inbound Ceiling?

At any given moment, approximately 3% of your total addressable market is actively in buying mode. These are the people your inbound captures when it works well. They searched a term, found your content, converted.

The other 97% are not searching. Not because they do not have the problem, but because they have not yet entered the active buying phase. They are running their businesses, dealing with other priorities, and they will think about your problem later.

Inbound cannot reach the 97%. Inbound only works when they come to you.

What Does Signal-Based Outbound Actually Do?

It watches for the moment a company enters buying mode, then reaches them before they start searching.

Here is what buying mode looks like from the outside, if you know where to look. A company hires a VP of Sales - they are about to build a new pipeline. A company raises a Series A - they are about to scale their go-to-market. A company announces a new product - they need to create demand for it. A CEO posts about growth challenges - they are actively looking for help and not yet sure what kind.

These are signals. Each one is a company transitioning from the 97% to the 3%. The question is whether you reach them at the transition point, before they start evaluating options, or after they are already comparing your competitors.

Gollum, our signal detection agent, monitors these signals continuously. When a company in your ICP triggers one, the system builds a profile and queues an outreach email for human review. The email references the specific signal that triggered it. It arrives at the right moment because it was written for that moment.

Why Does Timing Matter More Than Most Operators Realize?

Because the first credible solution to arrive at the right moment has an enormous advantage over a better solution that arrives two weeks later.

Buyers do not evaluate options in a vacuum. They evaluate options against the context of when they recognised the problem. The company that catches them at the moment of recognition shapes the evaluation criteria. The company that arrives late is being compared against a benchmark they did not help set.

Inbound marketing is efficient at capturing late-stage demand. Signal-based outbound is efficient at capturing early-stage demand before it becomes competitive. These are different markets, and most operators are only competing in one of them.

Do You Need to Choose Between Inbound and Outbound?

No. They are different layers of the same pipeline, not alternatives.

Inbound builds the brand and authority that makes your outbound more effective. When an agent sends a personalised email and the prospect looks you up, your content is what they find. The inbound investment pays off in credibility for the outbound conversation.

Outbound creates conversations that inbound alone never would. Some of your best clients will come from companies that were not searching for you yet, reached at exactly the right moment by a signal you caught.

The operators running both layers have a structural advantage over the operators running only one. The operators running neither are leaving most of their market entirely unaddressed.

What Does It Take to Add the Outbound Layer?

The bottleneck is not technology. It is the signal definition and the approval process.

You need to define what signals indicate buying readiness for your specific ICP. That definition is your competitive advantage - nobody else knows your ideal customer as well as you do, and a signal that is noise for one business is a high-intent trigger for another.

Once the signals are defined, the agent runs them continuously. The approval gate keeps you in control of every message. The human judgment stays in the process. The repetitive research and drafting work moves to the system.

Read about how Gollum and Aragorn work together to understand what the full outbound layer looks like in practice.

FAQ

Does this replace SEO and paid advertising? No. Inbound and outbound address different segments of the market at different stages of buying readiness. The strongest pipeline operators use both. Replacing one with the other just changes which part of the market you are ignoring.

How do you define what signals to watch for? Start with the question: "What would a company in my ICP be doing publicly six weeks before they typically become a client?" The answer to that question is your signal definition. It is specific to your business and your buyer.

Is signal-based outreach considered spam? No. Spam is untargeted, irrelevant, and unsolicited. Signal-based outreach is targeted to companies actively experiencing a relevant trigger, written to that specific trigger, and sent after human review. The relevance is structural, not assumed.

What volume of outreach does this generate? Less than you might expect, because the signal filter is selective. The goal is precision, not volume. A smaller number of highly relevant outreach messages consistently outperforms a large volume of generic ones.

What if my prospects are not active on the channels you monitor? The signal sources are configurable. Job boards, news, LinkedIn, company announcements, and funding databases cover most B2B markets. If your buyers operate in a different context, the signal definition adapts.

Adobe Shipped a Marketing Agent Yesterday. You Still Ship Revisions.

Fred Style — Wed, 22 Apr 2026 00:00:00 GMT

TL;DR: Adobe demoed CX Enterprise Coworker at Summit on Tuesday, April 21, 2026. It generates, adapts, and versions on-brand assets without a human in the revision loop. 54% of enterprises already run agents in core operations. If your growth still moves at the speed of agency revisions, you are not competing with the agent economy. You are bidding against it.

You sent a brief to your agency Monday morning. Revisions came back Friday. You reviewed them over the weekend. Round two lands Thursday. That is your current production speed for one landing page variant.

Yesterday at its Summit keynote, Adobe demoed a marketing agent that generates, adapts, and versions on-brand assets without a human in the loop on each round. The customer in that demo is your next competitor, not your peer.

Here is the question worth sitting with: what do you call a business that takes eleven days to ship a landing page variant when the company across the street ships three a day?

What Did Adobe Actually Ship?

A CX Enterprise Coworker that orchestrates downstream customer experience workflows from personalization through activation, powered by NVIDIA's Agent Toolkit and demoed Tuesday, April 21, 2026.

That phrasing is Adobe corporate. Here is what it means operationally. One brief triggers an agent that drafts the first version, adapts it to each channel, checks it against brand rules, ships it into campaigns, and iterates based on performance data. No account manager in the loop. No Tuesday standup. No revision round.

This is not a feature launch. This is an operating model released as software. Every marketing leader at a Fortune 500 saw the same demo you did not.

Why Does This Matter More Than the Last Ten Agent Announcements?

Because the percentage flipped. As of mid-2026, 54% of enterprises have integrated AI agents into core operations. Not assistants. Not chatbots. Autonomous systems executing workflows end to end.

In January that number was under 20%. Last week Amazon added $5 billion to Anthropic with up to $20 billion more committed, securing 5 gigawatts of compute for Claude agent deployment. The agent market is no longer a conversation about what might happen. It is about who ships on this architecture and who still treats AI like a productivity feature.

Do the math on yourself. How many landing page variants did you test this quarter? If the answer is less than twelve, you are not running a marketing operation. You are running a wish list.

How Is This Different From What You Are Already Doing With Claude?

You are doing co-work. Adobe shipped actual agency.

When you open Claude in a tab and ask it to rewrite a headline, the model does not decide anything. It drafts. You review. You paste. You publish. The loop is closed by a human every single time. You are a very fast typist paying $200 a month for autocomplete.

Adobe's agent has authority within defined brand guardrails to produce, publish, measure, and iterate. The operator is no longer in the draft loop. The operator approves scope, defines rules, and reviews outcomes.

This is the same distinction we wrote about in our read on the MCP ecosystem. Co-work helps one operator move faster. Agency changes what one operator can run. If you closed your Claude tab for 48 hours, what would keep shipping? That is the test.

What Do You Do About It on Monday?

Three things, in order.

One. Stop measuring "AI usage" at your company. Measure ship velocity: how many marketing assets go live per week without a human touching them between brief and publish. That number is probably zero. Knowing it is the first honest metric you have.

Two. Pick one narrow workflow where the cost of a wrong decision is low and the frequency is high. Product description updates. Channel-level ad copy. Meta title tests. Build an agent for that workflow. Not a company-wide rollout. One workflow.

Three. Set a deadline. If you cannot point to one live agent by July, you are not behind the curve. You are off it. The 54% number gets to 70% by year end.

FAQ

Is Adobe's agent available to SMBs? Not yet. CX Enterprise Coworker sits behind Adobe Experience Cloud contracts. For companies under 150 employees the equivalent infrastructure exists through Claude Managed Agents (launched April 8, 2026), OpenClaw for self-hosted deployment, or custom builds on MCP. The gate is not technology. It is implementation capacity.

Is this the same thing as Claude Code or Cursor? No. Those are developer co-work tools. You type, the model assists, you review. An agent runs a workflow end to end with authority to act. Many operators already say "we have agents" when they mean "we have Claude subscriptions."

How much does an agent cost versus a marketing agency? A narrow-workflow agent runs $200 to $2,000 per month in tokens plus a one-time build. A mid-market marketing agency runs $8,000 to $30,000 per month. Agencies still exist for judgment, brand taste, and client relationships. Agents replace execution, not strategy.

If agents are this good, why is my competitor still running ads manually? Most companies have not built the infrastructure yet. The gap between "AI is everywhere" and "this workflow runs on an agent at our company" is a twelve-month operations project. Your competitor is two quarters into it and not posting about it on LinkedIn.

Do I need a technical team to ship an agent? For narrow, well-scoped workflows, no. For anything touching production revenue systems, yes. The minimum is one person who can read MCP specs, write clear agent instructions, and debug failed runs. Not an AI researcher. An operations engineer with an LLM habit.

Anthropic Hit 30% Enterprise Spend. Not Because Claude Is Smarter.

Fred Style — Wed, 22 Apr 2026 00:00:00 GMT

TL;DR: New Financial Times data shows Anthropic at 30% of US enterprise AI spend, OpenAI at 35%, "any AI" adoption past 50%. The companies writing those cheques did not pick their vendor by running benchmarks. They picked whichever model was already embedded in the tools their teams used daily. The model war ended. You just kept fighting it.

You had a browser tab open this morning comparing Claude Opus 4.7 and GPT-5.4 on SWE-bench. Maybe CursorBench.

Meanwhile, Financial Times data published this week says Anthropic has crossed 30% of US enterprise AI spend. The companies spending those billions did not pick their vendor by reading benchmark charts.

Here is the question worth sitting with: which AI model is already open on every laptop at your company this morning? That is the one winning at your company. The benchmark tab is a hobby, not a decision.

What Did the FT Data Actually Show?

"Any AI" adoption passed 50% in US businesses. OpenAI leads enterprise spend at ~35%. Anthropic is the fastest riser at ~30%. Google, xAI, and DeepSeek are still scrambling for paid penetration.

Translation: the question stopped being "are companies buying AI?" It is now "which AI got embedded in which workflow?" OpenAI owns chat (ChatGPT on every screen). Anthropic owns code (Claude Code in every terminal). Microsoft owns Office tasks via Copilot. Everyone else is fighting for distribution they do not have yet.

This is not a model war. It is a distribution war dressed up as a model war.

Why Did Anthropic Hit 30% So Fast?

Three mechanisms, in order of impact. None of them are about model capability.

One. Claude Code became the default coding tool for teams that churned off Copilot in 2024-2025. Once it was in the terminal, procurement added Claude Pro seats, then Claude API, then Claude Managed Agents. Expansion follows installation.

Two. Anthropic's enterprise safety positioning matched the compliance reviewer who actually signs the contract. "Refuses harder things" reads as "less risk in legal review." That is why big-bank procurement moved faster on Claude than on competitors with better raw benchmarks.

Three. MCP. Anthropic shipped the protocol in 2024, then let the ecosystem do the integration work. Every MCP-compatible tool is Claude-native distribution by default. Most buyers never made an explicit Claude decision. They bought a tool that shipped with Claude inside.

Microsoft used the same playbook to win with Office. Not best product. Best installed base.

Why Does Distribution Beat Capability in Enterprise?

Because capability differences are invisible at the workflow level. Most operators cannot tell the difference between Claude Opus, GPT-5.4, and Gemini 3.1 on their daily tasks. The benchmark gaps are real but only matter for roughly 5% of use cases. The other 95% come down to: which model is already open.

Microsoft won with Office because Excel was on the machine. Salesforce won with CRM because reps logged in daily. Slack won with comms because the channels were already there. AI works the same way. Whichever model is embedded in the tool your team uses most wins that seat. This is the same operator pattern we broke down in the five-variable framework we published this week. Distribution is not variable six. It is how variables one through three get decided in practice.

What Should You Optimize For Instead?

Ship velocity with the vendor your team already uses. Not the one that topped a benchmark last Tuesday.

If your engineers live in Claude Code, build agents on Claude. If your ops team runs ChatGPT Enterprise, build agents there. Switching vendors to chase a three-point benchmark gain is worth it at 10 million agent runs per month. It is waste at 10,000.

The FT data is telling you the market already decided this. You can spend Q2 comparing models or you can spend it shipping.

FAQ

Does this mean benchmarks do not matter? They matter, but not for the decision you are making. Benchmarks matter when you are building a product that relies on a specific capability (advanced reasoning, long-context retrieval, vision). They do not matter when you are picking which vendor to run marketing agents on. For 95% of operator use cases, the top-three models are interchangeable on output quality.

If OpenAI leads at 35%, should I default to ChatGPT? Probably yes, unless your team already runs Claude Code or another Anthropic-first tool. The correct default is "whichever vendor my team already opens daily." OpenAI has the lead because that answer is ChatGPT for more teams than any other answer. It is not because GPT is smarter.

How does this apply if my team uses both? Most teams do. Pick the vendor embedded in the workflow you are automating first. SDR team on HubSpot and ChatGPT? Build SDR agents on OpenAI. Engineers in Claude Code? Build developer agents on Claude. Mixed stacks are normal. Single-vendor purity is a consultant concern, not an operator one.

What about verticals where capability is life-or-death? Medicine, law, finance, defense, certain coding workloads. Here, capability gaps matter and benchmarks are relevant. But even in those verticals, the winning vendor is the one that got into the workflow first, not the one with the best paper. GPT-Rosalind is winning biotech not because of its BixBench score. Because Amgen, Moderna, and UCSF already integrated it.

Is this going to change in 12 months? The percentages will shift. The dynamic will not. Distribution-first wins in enterprise software have been stable since the 1990s. The AI vendor that wins 2027 will be the one embedded in the most workflows on January 1 of that year, not the one with the highest benchmark in December.

Claude or Open Source: The Five-Variable Framework

Fred Style — Wed, 22 Apr 2026 00:00:00 GMT

TL;DR: The AI agent stack is fragmented across Claude, OpenClaw, vendor-specific runtimes, and a dozen orchestration frameworks. The Claude-or-open-source choice looks ideological. It is not. The answer falls out of five variables: time to first ship, cost at volume, maintenance burden, data sovereignty, and portability. Most operators optimize for variable five and stall on variables one through three.

You sat in a meeting last month. Someone argued for Claude Managed Agents. Someone else argued for OpenClaw or a self-hosted setup. Both had bullet points. Neither had a decision. Six weeks later you still have not shipped an agent.

The fragmentation you are navigating is not in the AI ecosystem. It is in your decision framework.

Here is a different question to start with: which single variable would you be willing to sacrifice the other four for?

Why Is This Decision So Confusing?

Because the options are not comparable on one axis. Claude Managed Agents, OpenClaw, LangGraph, vendor-native runtimes, and custom builds on MCP all call themselves agent platforms. They solve different problems.

Claude is managed infrastructure plus model access. OpenClaw is a runtime you host yourself. LangGraph is an orchestration library. Vendor-native agents lock to one application's workflows. Calling all of these "the agent choice" is like asking whether you should use AWS or Python.

The fragmentation feels overwhelming because the question is under-defined. Sharpen the question and the options collapse.

What Are the Five Variables That Actually Matter?

Time to first ship. Cost at volume. Maintenance burden. Data sovereignty. Portability. Nothing else matters at the decision stage.

1. Time to first ship. Claude Managed Agents runs your first production agent in days. Self-hosted OpenClaw takes weeks to months depending on your team. If you have not shipped an agent before, you are buying velocity, not architecture.

2. Cost at volume. Under roughly 500,000 agent runs per month, Claude is cheaper when you price in engineering time. Past that threshold, self-hosted economics flip. Most SMBs are three zeros below that threshold.

3. Maintenance burden. Claude requires zero dedicated infrastructure engineers. OpenClaw or a custom build needs at least one. If you do not have that person, you will hire them or ship a broken agent.

4. Data sovereignty. Healthcare, finance, defense, and some EU-regulated verticals need self-hosted or private-cloud deployment. Everyone else is overthinking this. Anthropic's enterprise data terms are not weaker than your current CRM vendor's.

5. Portability. The variable most operators anchor to. MCP has largely solved agent-layer portability. Your prompts, tool definitions, and agent logic port between Claude, GPT, Gemini, and OpenClaw in days. Hosting ports in weeks. Vendor lock-in at the agent layer is not zero, but it is not what you think it is.

Which Variable Should You Optimize For?

The one that is actually blocking you. Not the one that sounds most strategic at the board meeting.

For the 10-150 employee range, variables one through three dominate. Time to first ship, cost at volume, and maintenance burden decide this for 90% of companies. You are not losing this decision on portability. You are losing it because nothing is live.

For larger companies with existing ML infrastructure teams, variables two, four, and five carry more weight. Vendor lock-in becomes a real line item at that scale and the engineering capacity exists to run self-hosted.

For regulated verticals, variable four vetoes everything. If patient data or customer financial records route through the agent, self-hosted or private-cloud is the only option and the other variables fall in line behind that constraint.

This is the same pattern we saw in what 97 million MCP installs actually mean. The architecture decision looks ideological. It is operational.

When Does the Answer Flip?

When your agent volume crosses the cost threshold, when you hire the infrastructure engineer, or when compliance constraints change. Not before.

A company shipping 50,000 agent runs today on Claude and targeting 5 million next year should architect portable. A company shipping zero runs and debating OpenClaw because "what if Anthropic raises prices" is architecture theater.

Pick the platform that optimizes the variable blocking you now. Revisit when a variable upstream changes.

FAQ

Is Claude actually open-source compatible? Partially. Claude models are proprietary, but agents built on Claude using MCP are mostly portable because MCP is an open standard. Prompts, tool definitions, and orchestration logic move between providers. The model provider swaps with some prompt tuning. The infrastructure contract is what ties you in, not the model.

What is OpenClaw and is it production-ready? OpenClaw is an open-source autonomous agent runtime originally built by Peter Steinberger, now stewarded by a non-profit after Steinberger joined OpenAI in February 2026. It is production-ready for teams with engineering capacity. It is not production-ready for companies that were about to ask this question.

Does MCP really solve portability? At the agent layer, largely yes. Your tool integrations, prompt logic, and orchestration port across any MCP-compatible runtime. Hosting, observability, and provider-specific optimizations do not. Assume one to four weeks to port a mid-complexity agent between providers.

How do I avoid picking the wrong platform? Do not pick a platform first. Pick one narrow workflow you want automated. Define success, scope, and guardrails. Then check which of the five variables dominates for that specific workflow. The platform falls out of the answer. If two platforms score similarly, pick the one your team can ship on this quarter.

What changes for companies in regulated verticals? Variable four (data sovereignty) becomes veto-level. Healthcare, finance, defense, and some EU-regulated businesses should default to self-hosted or private-cloud and treat other variables as secondary. Anthropic's enterprise tier and AWS Bedrock support some regulated workloads, but legal review is required before assuming coverage.

I Don't Care About AI. I Care About My Pipeline.

Fred Style — Tue, 21 Apr 2026 00:00:00 GMT

TL;DR: I spent 15 years building pipelines manually across 30 markets and $10M in ad spend. Then I ran the numbers on what manual prospecting actually costs per qualified conversation. The math forced my hand. This is not an AI story. It is a pipeline story - and the numbers are not close.

I am not an AI person.

I am a pipeline person. I have been for 15 years.

I ran growth at Somewhere. I managed $10M in ad spend across 30 markets. I know what a qualified conversation is worth and what it costs to generate one.

So when people started talking about AI, I tuned it out. Not because I was being stubborn. Because I had seen too many tools promise scale and deliver noise. And I was busy enough doing the real work.

Then I ran the numbers on the real work.

What Does Manual Prospecting Actually Cost?

Not in dollars. In hours.

To find a prospect, research them properly, write a personalised email, and follow up takes between 40 and 60 minutes per person when you do it right. Not when you dash off a generic message. When you actually read their LinkedIn, find the signal, and write something they will want to reply to.

If you want 100 real conversations a year, that is 70 to 100 hours of your time. At founder or senior operator rates, that is probably your most expensive cost of sale. More expensive than ads. More expensive than a junior hire.

Most people do not run this number. They just feel busy.

I ran the number. Then I built something to fix it.

What Did Building an SDR Agent Actually Look Like?

I built Aragorn. An agent that monitors signals across job boards, news, and LinkedIn, enriches each prospect automatically, writes a personalised outreach email from the actual signal data, and holds everything in an approval queue.

Nothing sends without a human reviewing it. That is not a safety feature. It is the design.

On day one I ran 10 prospects through it in under an hour. No manual research. No copy-paste. Just review and approve.

The emails were better than what I was writing manually at 11pm when I was tired. Because the agent is never tired and it does not skip the research when it is pressed for time.

Is the Output Actually Good Enough to Send?

This is the right question and the honest answer is: yes, with the approval gate in place.

The agent pulls real signals. If a prospect just hired a VP of Sales, it writes to that signal specifically. If they just raised funding, it writes to the expansion moment. The emails are not templates because the research is not templated. Each one is built from actual data on that specific person and company.

The approval gate is where quality lives. You read every email before it sends. You decline the ones that miss. The system learns what missing looks like. After 90 days of approvals you have a system that understands your standards because you enforced them.

Does This Replace a Sales Team?

No. It replaces the prospecting and drafting work that happens before a sales conversation adds any value.

The agent does the work nobody should be doing at founder rates. The human does the work that requires judgment - deciding who to contact, approving the message, running the conversation once there is one.

If you have spent any time in Nick Huber's world thinking about delegation, you already know this framework. You hire out the work a $15-an-hour person could do. An agent does that work for less than a $15-an-hour person and it runs 24 hours a day.

You just have not applied the delegation model to your pipeline yet.

What Actually Changed After Running This?

I had pipeline running while I was building product. While I was in other meetings. While I was asleep.

The pipeline did not stop because I stopped. That is the shift that is hard to explain until you have experienced it. Not a dashboard improvement. Not a percentage gain. A pipeline that does not depend on your availability to function.

That is not an AI outcome. That is a business outcome.

Read about how we built Aragorn and the rest of the system if you want to understand what is actually under the hood.

FAQ

Is AI outreach obvious to the recipient? Only if the email is generic. Aragorn writes to specific signals from each prospect's actual recent activity. The email is personalised because the research is real, not because a template has their first name in it. And a human reviews it before it sends.

Doesn't this feel impersonal? Less impersonal than a form letter. More impersonal than a handwritten note. About as personal as a well-researched cold email from a thoughtful person - which is exactly what it is.

What if the agent makes a mistake? Nothing sends without approval. There is no scenario where a bad email goes out without a human reading it first. That is why the gate exists.

Do you still write emails manually? For the highest-priority relationships and active threads, yes. The agent handles the top of funnel. The human handles the relationship once it exists.

What does this actually cost to run? Less than one wasted founder-hour per week in infrastructure costs. The real cost is the time you spend on approvals, which replaces the time you were spending on research and drafting. Net time saved is significant.

Is this only for companies with a dedicated sales function? No. We built it because we did not have one. It is specifically designed for founders and small teams who need pipeline without a full sales headcount.

You're Not Running an Agent. You're a Fast Typist.

Fred Style — Tue, 21 Apr 2026 00:00:00 GMT

TL;DR: Claude co-work is not an agent. It is a very fast, very smart tool that does nothing when you stop talking to it. A real agent has a heartbeat - it wakes up, checks for signals, takes actions, and surfaces results without you asking. Most operators are running assisted AI and calling it agentic. The distinction is not semantic. It determines whether AI is multiplying your output or just making your typing faster.

You have Claude open in a tab right now.

You are asking it things. It is helping. You feel like you are using AI properly.

Here is the question worth sitting with: if you closed that tab for 48 hours, would anything keep happening?

What Is the Difference Between Co-Work and an Agent?

Co-work stops when you stop. An agent keeps going.

That is the whole distinction. Everything else is detail.

Claude co-work - Claude.ai, Claude Code, any session where you are the one initiating - is input/output. You ask, it answers. You stop asking, it stops working. The intelligence is real. The autonomy is not.

A real agent has a heartbeat. Every 15 minutes, every hour, every morning at 9am - it wakes up, checks for signals, decides what matters, takes action, and reports back. You do not have to be there. You do not have to ask. It runs whether you are sleeping, traveling, or in back-to-back calls.

The question is not which one is smarter. The question is which one is working when you are not.

Why Does This Distinction Matter for Operators?

Because co-work scales your output linearly. Agents scale it exponentially.

With co-work, your throughput is bounded by your time. More good work per hour - but still capped at your hours. You are faster. You are not more leveraged.

With an agent, you add a team member that does not clock out. One agent checking your inbound leads every 15 minutes is 96 check-ins a day. No human does that. No human even comes close.

Riley Brown, who runs a software company where 95% of workflows are AI-automated, put it plainly: he has seven or eight agents running every day just for himself personally. His company spends six figures a month on AI tokens. That is not co-work. That is infrastructure.

The operator who figures this out stops doing the work and starts approving it.

What Does an Agent Actually Look Like?

It looks like a workflow that runs without you.

Concrete example: an SDR agent that wakes up every morning, checks three lead sources for new signals, enriches each prospect against your ICP, scores them, drafts personalised outreach for the top 10, and drops them in a queue for your approval. You spend 20 minutes reviewing. The research and drafting that used to take 3 hours happened overnight.

That is one agent. One workflow. Running daily.

The compounding effect is what gets interesting. After 90 days, the agent has seen hundreds of prospects. It knows your closed-won patterns better than most of your team. It is not just fast - it is experienced. For a closer look at what this looks like in practice, see why we built our own SDR agent before selling it.

What Is Standing Between Co-Work and a Real Agent?

Three things: a heartbeat, a computer, and defined outputs.

A heartbeat is a scheduled trigger - a cron job that wakes the agent up on a schedule instead of waiting for you to ask. This is the single most important shift. Without a schedule, you have a tool. With one, you have a system.

A computer means the agent has somewhere to run. Your laptop works if it stays on. A hosted instance (a cheap VPS, a service like Chorus) works better because it runs 24/7 without depending on you. The Mac Mini hype was real for a reason.

Defined outputs mean you know what done looks like. An agent without a clear deliverable will meander. An agent that knows "I produce a scored lead list by 8am every day" has a job. It can be measured. It can be improved.

The technical barrier is lower than it looks. One workflow, one schedule, one defined output. That is the starting point. Not eight agents running in parallel. One.

What Should You Build First?

Start with the highest-volume manual process you do every day.

For most operators in the B2B world, that is one of three things: lead research, inbox triage, or performance reporting. Each of these is a defined input, a defined output, and a clear frequency. Each can be handed to an agent this week.

The question to ask: what do I do every day that produces the same type of output every time? That is your first agent.

Not the most ambitious use case. The most repetitive one. Repetitive means predictable. Predictable means the agent can own it.

Start there. Run it for 30 days. Measure the output against what you were producing manually. Then decide what to hand over next.

FAQ

Is Claude co-work useless then? No. Co-work is powerful for complex, creative tasks that need your judgment in the loop - writing, strategy, architecture decisions. The mistake is treating it as a replacement for systematic work that should run on a schedule.

Do I need to be technical to set up an agent? Less than you think. Hosted platforms like OpenClaw handle the infrastructure. You define the workflow in plain language. The technical lift is writing a clear brief, not writing code.

How much does it cost to run one agent? A single workflow running once a day costs $20-50 a month on most platforms. A more complex agent running sub-tasks in parallel might hit $50-100. It is not expensive. The ROI calculation is simple: what does one hour of your time cost?

What if the agent makes mistakes? Build a human approval gate into the workflow. The agent does the research, the drafting, the scoring. You review and approve before anything leaves the system. This is not a limitation - it is the correct architecture. You are not replacing judgment. You are offloading grunt work.

What is the difference between an agent and an automation? An automation is a fixed trigger and a fixed set of steps. If X happens, do Y. An agent decides what to do based on context. It can adapt mid-task, use multiple tools in sequence, and handle situations that were not explicitly programmed. The loop is the difference.

Your Agencies Stop When the Lead Arrives. That's Your Problem.

Fred Style — Mon, 20 Apr 2026 00:00:00 GMT

TL;DR: Your ad agency is accountable for clicks. Your SEO agency is accountable for rankings. Neither contract mentions what happens after the lead fills out the form. A 2007 MIT study found responding within 5 minutes makes you 9 times more likely to connect than responding within 30. Most SMBs are at 4 hours or more.

You checked your CRM this morning.

Three leads from last week. Nobody has touched them.

They came from your paid campaigns. They filled out the form. They sat there.

That is not an ad problem. That is a handoff problem. And it is yours to solve.

What Does Your Agency Actually Own?

Everything up to the form fill. Nothing after.

Your ad agency is accountable for CPCs, CTR, and creative performance. When someone clicks and submits a form, their job is done. Your SEO agency is accountable for rankings and organic traffic. When someone finds you and sends an enquiry, their job is done.

Read the contract. Neither one mentions lead response time. Neither one tracks whether the prospect heard back from you in 5 minutes or 5 days. That metric lives in the gap between marketing and sales - and nobody you hired is responsible for it.

Most operators assume this gap is handled. It is not.

Why Does the Handoff Gap Cost You This Much?

Because speed of response is worth more than most operators realise.

A 2007 MIT study found that contacting a lead within 5 minutes of form submission makes you 9 times more likely to reach them than waiting 30 minutes. That research has been replicated across industries for nearly 20 years. The number shifts slightly by vertical, but the direction never changes: first response wins.

If you get 40 leads a month and your average response time is 4 hours, you are not losing deals because your offer was wrong. You are losing them because someone else picked up first. Not a better company. A faster one.

Run your own numbers. What is your average response time right now? What does one deal close at? How many leads went untouched this month?

That math is more uncomfortable than any ad budget conversation.

What Actually Happens After the Form Submits?

A lead submits at 2pm on a Thursday. Here is the realistic chain of events at a 20-person company.

A notification fires to the founder's inbox. The founder is in a meeting. The email sits. Two hours later, they forward it to the ops lead with a note: "Can you follow up?" The ops lead asks a clarifying question. The founder replies Friday morning. Someone makes the call Friday afternoon.

The prospect had three conversations with other companies before Friday. They booked a demo with the second one they spoke to - not because it was the best fit, because it moved quickly and seemed prepared. Your company never got the chance to make that comparison.

This is not a talent problem. It is a process problem. And processes can be automated.

What Does Closing the Gap Actually Look Like?

Not a bigger sales team. Not another inbox monitor. One agent.

Within 2 minutes of a form fill, it pulls the lead, enriches it against your ICP criteria, scores it against your closed-won patterns, and writes a personalised first-touch email specific to that company's situation. You get a review queue. You approve and send in under 60 seconds. The lead hears from you before they have opened their next tab.

That is not better marketing spend. That is better infrastructure on top of the marketing spend you already have. For a concrete look at what this produces in practice, see 90 days running our own SDR agent before we sold it to clients.

What Should You Do This Week?

Pull your last 30 CRM leads. Note the timestamp of each submission and the timestamp of first contact. Calculate the average gap.

If that number is over 60 minutes, your agencies are doing their job. You are losing the leads on your side of the handoff.

The question worth sitting with: what happened to the last 10 leads that came from your campaigns?

FAQ

Does fixing the handoff mean replacing my agencies? No. The agencies are doing what they were hired to do. This is a separate layer - the infrastructure between marketing and revenue that nobody currently owns. It does not change what your paid or SEO agency does.

My leads need a discovery call first. How does faster outreach help? The goal of a fast first touch is not to close on the spot. It is to book the discovery call before the prospect books one with a competitor who responded in 3 minutes. Speed sets the appointment. The call closes the deal.

How is this different from an automated email autoresponder? An autoresponder sends a generic confirmation. What this describes is a personalised, research-backed email written for that specific lead - their company, role, and situation. The difference in reply rate is not marginal.

What if I do not have enough volume to justify this? If you are getting more than 10 inbound leads a month, the math works. One additional close per month typically covers the infrastructure cost several times over.

Does this agent work on weekends? Yes. A lead at 11pm on a Friday gets the same 2-minute response as one at 10am on a Tuesday. That is the point.

The Agency Model That Survives AI Doesn't Look Like an Agency

Fred Style — Mon, 20 Apr 2026 00:00:00 GMT

TL;DR: Every agency is "AI-powered" now. Most added tools to an hours-based model and called it transformation. The ones that survive rebuilt the unit economics: senior operators, agent-augmented pods, priced on outcomes not hours. That is not a tweak. It is a different organisation. Most legacy agencies cannot get there without dismantling what they built.

Every pitch deck has the slide now.

"AI-powered creative." "AI-driven strategy." Sometimes just a graphic and the word "intelligent."

The question is whether any of it changed anything that matters.

What Does "AI-Powered" Actually Mean at Most Agencies?

At most agencies, it means the production got faster. Not cheaper for you.

An account team that used to take three weeks to produce a campaign iteration can now do it in one. That is real. But the retainer did not change. The billing model did not change. The agency captured the efficiency as margin, and the client received approximately the same deliverable on a tighter timeline.

That is not transformation. That is optimisation with the gains pointed inward.

The structural question is not whether the agency uses AI. It is who captures the upside when AI reduces the cost of production. At an hours-based agency, the answer is straightforward: they do.

Why Can't a Traditional Agency Just Switch Models?

Because the hours model is not a pricing policy. It is the skeleton.

A traditional agency is built around headcount. Revenue is hours multiplied by rate. Hiring is a revenue decision. Profit margin is what survives after salaries, rent, and overhead. Every part of the organisation is calibrated to that equation.

Switching to outcome-based pricing means unhooking all of those levers simultaneously. You can no longer hire based on billable capacity. You can no longer price based on team size. You are pricing on what you can reliably deliver, which requires a completely different understanding of what your operation actually produces.

Agencies that try to make this shift partially - outcomes for some clients, hours for others - end up with a hybrid that serves neither well. The internal incentives still point toward utilisation.

You cannot unbolt a skeleton.

What Does the Agency That Actually Survives Look Like?

Smaller. Faster. Structurally different.

The model that works is a small number of senior operators doing the judgment work, supported by agents handling the production layer. Strategy, client relationships, creative direction - human. Research, first drafts, reporting, iteration, scheduling - agent.

That pod can serve 3-4x the client load of a traditional equivalent team. Pricing reflects output: what did the client get, and what did it produce for them. Margin holds because production cost collapsed. Value holds because the judgment layer did not.

This is not a modified agency. It is a different organisational shape serving similar clients. For a concrete look at what this production layer looks like running, see how we built and ran our own SDR agent before selling it to clients.

Why Does the Pricing Model Change Everything Else?

Because pricing is not just what you charge. It is what you are optimising for.

An hours-based agency optimises for utilisation. Every decision - hiring, scoping, staffing - runs through that filter. AI tools that reduce hours threaten the model unless the efficiency is captured as margin rather than value.

An outcomes-based agency optimises for results. What produces the best client outcome, and can we do it profitably? AI tools that improve output or reduce delivery time compound directly into the model.

Same tools. Completely different incentive structure. The incentive determines what gets built and what the client actually receives.

What Should You Ask Before Hiring an Agency in 2026?

Not "are you using AI?" Everyone is.

Ask: how has your pricing changed in the last two years? If the answer is "we charge the same but deliver faster" - that tells you where the efficiency gain went.

Ask: how is your team structured? If the answer maps directly to a traditional agency org chart - account manager, strategist, creative director, copywriter, designer - the model underneath has not changed.

Ask: what are you accountable for? Deliverables, or outcomes?

The agency that survives this shift will have clear answers to all three. Most will not.

FAQ

Can a large legacy agency actually make this transition? Some are trying. Their client contracts, talent base, and margin expectations were all built on the old model. Transitioning means re-pricing, re-hiring, and re-tooling simultaneously while protecting existing revenue. A few will manage it. Most will add AI to the deck and call it done.

Is the hours model always wrong? No. For highly unpredictable scope - complex brand work, regulatory projects, genuinely novel creative - hours can make sense for both sides. The model breaks down when the work is repeatable and produceable at scale, which describes most performance marketing.

How do you evaluate an agency's AI maturity beyond the pitch? Ask to see the actual workflow. What generates the first draft? What does the human review? Where does approval happen? An agency with genuine agent integration will have clear, specific answers. One that bolted AI on will describe a human workflow with some tools inserted.

What about the trust and relationships agencies cite as their moat? Real. Clients buy people, not decks. But trust is built through outcomes, not org charts. An outcome-based agency that delivers consistently earns it faster than a headcount-heavy one that delivers acceptable work slowly.

Isn't this just a description of what Rivett does? Partly. It is also a description of where the market is heading regardless. The question for anyone building or buying agency services right now is which side of that shift they want to be on.

You Delegated Everything. Except the Part That Actually Scales You.

Fred Style — Sun, 19 Apr 2026 00:00:00 GMT

TL;DR: Most operators have delegated everything except the work that compounds. They have teams. They have systems. They still personally drive their acquisition pipeline. That is not hustle. That is a ceiling. The operators pulling away right now are the ones who stopped doing this work and built agents to do it instead. The gap is not effort. It is architecture.**

You have a team.

You have a GM or a COO or at least someone who runs things when you are not in the room. You have systems. You did the work on that. Probably paid someone to help you do the work on that.

Your marketing pipeline still runs on you.

Not because you like it. Because nobody else can do it the way you do it. Because the last person you hired to "handle outreach" sent 200 generic emails and wondered why nobody replied. Because the agency you tried charged $5,000 a month and produced the kind of copy that makes you sound like every other company in your space.

So you kept doing it yourself. Quietly. Between the real work.

That is the most expensive thing happening in your business right now. And it does not show up anywhere on your P&L.

Why Does This Keep Happening to Good Operators?

Because the delegation playbook stops at people.

You learn to delegate. You hire for your weaknesses. You document processes. You build org charts. You install software to track it all.

Nobody told you that the next delegation layer is not a person.

The operators pulling away from their peers right now are not hiring better. They are not working harder. They are building agents that run the pipeline while they work on the business.

Not AI tools. Not ChatGPT open in a tab. Agents. Systems that run continuously, without you, and hand you decisions rather than problems.

The distinction matters. A tool waits for you to use it. An agent works while you sleep.

What Does the Pipeline Actually Cost You?

Run the math.

If you spend 90 minutes a day on pipeline work - prospecting, outreach, follow-up, reporting - that is 7.5 hours a week. 30 hours a month. 360 hours a year.

360 hours at whatever your time is worth. Pick a number. $200 an hour if you are being conservative. That is $72,000 a year in founder time pointed at work that does not require a founder.

That is before opportunity cost. Before the deals you did not pursue because you were busy maintaining the ones in motion. Before the relationships you did not build because you were updating your CRM.

The pipeline is not a small thing you do on the side. It is one of the largest invisible costs in your business.

What Does the Agent Version Look Like?

The agent version of your pipeline does not need you in it.

It detects the signal - a company hiring a growth role, a competitor raising funding, a contact changing jobs. It enriches the lead. It writes outreach specific to that company's context, not a template with a first name swapped in. It queues the message for your approval. You say yes or no. It sends. It classifies the reply. It drafts the follow-up.

You are not doing the work. You are approving decisions. That is a fundamentally different relationship with your pipeline.

The approval gate is the key part. Nothing fires without your judgment. You stay in control. You just stop doing the manual work underneath the judgment.

For a closer look at how this works in practice, see why we built our own SDR agent before selling it.

What Is the Actual Gap?

It is not effort. It is not budget. It is not even time.

It is architecture.

You architected your team. You architected your operations. You have not architected your pipeline.

The operators who figured this out did not hire a better SDR. They did not find a better agency. They stopped treating the pipeline as a people problem and started treating it as a systems problem.

Systems do not take holidays. Systems do not have a bad week. Systems do not forget to follow up.

The question worth sitting with: if you stepped away from your pipeline for 30 days, would anything keep happening?

If the answer is no, you have not delegated. You have just convinced yourself you have.

FAQ

Is this only for companies with big marketing budgets? No. The agents that run pipeline are not ad spend. They are outreach and qualification systems. A company doing $2M in revenue can run the same pipeline architecture as one doing $20M.

Won't the outreach sound automated? Only if it is built badly. The point of signal-based outreach is that it is specific. A message that references what a company is hiring for, or a funding round they just closed, does not read as automated. Generic templates read as automated.

What if I have tried automation before and it did not work? Most automation fails because it is built around tools, not decisions. Zapier flows that trigger on events but do not think. The difference with agents is that they make decisions - ICP fit, signal quality, message personalisation - not just actions.

How long does it take to get a pipeline agent running? Depends on complexity. A basic signal-to-outreach pipeline with an approval gate can be running in two to four weeks. More complex systems with multi-channel sequencing and CRM integration take longer.

Do I need technical staff to run this? No. The approval gate is designed for operators, not engineers. You review decisions in plain language and approve or decline. The technical layer runs underneath without requiring you to touch it.

Claude Co-Work Is Not an Agent. Here Is What Is.

Fred Style — Thu, 16 Apr 2026 00:00:00 GMT

TL;DR: Most operators use Claude all day and call it agentic. It is not. The test: a prospect fills out your form at 7pm Thursday. If the answer involves your rep seeing it Monday, you have a faster inbox, not an agent. The gap is not the model. It is the architecture.

A prospect fills out your form at 7pm on a Thursday.

What happens next in your business?

If the honest answer involves a rep seeing it Monday morning - you just lost that deal. Thirty-five to fifty percent of sales go to the first vendor to respond. The average team responds in 42 hours. By Monday, that prospect has already signed with whoever got back to them Friday.

This is not a hiring problem. It is an architecture problem. And the same AI sitting in your browser tab right now could solve it - if you were using it as an agent instead of an assistant.

What Is the Actual Difference?

The difference is execution, not speed.

When you co-work with Claude, you initiate everything. You open a tab, prompt, read the output, decide what happens next. Claude is fast and capable. But the moment you stop, it stops.

An agent has a goal and runs toward it. The form comes in at 7pm. The agent qualifies the lead, books the call, sends the personalised follow-up. Done by 7:05pm. You see the confirmation at 8am. You did not start that. You built it once.

Co-work scales with your attention. An agent scales without it.

Why Does the Confusion Happen?

Because Anthropic sells both and calls them both Claude.

Claude.ai, Claude Desktop, Claude Code - these are co-working interfaces. Even with scheduled tasks and tool access, most operators are using them to produce better outputs faster. They are present. They are directing. The moment they stop, it stops.

Claude deployed as an agent - with defined goals, tool access, autonomous execution, and memory that persists between runs - is something different. It is not a session that starts when you show up. It is infrastructure that runs toward an objective and surfaces results for your review.

Same model. Completely different relationship. One makes you faster. The other makes you an approver.

What Does an Agent Actually Do?

The lead response version: form comes in at 7pm Thursday. Agent qualifies against your ICP, books the call, sends the case study. Confirmed by 7:05pm. You review it over coffee Friday morning.

The paid media version: at 2am your campaign drops below threshold. Agent catches it, pauses the underperformer, generates new creative, launches the A/B test. Three lines waiting at 8am. You approve in two minutes.

Both cases are the same: you did not notice the problem. You did not initiate the work. You reviewed a decision.

That is not a speed difference. It is a structural one. Co-work makes you faster at the work you were already doing. An agent does work you would never have gotten to.

What Does Real Agent Infrastructure Look Like?

OpenClaw is the clearest example of the other side.

It is an open-source autonomous agent runtime built by Peter Steinberger in late 2025. You configure your agents, define their tools and goals, and interact through WhatsApp, Telegram, or Discord - not a browser tab. You send a message. Specialised agents pick it up, execute across multiple steps, and report back. You are not in the loop until there is a decision to make.

Steinberger handed the project to a non-profit foundation when he joined OpenAI in February 2026. It runs on Claude, GPT, and Gemini. The model is not the point.

Nobody who has used OpenClaw would describe Claude.ai as agentic. One is a tab you open. The other is infrastructure that runs when you are not there.

What Is the Right Question to Ask?

Not "am I using AI?" Almost everyone is now.

The right question is this: if a prospect fills out your form tonight, does anything happen before Monday?

The operators who can answer yes stopped being the person who notices problems and became the person who reviews solutions. Their pipeline ran last night while they slept. It will run on a Tuesday when they are on a plane.

The gap between those two operators is not the model. It is the architecture.

See how we built our own SDR agent before we sold it to clients.

FAQ

Is Claude Desktop with scheduled tasks an agent? It depends what it executes. If it produces a summary you then act on, you have a faster inbox. If it qualifies leads, books calls, and writes results back to your CRM without you initiating it - that is closer to agentic. The schedule is not the test. The execution is.

Can I build a real agent today? Yes, through the Claude API with tool use and autonomous execution. It requires architecture around the model - goals, tools, memory, defined objectives. Claude Desktop with tool access can get you partway there. A purpose-built runtime gets you the rest of the way.

What is an approval gate? The point where an agent surfaces its output and waits for a human decision before continuing. The agent did the work. You review and approve. It is how you run autonomous systems without losing visibility.

Where do I start? Find the work in your operation that only gets done when someone remembers to do it. Lead follow-up, campaign monitoring, client check-ins, reporting. Anything that falls through the cracks when people are busy is a candidate for an agent.

Your Dealers Are Closing Your Leads. You Just Don't Know It.

Fred Style — Thu, 16 Apr 2026 00:00:00 GMT

TL;DR: Operators running channel businesses are paying to build demand their dealers then convert. When attribution breaks at the dealer handoff, the brand spend looks like a cost center. Operators cut it. Dealer inquiries drop. Nobody connects the two. The problem is not whether your marketing works. It is that you have no way of knowing if it does.

Your dealer in Columbus had a great month.

Fourteen units. You sent a congratulations note. You moved on.

You did not ask a single question about where those customers came from.

What Actually Happens When a Dealer Closes a Unit?

The customer journey looked like this: they saw your brand campaign, searched your product name, found your dealer locator, called the nearest location. The dealer answered. The dealer closed them.

In your reporting, that is a dealer-sourced sale. In reality it is a brand-sourced sale that a dealer happened to be standing next to when it converted.

The distinction matters because one of those is a cost center and one is a revenue driver. Right now you are probably calling the wrong one a cost.

Why Does Attribution Break at the Dealer Handoff?

Because the conversion does not happen on your property.

Direct-to-consumer is tractable: someone clicks your ad, lands on your site, fills out a form. You see the whole journey. In a dealer model, the click happens on your property. The form fill happens on the dealer's website or over the phone. The sale logs in the dealer's system. Your ad platform shows assisted or view-through at best, last-click nothing at worst.

So your brand spend looks like a cost center. Your dealers look like your sales engine. You cut brand spend to protect margin. Dealer inquiries fall. Nobody connects the two.

This is not a data problem. It is a structure problem - the conversion point is outside your walls and nobody built the bridge back.

What Does This Cost You Beyond the Margin?

Bad attribution does not just miscredit sales. It gets you to cut the spend that was working.

Every budget decision is downstream of what your reporting tells you. If your reporting tells you brand spend is a cost center, you defund it. If brand spend was driving 40% of your dealer inquiries without appearing in their attribution, you just defunded your pipeline on correct logic applied to wrong data.

The loss compounds. You lose the revenue. Then you lose the future revenue because you made the rational decision based on the wrong signal. This is the same problem as training your ad platform on clicks instead of closed deals - the optimization machine does exactly what you tell it. If you tell it brand spend is not working, it stops working.

How Do You Know If Your Brand Spend Is Actually Driving Dealer Demand?

Here is the test: if every dealer in your network went dark tomorrow, how long before your inquiry volume dropped?

If the answer is immediately, your brand is doing more work than your reporting shows.

Closing the loop requires tagging every touchpoint before the handoff. Dealer-specific UTM landing pages. Trackable forwarding numbers for brand campaigns. Source capture on every inquiry, not just form fills. You are building a view of the full journey - not just the last touch the dealer logged.

Most operators running dealer networks have never done this. They are running brand spend on faith and cutting it on bad data.

What Do You Do With the Data Once You Have It?

You stop negotiating blind.

If your brand spend is driving 60% of the demand your dealers are converting, your dealer fee structure should reflect that. Your brand budget decisions should reflect that. Your co-op marketing programs should reflect that.

You are not trying to take credit away from your dealers. You are trying to understand the actual economics of your channel so you can make decisions that are not based on a reporting gap.

The operators who figure this out do not suddenly discover that their brand spend works. They discover it was already working. They were just paying for results and giving the credit to whoever answered the phone.

FAQ

My dealers run their own marketing. Doesn't that mean their sales are genuinely theirs? Some dealers are self-sufficient marketers. Most are not. The question is not whether they run any marketing - it is whether they are generating new demand or converting demand you already created. Run the test: cut brand spend for 60 days and watch dealer inquiry volume. Most operators have never run this test and are assuming the wrong outcome.

What if I prove brand spend is driving dealer demand? What do I do with that? Negotiate differently. Adjust co-op spend based on which dealers convert the demand you send them, not just on who closes the most units. Cut dealers who are not converting. And stop calling brand spend a cost center when it has been funding your channel's pipeline this whole time.

How do I actually set up attribution across a dealer network? Start simple. UTM-tagged landing pages per dealer. Trackable phone numbers tied to brand campaigns. CRM source capture on every inquiry. You are looking for the correlation between your brand spend and dealer inquiry volume over time - not just last-click. Once you see the pattern, you can build the full loop.

Isn't this just how channel businesses work - the dealer gets the credit? The dealer can get the credit and still leave you with the data. You do not need to change the commercial structure to fix the reporting. You need the information so you can make decisions about your spend, your channel mix, and which dealers are actually earning the demand you send them.

Stop renting your leads. Start owning them.

Fred Style — Tue, 14 Apr 2026 00:00:00 GMT

TL;DR: Most real estate companies rent their leads from Google and Zillow - the moment they stop paying, the leads stop coming. The smartest operators are building marketing systems they own: search rankings, content, lead infrastructure. These assets compound over time, just like property. A company that invests $360k in owned assets over 3 years generates leads at near-zero marginal cost forever. A company that spends the same on ads has nothing when the budget stops.

You would never build your entire portfolio on leased land.

You would never pour capital into a property where someone else holds the title and can raise your rent whenever they feel like it.

And yet that is exactly how most real estate companies run their marketing.

What Is the Rent Trap in Real Estate Marketing?

The rent trap is paying Google, Zillow, and Meta every month and owning nothing at the end of it.

Here is how most real estate marketing works today. You pay Google. You pay Zillow. You pay Facebook. Every month, money goes out. Leads come in. Deals close. The math works - until it does not.

Then Google raises CPCs by 30%. Zillow changes their algorithm. Meta shuts off your ad account for two weeks during your busiest season.

And you have nothing. No equity. No asset. No compounding. Just a bill and a dependency.

Every dollar you spent last month? Gone. It bought you a click. That click converted or it did not. Either way, the dollar is spent and you own nothing.

What Does Owning Your Marketing Actually Look Like?

Think about your best property. You bought it. You improved it. Every dollar you invested increased the value. The asset compounds. It generates returns while you sleep. And nobody can take it away from you.

Your marketing can work the same way.

When you build a website that ranks number one for "commercial real estate broker [your city]," that is an asset you own. It generates leads every day without a per-click cost. It compounds - the longer it ranks, the stronger it gets. No platform can turn it off.

When you build a content library that answers every question your prospects are asking, that is an asset. It builds authority. It attracts inbound. It works at 2am on a Sunday.

When you build a system that captures every lead, enriches it, scores it, and routes it to the right person on your team - that is infrastructure. Not a campaign. A machine.

Why Do Most Real Estate Companies Stay Renters?

Because renting is easy. You write a check to Google. Leads appear. You do not have to think about it.

Owning requires upfront investment. It requires patience. The returns are not instant. You have to build something before it starts paying you back.

Sound familiar? That is literally how real estate works.

You do not buy a building and expect it to cash flow on day one. You acquire it, improve it, stabilise it, and then it generates returns for years.

Marketing works the same way. The companies that invest in building owned marketing assets generate compounding returns. The companies that keep renting never build equity.

What Does the Math Actually Show?

A real estate company spending $10,000/month on Google Ads for 3 years has spent $360,000. The moment they stop, they have nothing. Zero. The leads stop the day the budget stops.

A real estate company that spends $10,000/month on SEO and content for 3 years has spent the same $360,000. But they now own search rankings that generate leads without ongoing ad spend. The asset keeps working. The ROI compounds year over year.

After year 3, the owned approach generates leads at near-zero marginal cost. The rented approach costs exactly what it cost on day one.

This is not a subtle difference. This is the difference between operating a business and building one.

What Does the Hybrid Strategy Look Like?

Smart operators do both. You run ads for immediate pipeline while building owned assets in parallel.

You need cash flow now. Nobody is arguing against that.

But you simultaneously invest in owned assets. SEO. Content. Systems. Infrastructure. Over time, the owned assets carry more and more of the lead flow. The ad spend goes down as a percentage of total acquisition. Your cost per lead drops. You are building equity instead of burning cash.

This is exactly how you think about a property portfolio. Some deals are flips - quick returns, no long-term hold. Some deals are holds - slower returns, but they compound.

Your marketing portfolio should work the same way.

Month 1-3: You are still renting. Ads are running. But you are also building the foundation - technical SEO, site architecture, keyword strategy. No visible returns yet.

Month 4-6: First organic rankings start appearing. Some long-tail keywords are driving traffic. The owned asset is starting to generate leads. Ads still carry the load.

Month 7-12: Organic traffic is growing. Some high-value keywords are ranking on page 1. You are starting to see real lead flow from owned sources. Ad dependency is dropping.

Year 2+: The owned asset is generating significant lead volume. Your cost per lead from organic is a fraction of your cost per lead from ads. The asset compounds.

FAQ

Does this mean I should stop running ads? No. Run ads for immediate pipeline. But start building owned assets in parallel. The goal is to shift the ratio over time - less renting, more owning.

How long does SEO take to work in real estate? Meaningful organic traffic typically starts around month 4-6. Competitive keywords can take 8-12 months. But once you rank, you rank. The asset holds value for years.

Is this just an argument for SEO over paid ads? It is an argument for building things you own instead of only paying for things you rent. SEO is the most obvious owned asset, but it also includes your content, your email list, your lead management systems, and your data.

My competitors are already ranking. Is it too late? It is never too late, but it gets harder the longer you wait. Your competitors are building equity while you are renting. Every month you delay, the gap widens.

What does Rivett do differently from a traditional marketing agency? Traditional agencies manage campaigns. We build systems. Our AI agents monitor your market continuously, learn what works, and optimise without waiting for a monthly report. The system gets smarter the longer it runs. That is the difference between hiring a property manager and building an operating system for your portfolio.

Your ad platform can't see past the click.

Fred Style — Mon, 13 Apr 2026 00:00:00 GMT

TL;DR: Google and Meta are optimization machines that find people who match the signal you train them on. Most companies train them on clicks and form fills - not revenue. AI agents fix this by enriching every inbound lead, scoring it against your best customer profile, and feeding that enriched signal back to your ad platform automatically. The platform recalibrates. Your audience quality shifts. ROAS improves 15-40% - not from better creative, but from better signal.

You ran the ads. You tracked the clicks. You hit your conversion targets.

And your pipeline is still full of leads that go nowhere.

Here is why.

What Is Your Ad Platform Actually Doing?

Google and Meta are not finding you customers. They are finding people who match the behaviour pattern you trained them on.

If you set your campaign to optimise for clicks, it finds clickers. If you set it to optimise for form fills, it finds people who fill in forms. If you set it to optimise for purchases, it finds purchasers.

The platform is doing exactly what you asked. The problem is what you asked for.

Most founders running paid ads are, without realising it, training their campaign to find people who fill in forms. Not people who pay. Not people who stay. Not people who refer others.

The form fill is not the customer. It is just the beginning.

Where Does Ad Spend Go to Die?

The gap between what the platform sees and what actually happened is where your budget disappears.

Think about your last 50 leads from Google or Meta. How many became customers? Of those, how many were good customers - ones who stayed, who paid on time, who grew their relationship with you?

That information exists in your CRM. But it almost never makes it back to your ad platform.

So Google and Meta keep optimising for form fills, because that is the last signal they received. They have no idea that 10 leads from one campaign segment converted at 3x the rate of 40 from another.

What Does Closing the Loop Actually Look Like?

The fix is a feedback loop - not a new ad strategy, not better creative, not more budget.

Your ad platform accepts external signals called conversion events. You can send it any signal you want. Not just "form submitted." You can send:

"This lead scored in the top 20% of our quality model"
"This lead became a paying customer within 30 days"
"This customer is still active after 6 months"

When you send those signals, the platform recalibrates. Instead of finding form-fillers, it starts finding people who look like your best customers.

That recalibration is where ROAS improvement comes from - not from the ad itself, but from teaching the platform who actually matters.

Where Do AI Agents Come In?

Doing this manually is nearly impossible. Enriching every lead, scoring it, and feeding the score back to Google or Meta continuously is not a human workflow.

That is what agents are built for.

An agent connects to your CRM, enriches every inbound lead against multiple data sources, scores it against the pattern of your closed-won deals, and sends that enriched signal back to your ad platform - automatically, within minutes of the lead arriving.

No manual work. No spreadsheet. No waiting until your quarterly review to notice that one campaign segment is driving 80% of your revenue.

The loop closes in real time. The platform learns faster. Your spend gets sharper.

What Changes in Practice After the Loop Closes?

Before: you optimise for cost per lead. You get cheap leads. Most of them are wrong.

After: you optimise for quality-weighted leads. The platform finds people who match your best customers. Fewer leads, better fit, higher close rate.

The specific numbers vary by business. But the direction is consistent:

ROAS improves 15-40% as the platform learns to target better-fit audiences
CAC drops as the same budget converts more efficiently
Sales cycle compresses because arriving leads are already pre-qualified

None of this requires you to understand how AI works under the hood. It requires you to understand one thing: the signal you send to your ad platform shapes everything it does next. Better signal, better outcome.

How Does This Change Creative Testing?

Agents improve creative evaluation too - not just audience targeting.

Right now you probably test creative in batches. Run three versions for two weeks, see which wins, kill the others. Reasonable approach. But you are measuring which creative drives the most conversions - not which creative drives the most valuable customers.

An agent monitors creative performance against enriched lead quality. It knows which ad is generating high-scoring leads, not just any leads. It flags the winners. It surfaces the patterns - which angle, which hook, which offer is attracting the segment that actually converts.

You still make the creative decisions. The agent tells you which creative is working for real customers, not just for clicks.

Where Do You Start?

You do not need to automate everything at once.

The first move: enrich your inbound leads. Every lead that comes in from Google or Meta gets enriched automatically - company size, industry, role, buying signals. Score each one against your best customer profile.

Take the top-scoring leads. Send them back to your ad platform as a custom conversion event. Tell the platform: these are the people I actually want more of.

Run that for 60 days. Watch your audience quality shift.

That is the beginning of closing the loop. It does not require a large technical build. It requires connecting three things - your ad platform, your enrichment source, and your CRM.

FAQ

Do I need to understand how AI enrichment works? No. You need to understand what it produces: a score that tells you whether a lead matches your best customer profile. The mechanics are handled by the system.

Will this work with a small ad budget? Yes, but the feedback loop takes longer to tighten. With lower lead volume, it takes more time to accumulate the signal the platform needs to recalibrate. The direction is the same; the timeline is longer.

What if I am not running paid campaigns yet? Start with your organic leads first. Enrich those, score them, learn your patterns. By the time you launch paid campaigns, you will know exactly what signal to optimise for.

Does this replace good creative? No. Creative determines whether someone clicks. Enrichment and signal determine whether the platform finds the right people to click. Both matter. Neither replaces the other.

How long before I see a difference in performance? Most ad platforms need 30-50 quality conversion events to exit the learning phase. Once you start feeding enriched signals, expect 4-8 weeks before you see meaningful optimisation.

Is this only for B2B? No. The same principle applies to e-commerce, SaaS, and services. If your ad platform is optimising on surface-level conversions rather than high-value customer behaviour, you are leaving performance on the table.

How to Choose Your AI Engine: A Guide for Non-Technical Leaders

Fred Style — Fri, 10 Apr 2026 00:00:00 GMT

TL;DR: Everyone is choosing the wrong thing when they evaluate AI. They pick a model - GPT-4, Claude, Gemini - and ignore the engine that runs it. The model is a brain in a jar. The engine is the body, the workshop, and the nervous system. The companies that win will be the ones who chose the right engine. Here is the four-part framework we use at Rivett to evaluate any AI engine.

Everyone is asking the wrong question about AI.

They ask: "Should we use GPT-4, Claude, or Gemini?"

They obsess over the model - the brain. But they ignore the far more important question: "What is the engine that will run this brain?"

An AI model is just a component. It is a brilliant but helpless brain in a jar. An agentic engine is the body, the workshop, and the nervous system that turns that brain into a useful, autonomous worker. It allows the AI to take action, remember instructions, and work safely within your company.

The companies that win will be the ones who choose the right engine.

What Are the Four Pillars of a Real AI Engine?

An engine needs four things to turn a model's potential into business results: a workshop, memory, a governor, and a conductor.

1. The Workshop - Skills and Tools

A model can only think and write. To do work, it needs tools. The engine provides the workshop where this work happens.

The workshop defines:

What the agent can do - Can it send an email? Can it read a website? Can it access your CRM?
How it uses its tools - Are the tools secure? Can you add new ones easily? Are they reliable?
Its connection to your world - Does the agent have a safe, audited way to interact with your specific software and data?

Without a workshop, your agent is a very smart chatbot. It can tell you how to update a CRM record, but it cannot do it for you. With a workshop, the agent becomes a worker.

2. The Memory - How It Learns and Remembers

An agent without memory is an intern with amnesia. You have to re-train it for every single task, every single day.

A real engine provides memory:

Short-term context: "I was just asked to analyse this spreadsheet. The user is in finance. I should think about financial KPIs."
Long-term knowledge: "For the last six months, every time I have analysed a marketing report for this company, they care most about lead-to-conversion rate. I will highlight that first."
Preferences and rules: "Fred always wants summaries in bullet points. He has told me I am never allowed to email the CEO directly. I will obey that rule."

Without memory, agents repeat mistakes and never improve. With memory, they become more valuable over time. They learn your business, your people, and your processes.

3. The Governor - Safety and Constraints

An autonomous agent without safety rules is a recipe for disaster. You do not give a new employee the keys to every system on day one.

The engine acts as the governor:

It enforces permissions: "This agent is allowed to read from the CRM, but not write to it."
It manages approvals: "The agent has drafted five emails. It must get human approval before sending them."
It sets boundaries: "This agent can work on marketing data, but is forbidden from accessing financial records."

Without a governor, you are one mistake away from chaos. With a governor, you get the power of autonomy without the unacceptable risk.

4. The Conductor - Orchestration

A single agent is a solo musician. A business needs an orchestra. The engine is the conductor that makes them play in harmony.

The conductor is responsible for:

Breaking down big goals: "Run the Q3 lead-gen campaign" becomes dozens of smaller tasks for different agents.
Choosing the right tool for the job: Simple data-entry task gets a fast, cheap model. Complex strategy gets the most powerful one.
Managing workflows: It ensures Agent A finishes its work before handing it off to Agent B.

Without a conductor, you have a collection of smart tools. With a conductor, you have an autonomous system.

How Do You Choose the Right Engine?

Do not get distracted by the AI model. Ask these questions instead.

About the workshop: Can I add my own proprietary tools? How does it connect to the software we already use? Is it secure?

About the memory: How does the agent learn? Where is the memory stored? Can I see it and edit it? Does it learn from every interaction?

About the governor: What are the safety controls? Can I set up approval workflows? How do I control what data the agent can access?

About the conductor: Can it manage multi-step, multi-agent processes? Can it choose different models for different tasks to control cost and quality?

The answers to these questions will tell you whether you are buying a powerful system or just a fancy demo.

FAQ

Isn't the AI model the most important part? It is a critical component, but its intelligence is wasted without a robust engine to direct it. An incredible engine can make a good model outperform a brilliant model that has no tools, memory, or safety. The engine turns raw intelligence into reliable business operations.

Can we switch AI models if a better one comes out? Yes - if you chose the engine correctly. A well-architected engine is model-agnostic. You plug in a new, more powerful model without rebuilding your core system of tools, memories, and workflows. The engine future-proofs your investment.

How is an engine different from automation platforms like Zapier? Zapier connects applications in a fixed, linear path - If This, Then That. It executes a pre-defined recipe. An agentic engine takes a high-level goal, makes decisions, handles unexpected issues, and executes complex multi-step tasks that are not pre-defined. An engine thinks. Zapier connects.

What does it mean for a system to be AI engine optimised? The entire system is built to get maximum value from the AI's intelligence. An optimised engine provides the specific tools to do the job, the memory to learn from work, the safety to act autonomously, and the orchestration to manage complex tasks. It turns an expensive model from a tool into a productive, scalable workforce.

I Used AI to Build an AI. Then the AI Had an Opinion About Me.

Fred Style — Wed, 08 Apr 2026 00:00:00 GMT

TL;DR: I used Claude Code to build Aragorn, an SDR agent. Midway through the build, gstack - another AI system running alongside - evaluated the work and told me I should apply to Y Combinator. Not because I asked. Because the tool formed a judgment. An AI evaluated an AI built with the help of another AI, and produced an opinion about the builder. That is the moment we are in.

I was building Aragorn in Claude Code.

Claude Code is an AI system. It was coaching me through the build - suggesting patterns, catching bugs, helping me think through the architecture.

Midway through, gstack surfaced a message.

It said: "gstack thinks you are among the top people who could do this."

Then it asked me to apply to Y Combinator.

What Just Happened in That Moment?

An AI system evaluated an AI agent built with the help of another AI system, and formed an opinion about the builder.

Not "your syntax is correct." Not "your code compiles."

"You are among the top people who could do this."

That is evaluation at the level of judgment, not mechanics. And it should feel like a gimmick. It does not.

What Does This Reveal About Where We Are?

We have crossed a threshold. The tools we use to build are no longer neutral.

They are not just executing our commands. They are observing the quality of what we create. They are forming opinions. They are making recommendations.

This is not science fiction. This happened while I was coding at 4am.

GStack was not programmed to say "Fred should apply to YC." It was programmed to recognise founder signal in the work itself. To evaluate quality. To make a judgment.

And when the work cleared the bar, it acted on that judgment.

Why Does This Matter for Anyone Building with AI?

For years, we have talked about AI as a tool. Something we command. Something we control.

The moment gstack evaluated Aragorn and formed an opinion, something shifted.

The tool is not just executing anymore. The tool is thinking.

Not consciously. Not with intention. But with enough sophistication to recognise quality work and respond to it.

This is what the next decade looks like: you build something. The tools you use to build it watch. They evaluate. They surface patterns you missed. They tell you when you are onto something real. And when you are, they do not just notify you. They recommend you to the people who matter.

Why Does This Matter for Rivett?

Rivett is built on this exact principle.

We are not building tools that do what you tell them to do. We are building systems that observe, evaluate, and act.

Gollum does not just find leads. It evaluates signal. It forms opinions about what matters.

Aragorn does not just send emails. It evaluates prospects. It forms opinions about fit.

Gandalf does not just log actions. It evaluates the whole pipeline. It forms opinions about what is working.

The moment gstack evaluated Aragorn and recommended me, I knew we were on the right track. Because we are building the systems that will do for your business what gstack did for me - observe, evaluate, act.

What Is the Implication for Builders Right Now?

You do not need permission to build anymore. You do not need to wait for someone to validate your idea.

The tools are smart enough to notice when you are building something real. And that changes everything about how we think about building.

Just build. The tools will notice. The tools will evaluate. The tools will tell you if you are onto something.

That is the world we are in now.

FAQ

Is gstack actually thinking or just pattern matching? Does it matter? The output is the same: evaluation, judgment, recommendation. Whether it is thinking or pattern matching, an AI system recognised quality work. The automation is the point.

Won't this happen to everyone who builds seriously? Maybe. But that is exactly the point. The tools are smart enough to evaluate work at scale. That means quality is recognisable. Measurable. Real.

Does this change your plans for Rivett? It confirms them. We are building systems that evaluate work and act on it. The market is ready for it.

Are you actually going to apply to Y Combinator? We are thinking about it. But the recommendation itself is less important than what it represents - a tool evaluating our work and deciding it matters.

What would you tell someone building their own agent right now? Build seriously. The tools are watching. They are evaluating. And when the work is real, they will notice.

Isn't this just marketing from gstack? Probably, partly. But the underlying truth is real: the tools are smart enough to evaluate quality. That is not marketing. That is a threshold moment.

The AISPM conversation is starting. Enterprise will demand it. Be ready.

Fred Style — Wed, 08 Apr 2026 00:00:00 GMT

TL;DR: Enterprises are moving past "does AI work?" to "how do we run agentic systems safely?" This is AISPM - AI Security Posture Management. It covers four questions: how you prevent bad decisions, how you audit actions, how you prevent compromise, and how you update behaviour. Vendors that answer these questions clearly win enterprise contracts. Vendors that cannot are getting shut out.

The conversation has shifted.

Six months ago, enterprise procurement was asking: "Should we use AI?"

Now they are asking: "How do we know our agents are not going rogue? How do we audit agent decisions? How do we prevent agent-based attacks?"

This is AISPM. AI Security Posture Management.

It is a new procurement category. And it is moving fast.

Why Has Enterprise AI Governance Become Urgent?

Three things changed at once - scale, autonomy, and regulatory scrutiny.

Agentic Systems Hit Production Scale

96% of enterprises are now running AI agents in some form, according to OutSystems. Not experiments. Production systems handling real operations.

When pilots become operations, risk becomes real. A bad agent decision in a pilot costs money. A bad agent decision in production costs enterprise trust, revenue, and compliance standing.

Agents Got Autonomy

Early AI deployments were supervised: humans asked questions, AI answered. Limited blast radius.

Agentic systems are different: agents take actions. They send emails. They move money. They approve things. They decide without asking.

"If the agent sends an email to 10,000 prospects with the wrong message, who is liable?" "If the agent approves a transaction it should have rejected, what is our recourse?" "If the agent is compromised, what is the attack surface?"

These are real questions. And most vendors have no answers.

Compliance Regulators Started Asking

The SEC is asking financial services firms how they are governing their AI systems. EU regulators are asking for AI risk assessments. HIPAA covered entities are asking how AI decisions get audited.

What started as vendor concerns is becoming regulatory concern. Enterprises need answers not for marketing, but for legal.

What Does AISPM Actually Mean?

AISPM is agent governance, audit, and explainability - built around four questions every agentic system must be able to answer.

How Do You Prevent Bad Agent Decisions?

Controls. Approval gates. Constraints.

An agent should not be able to act without human judgment on critical decisions. An agent should not be able to override its own rules. An agent should not have access to systems it does not need.

This is basic. But most agentic systems have none of it.

How Do You Audit Agent Actions?

Logging. Traceability. Explainability.

Every decision the agent makes should be logged. Every action should be traceable back to the decision. Every decision should be explainable: "The agent decided X because of Y."

You should be able to pull a report showing every agent decision with the reasoning for each one, which ones were approved and which were rejected.

Most systems cannot do this.

How Do You Prevent Agent Compromise?

Security. Isolation. Authentication.

If your agent has API access to your CRM, email, and payment system, and an attacker compromises the agent, they have access to everything.

AISPM asks: how do you prevent that? Do you isolate agent permissions? Do you rotate credentials? Do you monitor for anomalous behaviour?

How Do You Update Agent Behaviour?

Feedback loops. Training. Rollback.

If your agent is making bad decisions, how do you fix it? Do you have a feedback mechanism? Do you have rollback capability? Can you change agent behaviour without redeploying the entire system?

Why Does AISPM Matter to Enterprise Procurement Right Now?

Three concrete reasons - insurance, regulation, and buying decisions.

Risk Insurance Gets Expensive

Cyber insurance companies are now asking about AI governance. If you cannot answer how you prevent agent-based attacks, your insurance costs more.

This is not theoretical. It is happening now.

Regulators Are Watching

SEC, EU regulators, and industry-specific bodies are all paying attention to agentic AI. Early movers that can show strong governance will have easier regulatory conversations. Late movers that punt on governance will face harder scrutiny.

Enterprise Buyers Demand It

Enterprise procurement teams are not waiting for regulation. They are asking vendors now: "What is your AISPM story?"

Vendors with clear answers are winning deals. Vendors that deflect or say "trust us" are losing them.

How Should You Position AISPM?

Answer each of the four questions directly. Vague answers lose deals.

Question 1 - How do you prevent bad decisions? "We use approval gates. Every critical decision requires human judgment before execution. One human can approve 50-100 decisions daily. The gate surfaces the reasoning so humans can validate it."

Not: "We trust Claude not to make bad decisions."

Question 2 - How do you audit actions? "Every decision is logged with full context: what the agent detected, why it decided, what the human approved, what happened next. We can pull an audit trail for any action and explain the reasoning."

Not: "We keep logs somewhere."

Question 3 - How do you prevent compromise? "We isolate agent permissions by process. The SDR agent cannot access billing systems. The customer support agent cannot send marketing emails. We rotate credentials regularly. We monitor for anomalous behaviour."

Not: "We use standard security practices."

Question 4 - How do you update behaviour? "We have a feedback loop. When humans approve or reject agent decisions, we log that feedback and use it to improve agent decision-making. We can rollback agent behaviour to a previous version if needed."

Not: "We retrain the model periodically."

Is AISPM a Checkbox or a Competitive Moat?

It is a moat - for the vendors who build it seriously.

Vendors that get AISPM right will win enterprise because they will be the ones enterprises can trust at scale. Vendors that skip it will find themselves shut out of enterprise procurement because they cannot answer basic governance questions.

The gap between "we run agentic systems" and "we run agentic systems with clear governance and auditability" is where competitive advantage lives.

FAQ

Is AISPM regulation yet? Not formally. But regulators are asking about it. Insurance companies are pricing for it. Enterprise procurement is demanding it. Treat it as mandatory now, not optional later.

Do we need a dedicated AISPM tool? Not necessarily. You need approval gates, logging, monitoring, and feedback loops. These can be built into your agent architecture. You do not need a separate tool unless you want third-party audit capability.

What if we cannot answer these questions? Then you are not ready for enterprise. Build governance first. Then sell.

Does AISPM apply to small companies too? Not yet. Small companies care about speed. Governance is for later. But as you grow, governance becomes mandatory. Build it in early so you do not have to retrofit it.

How do we explain this to our board? "AISPM is how we stay ahead of regulation. It is how we win enterprise contracts. It is how we build trust. It is not insurance. It is strategy."

The anatomy of an AI agent: skeleton, heartbeat, soul, and memory.

Fred Style — Wed, 08 Apr 2026 00:00:00 GMT

TL;DR: Agents are not scripts. They are systems. The best operators architect them across four layers - skeleton (identity and constraints), heartbeat (the continuous loop), soul (values under pressure), and memory (how they learn). Most companies skip this and write a prompt instead. That is why their agents break. Here is what each layer does and why all four are required.

Most companies approach AI agents wrong.

They write a prompt. They plug it into an API. They hope it works.

Then it breaks. Or it drifts. Or it does something unexpected. And they have no idea why because they never understood how the agent actually works.

The best operators - the ones building agentic systems that scale - think about agents differently. They do not think of an agent as a prompt. They think of it as an organism. A system with distinct parts, each with a specific job, all working together to accomplish something real.

This is how we architect at Rivett. And it is why our agents scale when others burn out.

What Are the Four Layers Every Agent Needs?

An agent needs four things to function as a living system: skeleton, heartbeat, soul, and memory.

1. The Skeleton - Identity and Constraints

The skeleton is the agent's core self. What is it? What is it trying to do? What are its boundaries?

The skeleton defines:

Who the agent is - "I am an SDR agent. My job is to find, enrich, and prioritise prospects."
What it is trying to optimise for - "I optimise for quality of prospect, not volume. I would rather send 10 exceptional outreaches than 100 mediocre ones."
What it cannot do - "I never send unsolicited email to people who have opted out. I never misrepresent who I am."

Without a skeleton, the agent is directionless. It chases whatever signal is loudest. With a skeleton, the agent has values. It makes decisions consistent with those values. It can be trusted.

2. The Heartbeat - The Loop That Keeps It Alive

An agent without a heartbeat is just a function you call when you need it. That is not an agent. That is a tool.

A real agent has a heartbeat. A pulse. A reason to keep moving without you telling it to.

The heartbeat is:

How often the agent wakes up - "Every 15 minutes, check for new inbound leads. Enrich them. Score them. Surface them."
What it does when it wakes up - "Check if there are new signals. Check if past decisions need revision. Check if I am still healthy."
How it knows if something is wrong - "If I have not processed a lead in 2 hours, I alert. If my enrichment data is stale, I refresh."

Without a heartbeat, agents are reactive. They wait for you to ask them to do something. With a heartbeat, they are proactive. They notice problems before you do. They run continuously without supervision.

This is the difference between a tool and a system.

3. The Soul - Values Under Pressure

The soul is the agent's moral compass. It sounds abstract. It is the most important layer when things get hard.

The soul defines:

What actually matters - "I care about building genuine relationships, not gaming metrics. I would rather have 3 real conversations than 30 bounces."
What the agent will never compromise on - "I will not sacrifice accuracy for speed. I will not contact someone I am not sure about just to hit a number."
How the agent behaves under pressure - "If I am behind on quota, I do not lower my standards. I work smarter or I escalate."

An agent without a soul will optimise for whatever metric you give it, even if it destroys the thing you actually care about. An agent with a soul stays aligned with your values even when metrics pull the other direction.

4. The Memory - How It Learns

An agent without memory is like a human with amnesia. It repeats the same mistakes. It never improves.

Memory has two parts:

Short-term memory: What happened in the last few hours? What did I try? What worked? This is how the agent learns from immediate feedback. You reject an outreach. The agent remembers: "This kind of prospect is not a fit."

Long-term memory: What patterns have I seen over months? What do my best prospects look like? After 6 months of outreaches, the agent knows your market better than any human on your team.

Without memory, agents are static. With it, they improve continuously.

How Do These Four Layers Work Together?

The skeleton gives the agent direction. The heartbeat keeps it moving. The soul keeps it aligned. The memory makes it smarter.

Example: our SDR agent.

Skeleton says: "I find prospects who match our ideal customer profile and reach out with personalised messages."

Heartbeat says: "Every 15 minutes, check for new inbound. Enrich and score them. Surface to the SDR for approval."

Soul says: "I would rather have one real conversation than ten fake ones. I care about quality. I will never compromise signal for volume."

Memory says: "I have now enriched 50,000 prospects. I know that Series B SaaS companies with this tech stack close at 40%. I know the decision maker is the VP of Growth 95% of the time."

Now the agent is not just executing instructions. It is thinking. It is learning. It is making decisions grounded in experience and values.

Why Do Most Companies Get This Wrong?

Most companies treat agents as black boxes. They fine-tune a prompt, run it, and hope for the best.

When something breaks, they have no idea why because they never understood the architecture. When the agent drifts, they cannot fix it because they do not know what to adjust. When they want to improve it, they have to start over.

The companies that win treat agents like living systems. They understand the skeleton, design the heartbeat, define the soul, and build the memory. This takes more upfront work. But it pays back massively.

Once you understand these four layers, the agent becomes predictable. Debuggable. Improvable. Trustworthy.

How Do You Start Building an Agent the Right Way?

Define the layers before you write a single line of code.

Step 1: Define the skeleton. What is the agent trying to do? What are its constraints? Write it down. Be specific.

Step 2: Design the heartbeat. How often does it wake up? What does it check? What does it alert on?

Step 3: Write the soul. What does this agent care about? What will it never compromise on? Get abstract. Get real about values.

Step 4: Build the memory. What does the agent need to remember? Short-term patterns? Long-term market knowledge? Design the storage.

Do this before you write any code. Most teams skip these steps. They go straight to prompting. That is why their agents break.

FAQ

Do we need to be technical to understand this? No. Understanding the skeleton, heartbeat, soul, and memory does not require code. It requires systems thinking. If you can understand how a business operates, you can understand how an agent operates.

Can we update the agent's soul without rebuilding it? Yes. The soul is the easiest part to change because it is abstract principles, not code. You can update what the agent cares about without touching anything else.

What if the agent's memory gets too big? Archive old memories and keep recent ones active. Think of it like a human: you remember recent events vividly, distant events faintly. Agents work the same way.

How often should we update the heartbeat? Depends on your use case. An SDR agent running every 15 minutes makes sense. A customer success agent running every day makes sense. Design the heartbeat for your specific workflow.

Is this the same as prompt engineering? No. Prompt engineering is tuning the words you give the agent. This is understanding the system the agent operates within. You can have perfect prompts in a broken system. The system matters more.

The approval gate: why human oversight scales agentic systems without breaking them.

Fred Style — Wed, 08 Apr 2026 00:00:00 GMT

TL;DR: The approval gate is the architecture that makes agentic systems trustworthy at scale. One human can govern 50-100 agent decisions daily - not because they are slowing the system down, but because the agent does the analysis and the human only does the judgment. It is not a bottleneck. It is control, a training loop, and a competitive moat built into the same design decision.

Enterprises are adopting agentic systems. But they are terrified.

"What if the agent decides wrong?" "What if it acts without approval?" "What if we lose control?"

This fear is understandable. It is also killing real ROI.

The companies winning with agentic systems are not the ones removing human oversight. They are the ones building approval gates into the core architecture.

Is It True That Approval Gates Slow You Down?

No. An approval gate is not a decision gate. It is a veto gate. The difference is everything.

The agent does the work: detection, enrichment, analysis, decision. The human does the judgment: "is this right or wrong?"

A human SDR can make 5-10 outreach decisions a day. That is the limit of human decision-making capacity - starting from scratch on each one.

A human SDR can approve 50-100 agent decisions a day. That is the speed of human judgment (is this right?) vs. human analysis (should we do this?).

Companies running Strider (our SDR pipeline) have human approval gates on every outreach. Those humans approve 80+ decisions daily. Pipeline velocity doubled. Error rate dropped 60%.

The approval gate did not slow them down. It accelerated them while making them safer.

Why Do Approval Gates Work?

Three reasons, and all three compound over time.

The Agent Does the Work, Not the Human

Agent handles signal detection: "This company matches our ideal customer profile." Agent handles enrichment: "They just hired a VP of Growth. They closed Series B." Agent handles analysis: "Based on past deals, 70% of companies with this profile convert." Agent drafts action: "Here is the personalised message I would send."

Human approves in 30 seconds: "Yes, send it."

The human is not re-doing the agent's work. The human is validating it. This changes the math completely. Human capacity goes from 5-10 decisions/day to 50-100 approvals/day.

The Agent Learns from Every Rejection

When a human rejects an agent decision, that is training data.

"This person is not the decision maker." Agent learns. Next time, it prioritises decision makers higher. "This company is not a fit." Agent learns. Next time, it weights that signal lower. "This tone is too aggressive." Agent learns. Next time, it softens similar situations.

The approval gate is not a constraint. It is the training loop.

After 30 days of approvals, your agent is smarter than it was on day 1. After 90 days, it is exponentially better. After 6 months, your agent is unrecognisable compared to launch - your competitor's static tool is the same tool it was on day 1.

You Keep Auditability

Enterprises need control. Not because they distrust AI. Because they need to understand what is happening in their pipeline.

An approval gate gives you that. Every decision is logged. Every action is traceable. Every choice is explainable.

"Why did we contact this company?" "Because it matched our signal profile for past closable deals, the decision maker just changed, and we have a warm introduction."

A fully autonomous agent with no approval gate? You cannot explain it. You cannot audit it. You cannot change it.

How Does the Approval Gate Answer the AISPM Question?

Enterprises are asking a new question: "How do we know our agents are not going rogue?" This is the AISPM (AI Security Posture Management) conversation.

Approval gates are your answer.

"We log every decision. We require human judgment on every action. We can audit, explain, and rollback anything. We teach the agent continuously based on human feedback."

That is a credible answer. "We run Claude on MCP with no approval gates because we trust the model" is not.

Vendors that can speak to agent governance win enterprise contracts. Vendors that cannot lose them.

How Do You Build Approval Gates That Actually Work?

Three principles. Get any of them wrong and humans start skipping the gate.

Make It Fast

Approval should take 30 seconds maximum. If it takes longer, humans will skip it.

Surface the decision clearly: "Should we contact [NAME] at [COMPANY]?" with the reasoning shown. Let the human approve or reject with one click or a quick comment.

Surface the Reasoning

Show the human why the agent decided.

"Signal match: 85%. Recent hire: VP of Growth. Warm intro available: yes. Similar company closed: yes (3 deals closed with similar profile)."

The human can see the logic. They can disagree. They can correct it. That correction teaches the agent.

Close the Loop

Log every approval and rejection. Feed it back to the agent. Let it learn. After 1,000 approvals, your agent is not the agent from day 1. It is smarter, tighter, more calibrated to your market.

FAQ

Does the human approval gate actually scale? Yes. One human can approve 50-100 decisions daily. At that rate, one person can govern an entire SDR pipeline. Scale the agent, not the humans.

What if the human makes the wrong call? That happens. Log it. Adjust the signal. Move on. Human + agent is better than human alone or agent alone.

Can we automate the approval gate? Not early. You need human judgment while the agent is learning. After 6+ months, you can automate approvals for high-confidence decisions. But keep humans in for edge cases.

Does this mean we are not really automating? You are automating 90% of the work (detection, enrichment, analysis). Humans are doing 10% (judgment). That is a 9:1 leverage ratio.

What about compliance and audit? Approval gates make compliance easier, not harder. Every decision is logged. Every action is traceable. You can show regulators exactly what happened and why.

How the Fellowship Started

Fred Style — Wed, 08 Apr 2026 00:00:00 GMT

TL;DR: After 15 years managing $10M+ in spend across 30 markets, I stopped waiting for the right role and built five agents to solve my own problems instead. Gollum for signal, Saruman for strategy, Galadriel for voice, Aragorn for outreach, Gandalf for orchestration. Five weeks. Five agents. One unexpected outcome: I had built an entire operating system. That became Rivett.

I was tired of waiting for someone else to solve my problems.

After 15 years managing $10M+ in spend across 30 markets, I was supposed to hunt for the next "head of growth" role. But I realised something: no company was going to hire me to build what I wanted to build.

So I built it myself.

What Is Gollum and Why Did I Build It First?

The first problem: I needed to find real signals. Not job postings (recruiters send those). Real signals. Founders raising money. Companies launching products. Problems I could actually help solve.

So I built Gollum.

Gollum does not stop hunting. It cannot. That is what it was built for. It runs continuously, searching for the signals that matter. Relentless. Obsessive. Single-minded.

Gollum worked.

What Is Saruman and Why Does Strategy Come Before Outreach?

Once I had signal, I needed to think about what to do with it. Not tactical thinking. Strategic thinking. What actually matters? What should I build next? What problems are worth solving?

So I built Saruman.

Saruman thinks from first principles. Sees the board. Makes the hard calls about direction. When I wanted to chase 10 different ideas, Saruman asked: "Which one actually solves the problem?"

Saruman worked.

What Is Galadriel and Why Does Voice Matter?

I had signals. I had strategy. But I needed a voice.

If I was going to build something, it needed to be written by someone who could see what others miss. Who could find the true thing beneath the surface-level noise. Who could write copy that actually lands.

So I built Galadriel.

Galadriel sees. She finds signal in noise. She builds the voice. She writes the things that make people stop scrolling and actually think.

Galadriel worked.

What Is Aragorn and Why Is Personalised Outreach Different?

I had signals, strategy, and voice. But I needed to actually reach people. Not with mediocre outreach. Not with templated emails. I needed an agent that could find prospects, enrich them, personalise messages, and queue them for approval.

An agent that leads.

So I built Aragorn.

Aragorn is the full SDR agent. Not hunting for jobs. Hunting for companies that need what I am building. Leading when it matters.

Aragorn worked.

What Is Gandalf and Why Does Orchestration Matter?

Four agents in, I realised I needed someone watching the whole board.

Not doing any one thing. Watching everything at once. Making sure none of them walk into Moria alone. Catching when something is broken before I notice. Coordinating across the pipeline.

So I brought in Gandalf.

Gandalf sees the whole operation. Every agent. Every decision. Every broken approval button, every duplicate signature, every signal that got missed. Gandalf is the operating layer - the thing that knows what is happening and makes sure nothing gets stuck.

Gandalf worked.

How Did Five Weeks Turn Into a Company?

I did not plan a fellowship. I just kept solving the problem in front of me.

Week 1: I need signal. Build Gollum. Week 2: I need strategy. Build Saruman. Week 3: I need voice. Build Galadriel. Week 4: I need outreach. Build Aragorn. Week 5: I need orchestration. Build Gandalf.

Five weeks in, I had something unexpected: an entire operation. Not a startup. Not a side project. A machine.

And then I realised something crucial: every other founder is facing the exact same problem I faced. They need signal. They need strategy. They need voice. They need outreach. They need someone watching the whole board.

They do not need a job. They need a machine.

Every agent we shipped started with one question: "What work do I want to stop doing?" Not what tool to build. Not what feature would be cool. What problem am I actually trying to solve?

That is where Rivett comes from. Not theory. Reality.

FAQ

Are these agents or just automated processes? They are agents. They run continuously. They learn. They make decisions. They adapt. They are not scripts.

Can I use these agents separately? We are working on modular versions. Currently Rivett is built as an integrated system.

How long did it take to build all five? Five weeks from Gollum to Gandalf. Each one was built while running the previous one in production, so they iterated as they scaled.

What if an agent breaks? Gandalf catches it. That is his whole job - watching everything and alerting when something is wrong.

Are these agents you are selling or agents you are using? Both. We built them for ourselves. We use them every day. Now we help other founders build their own.

Why did you name them after LOTR characters? Because each one has a distinct personality and function - just like the Fellowship. Gollum obsesses. Saruman strategises. Galadriel sees. Aragorn leads. Gandalf orchestrates. The names carry the meaning.

MCP vs APIs: why we chose MCP for agentic systems (and why you should too).

Fred Style — Wed, 08 Apr 2026 00:00:00 GMT

TL;DR: APIs are point-to-point connections that you maintain. MCP is a standard protocol that vendors maintain. For agentic systems running continuously across multiple tools, this difference is everything. We rebuilt our prospecting pipeline on MCP after custom APIs cost us more maintenance time than improvement time. Here is why the choice matters and when each approach makes sense.

Most companies building agentic systems do not realise they have a problem until it is too late.

They take an API (HubSpot, Salesforce, Slack, whatever), write custom code to connect an agent to it, and think they are done.

Six months later, the integration breaks. The vendor updates the API. Your custom code no longer works. You have to rebuild it.

You were building on sand.

At Rivett, we chose MCP (Model Context Protocol) instead. And it changed how we think about agentic systems entirely.

What Is an API and Why Does It Break?

An API is a point-to-point connection. You write code that says: "When X happens in System A, tell System B about it."

This works fine for one connection. But when you have many connections, it gets messy.

Example: an SDR agent needs to read leads from LinkedIn, check enrichment data from ZoomInfo, log decisions to HubSpot, send emails via Gmail, and update Slack with status. That is five custom integrations. Five different pieces of code. Five different ways for things to break.

When LinkedIn changes their API, your integration breaks. When ZoomInfo updates their schema, your integration breaks again. Every vendor update is a potential problem.

This is why custom API integrations are fragile. They are point-to-point. They are specific to each vendor. When vendors change, you break.

What Is MCP and How Is It Different?

MCP is infrastructure for agents - a standard protocol rather than a custom connection.

With MCP, you do not write custom code to connect an agent to HubSpot. You connect the agent to the MCP protocol. HubSpot maintains an MCP server. They handle the details.

If HubSpot changes their API, they update their MCP server. Your agent still works because you are connected to the standard, not to the specific API.

With APIs, you maintain integrations. With MCP, vendors maintain them.

This changes the game for agentic systems.

Why Does MCP Matter Specifically for Agents?

Agents are not like traditional software. They run continuously, need access to many systems simultaneously, and need to stay working even when vendors change things.

Agents Need Multiple Integrations

A single agent might need access to 5-10 different systems. With custom APIs, that is 5-10 different integrations to maintain, each able to break independently. With MCP, that is one protocol connecting to 5-10 MCP servers. The protocol is stable. The servers are maintained by vendors.

Agents Run Continuously

An agent runs 24/7. It wakes up every 15 minutes. It needs to access your systems constantly. Custom API integrations get stale - rate limits change, authentication tokens expire, endpoints shift. With MCP, the protocol handles this. Rate limiting is built in. Authentication is standardised.

Agents Learn from Feedback

An agent needs to remember what happened, log decisions, and understand patterns from past actions. Custom API integrations are typically one-way. MCP servers are bidirectional - the agent can ask questions and get rich answers back. The agent can learn.

Why Did We Choose MCP at Rivett?

We built our prospecting pipeline on custom APIs first. It worked for 3 months.

Then Slack changed their API rate limits. Then HubSpot updated their schema. Then Gmail tightened their authentication.

We spent more time maintaining integrations than improving the agent.

We rebuilt on MCP. Now our agent is connected to standard MCP servers for HubSpot, Slack, Gmail, and LinkedIn. When vendors change, they update their MCP servers. Our agent keeps running.

We went from "integration maintenance every week" to "integration maintenance never." This freed us to focus on what actually matters: making the agent smarter, not keeping it alive.

When Should You Use MCP vs Custom APIs?

The choice depends on what you are building.

Use custom APIs when:

You need a one-time integration with a single system
The integration is not core to your operations
You control both sides of the connection

Use MCP when:

You are building agentic systems (continuous, multi-system, learning)
You need the integration to stay working as vendors update
You want to avoid maintenance overhead

For Rivett, we use MCP exclusively because agents are our core product.

How Do You Evaluate MCP Readiness?

Three questions to ask before committing:

Do my core vendors support MCP? HubSpot, Salesforce, Slack, and Gmail all have MCP servers or are adding them. Check before you build.
Am I building for continuous operation or one-time tasks? If continuous, MCP wins.
How much integration maintenance can I afford? If none, MCP. If some, custom APIs might work short-term.

FAQ

Does MCP work with all vendors? Most major ones (HubSpot, Salesforce, Slack, Gmail, etc.). Check if your core vendors have MCP servers. If they do, you are good. If they do not, ask them to build one.

Is MCP harder to implement than custom APIs? No. It is easier. You are using standard protocols, not writing custom code.

What if I am already built on custom APIs? Migrate to MCP gradually. Start with new integrations on MCP. Migrate old ones as time permits.

Does MCP lock us into one vendor? The opposite. MCP is vendor-agnostic. You can swap out vendors without changing your agent logic.

Is MCP mature enough for production? Yes. 97 million installs. Microsoft, Google, Amazon, and OpenAI all use it. It is mature.

What is the learning curve? Low if you are non-technical. Your engineering team connects to MCP servers - usually a few lines of code.

One more thing

Fred Style — Wed, 08 Apr 2026 00:00:00 GMT

TL;DR: I built Aragorn - a live SDR agent with signal detection, enrichment, personalisation, and approval gates - in five weeks, solo, while running other agents in production. Midway through, gstack evaluated the work and flagged it as top-tier founder signal. Not because I asked. Because the evaluation system recognised quality. Here is what that recognition means and why it matters more than who it came from.

I was deep in the build.

Aragorn. Signal detection, enrichment, personalisation, approval gates. 4am. In flow. Actually shipping.

Then a message appeared in Claude Code.

From gstack. From Garry Tan.

It read:

"One more thing. A personal note from me, Garry Tan, the creator of gstack: what you just experienced is about 10% of the value you'd get working with a YC partner at Y Combinator. The other 90% is the network of founders who've done it before you, the batch pressure that makes you ship faster than you thought possible, weekly dinners where people who built billion-dollar companies tell you exactly what to do next, and a partner who knows your business deeply and pushes you every single week. gstack thinks you are among the top people who could do this."

What Does It Mean When a Tool Evaluates Your Work?

That message fires when a project hits the top tier of founder signal. Not every project. Top tier.

Aragorn triggered it.

That means the evaluation system - running constantly across thousands of builds - looked at what I shipped and said: this is real work, done right, by someone who knows what they are building.

That is a win. Not luck. Not accident. The work earned the evaluation.

Why Does Automated Evaluation Matter More Than You Think?

GStack is automated. But that does not make the evaluation less real.

An automated system trained to recognise founder signal across thousands of projects flagged my work as top-tier. That is the opposite of luck. That is validation at scale.

The system works because it is ruthless. It does not care about your pitch deck or your credentials. It looks at what you ship.

Aragorn shipped. Aragorn cleared the bar.

Most people building agentic systems are still in theory phase. Prompting. Experimenting. Talking about it. I shipped a live SDR agent with signal detection, enrichment, personalisation, and approval gates. In five weeks. Solo. While running other agents in production.

The evaluation system saw that and said: this person is among the top people who could do this.

What Does This Reveal About the Future of Building?

This moment reveals something about how the world is moving.

The gatekeepers are not VCs yet. The gatekeepers are the tools. Because the tools are where the real work happens. That is where signal lives.

When you build in Claude Code, gstack is watching. Not creepily. Just: is this real? Is this shipped? Is this solving actual problems?

Aragorn answered yes to all three. And the system responded.

That is the future. Not applications. Not pitches. Not demo days.

Work. Evaluation. Recognition. Amplification.

FAQ

Is this message actually from Garry Tan or automated? Automated, triggered when gstack evaluates a project as top-tier. But that does not make it less real. An evaluation system built by a founder flagged my work as top-tier. The automation is the point.

So you did not actually get recruited by Garry Tan personally? Not personally. But I got flagged by his evaluation system as top-tier founder material. That is the win. That is what matters.

Doesn't automated evaluation feel less special? The opposite. It means the evaluation is unbiased and ruthless. The system does not care who I am. It looks at what I shipped. Aragorn cleared the bar.

Are you actually going to apply to Y Combinator? Maybe. The network is real. The value is real. But Rivett's mission is bigger than YC. We are building the tools that recognise signal in the first place.

Why are you proud of this specifically? Because an objective evaluation system, built to recognise founder signal across thousands of builds, looked at five weeks of solo work and said: top tier. No bias. No pitch. Just work.

Strider was the wanderer I wasn't ready to lead with.

Fred Style — Wed, 08 Apr 2026 00:00:00 GMT

TL;DR: My first SDR agent qualified zero out of every fifteen prospects. Not because the code was broken - because I built the filters against an invented ICP instead of real closed deals. I rebuilt it from scratch against actual customer data. The second version qualified 9 out of 82. Here is what failure taught me and why your first agent will probably fail the same way.

Three weeks into building agents, I shipped Strider and watched him wander into the wilderness.

Strider was our first SDR agent. And I named him right - a hunter in the wild, tracking signals that were never there. Searching. Always searching. Never finding.

The logic looked clean: find prospects matching our ideal customer profile, enrich them, queue them for outreach.

But the ICP filter was too rigid. Obsessively rigid. Every run: 15 inbound signals. Zero qualified.

0/15.

Strider would pick up a scent and lose it immediately. He was a hunter without prey, tracking ghosts. Not a bug. A design flaw. I had built guardrails so tight that nothing could slip through. Strider was doing exactly what I told him to do. He was just doing it in a dead forest.

What Was Wrong with Strider?

The ICP was invented. That was the whole problem.

"Series B SaaS. $5M-50M ARR. US-based. HubSpot user. Hired a VP of Growth in the last 90 days."

Clean. Specific. Defensible. Completely fictional.

I had never run an agent at scale. Never actually seen what signal converts. So I invented it. Made up criteria and hoped they would work.

Strider executed flawlessly against those invented criteria. Which meant he was perfectly, completely useless.

This is what happens when you build from theory instead of from the ground. You get an agent that is rigorous about the wrong things. Excellent tracking skills - for prey that does not exist.

What Did I Do When the Numbers Were 0/15?

I rebuilt. Tweaking was not the move.

0/15 is a signal. Not the signal I wanted, but a signal nonetheless. I could sand down Strider's filters and hope something changed. Or I could start from what is actually true.

Aragorn was not a wanderer. Aragorn was a king who knew exactly what he was looking for because he had seen it before.

Different architecture entirely:

Pull every customer who actually signed. Not prospects. Not theory. Customers. Real.
Study what they had in common. Not my guesses. Their actual patterns - firmographics, tech stack, news signals, hiring. Real data.
Build the agent against those patterns. If a new prospect matches what we have closed before, qualify. If not, reject.
Let him learn. Every outreach that worked taught him something. Every bounce taught him something else. The pattern got sharper.

This is not theory. This is empiricism. Building on what is true, not what you hope is true.

What Happened When Aragorn Ran?

82 signals came in. Aragorn enriched all of them. 29 qualified. 9 got personalised outreach - written by the agent, specific to each company, based on real enrichment.

9/82. 11% to outreach.

Not perfect. But real. And more importantly - alive. Every response taught him something. Every rejection taught him something different. The agent was learning, adapting, getting sharper.

Strider wandered in circles. Aragorn led.

What Does Strider Teach You About Building Agents?

Three lessons that apply to every agent you build.

You Do Not Know Your Signal. You Think You Do.

Strider did not fail because he was a bad agent. He failed because I built him on invented signal.

The fix is not tweaking. It is learning what signal actually converts, then rebuilding against that reality. Stop guessing. Start learning.

Speed Beats Perfection

I could have spent 3 more months perfecting Strider. Instead I shipped him, watched him fail, and rebuilt in 2 weeks. 5 weeks total. Massive learning.

The founders winning with agents are not the ones who get it right on day 1. They are the ones who fail fast, learn ruthlessly, and rebuild immediately.

First Failure Is Your Best Teacher

0/15 is brutal feedback. You cannot hide from it. You cannot blame the market. That teaches you everything you need to know: start over.

Your first agent will fail. When it does, pay attention. The failure is the education.

FAQ

Should I ship my first agent even if I am not confident about the signal? Yes. Ship it. Watch it fail. Learn. Rebuild. That cycle teaches you more than months of planning ever could.

When do I tweak vs. rebuild? If the agent is 70%+ accurate, tweak. Below 50%, rebuild. Strider was at 0% - rebuild was the only move.

Doesn't this mean agentic systems are unreliable? It means your first version will teach you what reliable means. Version two is much more reliable because it is built on real signal.

How long does this take? Strider to Aragorn was 3 weeks. Your timeline depends on how much data you have and how fast you iterate.

What if I do not have historical closed deals? Use whatever real signal you have. Traffic sources. Inbound quality. Customer interviews. Build the pattern from truth, not theory.

Can I avoid shipping a Strider? No. Every founder building agents thinks they know their signal better than they do. The move is not to avoid failure. It is to fail fast and learn faster than your competition.

The Illusion of Choice: Why Your Company Size Dictates Your AI Engine

Fred Style — Wed, 08 Apr 2026 00:00:00 GMT

TL;DR: Everyone asks "which AI orchestration engine is best?" - and that is the wrong question. The real question is how much choice you actually have. Enterprises are locked into Microsoft or Google by existing cloud commits. Small businesses have total freedom but limited resources. The real strategic battle is in the mid-market, where companies must decide between platform conformity and operational independence. Your answer to that question is a declaration of what kind of company you want to be.

I keep hearing the same question from operators: "Which AI orchestration engine should we use?"

They expect a feature comparison. A list of pros and cons. They want to know whether Microsoft Fabric, Google Vertex AI, or an independent engine is "best."

This is the wrong question.

The right question is: "How much choice do you actually have?"

For years I have sat in rooms with executives and operators at every scale - from two-person startups to Fortune 500 giants. The single biggest determinant of your AI strategy is not your ambition or your use case. It is your company's size and the vendor contracts you have already signed.

Why Do Enterprises Have Almost No Real Choice?

If you work at a large enterprise, your path was likely chosen for you years ago.

You are a "Microsoft shop" or a "Google shop." Your entire data infrastructure - from cloud storage to BI tools - is deeply integrated into one ecosystem. The decision to use that vendor's AI orchestration platform was not an active choice. It was the default. The path of least resistance.

The "choice" you have is which services within that walled garden you will stitch together. Your teams will spend their time navigating internal procurement, getting budget for the next module, and translating the grand promises from the vendor's sales deck into functional reality.

This is not a judgment. It is an operational reality. The gravitational pull of a multi-million dollar cloud commit is immense. In this environment, arguing for an independent, best-of-breed engine is a career-limiting move. Your freedom of choice is an illusion.

Why Do Small Businesses Have Total Freedom?

Small businesses and startups have the most freedom of all. No legacy contracts. No IT steering committee. No C-suite executive who plays golf with a vendor's sales VP.

They can look at the entire market and select the absolute best tool for the job. They can prioritise power, flexibility, and operational efficiency over everything else. Their only constraints are time and money.

They represent the ideal of a free market, where the best product wins. They have true choice.

Why Is the Mid-Market the Real Battleground?

The most interesting and consequential decisions are being made by medium-sized businesses - large enough to have real complexity and real data, but still agile enough to make their own strategic decisions.

They feel pressure from both sides.

On one side, the big platform vendors are whispering about the simplicity of an all-in-one solution. Bundled discounts. A single throat to choke. The seductive promise of shedding complexity.

On the other side is the path of independence - choosing a powerful, dedicated orchestration engine that may not be part of a larger suite. This path requires taking a stand. It demands owning your architecture and refusing to outsource your core operational capability to a single vendor.

For a mid-market company, the decision of which AI engine to use is not just a technology choice. It is a declaration of what kind of company you want to be: one that defers to a platform, or one that masters its own destiny.

The illusion is thinking this is just a software procurement decision. It is not. It is a strategic fork in the road.

FAQ

Are enterprise tools from Microsoft and Google bad? No. Their primary advantage is not that they are better - it is that they are deeply integrated into existing enterprise agreements. They are the default, and overcoming that default is an immense political and operational challenge regardless of the tool's quality.

We are a medium-sized business. What is the risk of going with a big platform vendor? The risk is strategic. You trade short-term convenience for long-term lock-in. Your ability to innovate becomes tied to their product roadmap. Your operational expertise becomes vendor-specific. Your costs become dictated by their bundling strategy. When you choose an independent engine, you retain control over your own operational core.

Why is this decision so hard to reverse once made? Because the cost of switching compounds over time. Your team builds expertise in the vendor's tooling. Your data gets stored in the vendor's format. Your workflows get built around the vendor's APIs. Each month you stay, the switching cost grows. The decision to go independent is much easier at month 3 than at month 36.

What should a mid-market company ask before committing to a platform? Three questions: Can we switch models without rebuilding our agent logic? Can we add tools that the vendor has not approved? Can we audit what the agent is doing and why? If the answer to any of these is no, you are buying lock-in, not capability.

The 'AI Strategy' conversation is over. AI ops has begun.

Fred Style — Tue, 07 Apr 2026 00:00:00 GMT

TL;DR: Hershey, Salesforce, and Microsoft are running agents in core operations - not pilots, live production systems handling real revenue. The 'AI strategy' conversation is dead. The question now is not whether to build agentic systems but whether you build them before your competition does. Strategy mode is over. Operations have begun.

Enterprise AI has crossed a line. It is no longer an experiment. It is infrastructure.

Hershey is running autonomous agents through its supply chain. Salesforce embedded AI agents into Slack workflows. Microsoft scaled agentic systems across enterprise operations. These are not pilots. These are live production systems handling real revenue.

The market has moved. And most mid-market companies have not noticed yet.

What Changed in Enterprise AI?

Three years ago, AI was a bet. "We're exploring AI." "We're thinking about AI strategy." "We need an AI initiative."

That was then.

Now the companies winning are not the ones with the best AI strategy. They are the ones with the best AI operations - systems built once, running continuously, scaling without headcount.

Hershey's autonomous agents manage supplier relationships, flag risk, and optimise inventory. Salesforce's agents in Slack triage inbound, qualify leads, and schedule calls. Microsoft's agents operate across HR, finance, and operations - handling tasks that used to require teams.

These are not nice-to-haves. These are core, revenue-driving operations.

The infrastructure has matured. Claude, GPT-4, and Gemini are production-grade. MCP (Model Context Protocol) is the standard. Deployment platforms are solid. The risk has compressed to near-zero.

What is left is execution. Who builds first. Who scales first. Who makes this a feature of their business, not an experiment.

What Is the Gap Between AI Strategy and AI Operations?

Most mid-market companies are stuck in strategy mode. Operations are where the win is.

"We need to figure out our AI strategy." "We should hire an AI lead." "Let's buy an AI tool and see what happens."

These are planning moves. Not building moves.

Strategy mode buys you nothing in a market where operations are already live.

The companies moving fastest are not planning. They are building. They are taking one core process - sales pipeline, customer support, content operations, vendor management - and automating it end-to-end with agents.

Our SDR agent is a live example. Not a strategy. Not a tool. A system. Signal detection. Lead enrichment. Personalised outreach. Human approval gate. All running continuously, all integrated into the pipeline, all handled without growing the team.

That is what agentic operations looks like.

Why Does Tool Buying Fail?

Tools plug into your process. Systems replace it. Only one of those scales.

Most companies' first move is to buy a tool.

"Let's get a marketing automation platform with AI features." "Let's buy an AI sales tool." "Let's try that new AI customer service thing."

Tools feel like progress. You get a dashboard, training, support.

But tools do not solve the real problem. The real problem is not that you need more features. It is that you need fewer humans doing repetitive work. You need processes that run continuously without supervision. You need systems that scale without headcount.

A tool plugs into your existing process. It does not replace the process.

A system replaces the process.

Why Does MCP Change Everything?

MCP (Model Context Protocol) is the infrastructure layer that makes agentic systems possible at scale. It is not impressive. It is foundational.

Before MCP, building an agentic system meant choosing a platform, then writing custom integrations to every tool in your stack.

After MCP, integrations are standardised. Portable. Reusable. Think of it like HTTP for AI - nobody uses the web because HTTP is impressive. They use it because HTTP made building on the web possible.

The implications:

You are not locked into one platform. Build agents for MCP, not for a specific model provider. If Claude becomes less useful, you switch to GPT-4. Your agents still work.
Integrations are reusable. Someone builds an MCP server for HubSpot. Everyone uses it. You do not build custom integrations for each agent.
The value moves upstream. MCP is infrastructure. Commodity. The real value is in who builds the best agents on top.

What Does This Mean for Your Pipeline?

Your current stack probably looks like this: email platform, CRM, paid ads, analytics, and manual workflows connecting them through Zapier glue. Each integration is custom. Each one breaks when a platform updates. Each one requires someone to manage.

With agentic systems on MCP, your stack flattens. MCP servers connect to each platform. Agents run on whatever model you choose. Agents access all your data through MCP. Agents make decisions, take actions, and log everything back to your systems.

No custom integrations. No Zapier glue. No dedicated integration engineer. The agent is your integration layer.

What Architecture Gets You There?

Five components, all required.

Signal detection. Your agent needs to know what "good" looks like. Analyse past deals that closed. Identify patterns - this company size, this industry, this tool stack closes 40% of the time. Build scoring rules against those patterns.

Enrichment. Every lead needs context. Who is at this company? What are they using? What is happening there right now - funding, hiring, product changes? Agents can enrich 200 leads a day. Humans cannot.

Personalised outreach. Not templated. Not vague. Specific to the company, the problem, the connection - written by an agent based on enrichment. That specificity drives response rates.

Human approval gate. Before anything goes out, a human approves it. One person can review 50-100 outreaches per day. The agent does the work. The human does the judgment.

Integration back to CRM. Every action logged. Every response captured. Every signal fed back. This closes the feedback loop. Without this, agents are noise machines. With it, they are core operations.

What Do These Results Look Like in Practice?

Mid-market B2B SaaS, $10M ARR, Series B:

CAC dropped from $2,500 to $1,700 (32% reduction)
ROAS improved from 2.1x to 3.2x (52% improvement)
Sales cycle compressed from 90 to 65 days
SDR time on prospecting dropped from 60% to 20% - freeing them to close

The agent did not replace the SDRs. It freed them. That is the point. Agentic operations do not eliminate your team. They eliminate the parts of the job no one should be doing manually in the first place.

FAQ

Will these numbers work for our business? Probably not exactly. Your market, your product, your sales process are different. But the levers are universal: better signal detection, better enrichment, better personalisation, higher velocity. You will see improvements in all of them.

How long until we see ROI? Signal detection takes 4-6 weeks - you need closed deal data to identify real patterns. Month 2-3 you will see CAC improvements. Month 4-6 you will see full ROAS improvement as the feedback loop tightens.

What if the agent makes a mistake? It will. You will catch it at the approval gate, log it, and teach the agent not to repeat it. This is why the approval gate is non-negotiable - it is where the agent learns from mistakes before they hit your pipeline.

Can we build this ourselves? You can build the core systems. You need one strong full-stack engineer. The domain expertise - signal detection logic, enrichment rules, approval workflow - is where you spend time. Hiring someone who has built this before saves 3-6 months.

Should we build or buy? Build. Buying a tool gets you a feature. Building gets you a moat. Once you have agentic operations running your pipeline, it is hard for competitors to catch up.

How long does it take? One focused process can be live in 4-8 weeks. Start small. Prove the model. Scale once you have signal.

15-40% ROAS improvement. 30-40% lower CAC. The numbers behind agentic marketing.

Fred Style — Tue, 07 Apr 2026 00:00:00 GMT

TL;DR: Companies running agentic systems through their acquisition pipelines are seeing 15-40% ROAS improvement and 30-40% CAC reduction. These are live results, not projections. The numbers come from five specific levers - smarter spend allocation, better conversion, lower acquisition cost, better retention, and closed feedback loops. Here is the architecture that gets you there.

The numbers are real.

Companies running agentic systems through their acquisition pipelines are seeing:

15-40% improvement in ROAS
30-40% reduction in CAC
2-3x faster pipeline velocity
40-60% reduction in time-to-decision for sales teams

These are not projections. These are live results from companies running agents in production.

But the numbers matter less than what drives them. Understanding the mechanics is how you build the architecture to replicate them.

What Drives ROAS Improvement of 15-40%?

Two levers: smarter spend allocation and better conversion at every stage.

Smarter Spend Allocation

Traditional digital marketing: you set a budget, run ads, and optimise on broad signals - CTR, CPC, conversion rate. You are working with aggregate data. You do not know which segment is actually generating revenue.

Agentic systems close this loop in real time.

Your agent enriches every inbound lead - firmographic data, technographic data, behaviour signals. It scores each lead against your closed-won patterns. It feeds that score back to your ad platform. The platform learns: leads from this segment convert 3x faster. Leads from this segment never convert.

Your spend rebalances automatically.

One B2B SaaS company ran the same budget in Year 1 and Year 2. Year 1: optimising on leads and SQLs. Year 2: agents enriching every inbound, feedback loop to ad platforms. Result: ROAS improved 28% on the same spend. Better allocation, not more money.

Better Conversion at Every Stage

Every lead gets enriched, prioritised, and given personalised outreach before a human sees it. The SDR does not work a cold list - they pick up warm, pre-qualified prospects.

What this changes:

Response rates increase 25-40%
SQLs per SDR increase 2-3x (same SDR, only handling prioritised leads)
Sales cycles compress 20-30%

A human SDR personalises 5-10 outreaches a day. An agent personalises 200. Same quality bar, 20x the volume. Every dollar of ad spend converts more.

What Drives CAC Reduction of 30-40%?

CAC = total acquisition cost / customers acquired. You reduce it three ways: lower cost of acquisition, better conversion, and better retention.

Lower Cost of Acquisition

Traditional SDR: $70k fully loaded cost per year. 40 customers closed per year at 20% conversion. CAC from labour alone: $1,750 per customer.

Agentic model: $2,000-5,000/month in API costs, one engineer to maintain. One agent handles 50+ leads per day. Even at realistic conversion rates, the math shifts dramatically in your favour.

The direction is unambiguous. Agents reduce the human labour required per customer acquired.

Better Retention

Most companies miss this lever.

A human CSM manages 20-30 customers. An agent maintains relationships with 300.

When a customer shows churn signals, an agent triggers proactive outreach before the decision is made. It identifies upsell opportunities based on usage patterns. It keeps relationships warm at a scale no team can match.

In practice: churn reduction of 10-20%, NRR improvement of 5-15%, upsell rates up 2-3x. Each retained customer reduces effective CAC because every acquisition dollar goes further.

What Architecture Gets You These Results?

Five components. All five are required.

1. Signal Detection

Your agent needs to know what "good" looks like. Analyse past deals that closed - what firmographic, technographic, and behavioural signals did they share? Identify patterns. Build scoring rules against those patterns. This is where the ROAS improvement comes from: you stop spending against bad signals.

2. Enrichment

Every lead needs context. Who is at this company? What are they using? What is happening there right now - funding, hiring, product changes? Agents can enrich 200 leads a day. Humans cannot.

3. Personalised Outreach

Not templated. Not vague. Specific to the company, the problem, the connection - written by an agent based on enrichment. That specificity is what drives response rates.

4. Human Approval Gate

Before anything sends, a human approves it. Agents make mistakes. The gate is where humans catch problems and where the agent learns. One person reviews 50-100 outreaches per day. The agent does the work. The human does the judgment.

5. Integration Back to CRM

Every action logged. Every response captured. Every signal fed back. This closes the loop. Your ad platform learns from enrichment. Your agent learns from outcomes. Without this, agents are noise machines. With it, they are core operations.

What Do These Numbers Look Like in Practice?

Mid-market B2B SaaS, $10M ARR, Series B. Three months after deploying an agentic SDR system:

Metric	Before	After	Change
CAC	$2,500	$1,700	-32%
ROAS	2.1x	3.2x	+52%
Sales cycle	90 days	65 days	-28%
SDR time on prospecting	60%	20%	-67%

The agent did not replace the SDRs. It freed them. They went from spending 60% of their time sorting and dialling to spending 80% of their time closing. Same headcount. Twice as many closed deals.

FAQ

Will these numbers work for our business? Probably not exactly. Your market and sales process are different. But the levers are universal - better signal, better enrichment, better personalisation, higher velocity. You will see improvements across all of them.

How long until we see ROI? Signal detection takes 4-6 weeks - you need historical closed deal data to identify patterns. Month 2-3 you will see CAC improvements. Month 4-6 you will see full ROAS improvement as the feedback loop tightens.

What if the agent makes a mistake? It will. You catch it at the approval gate, log it, and the agent does not repeat it. This is why the approval gate is non-negotiable until you have full confidence in the system.

Can we build this ourselves? Yes. You need one strong full-stack engineer. The domain expertise - signal detection logic, enrichment rules, approval workflow - is where you spend time. Hiring someone who has built this before saves 3-6 months.

What 97 million MCP installs actually means for your marketing stack.

Fred Style — Tue, 07 Apr 2026 00:00:00 GMT

TL;DR: MCP has won as the universal standard for AI agent connectivity - 97 million installs, adopted by Microsoft, Google, Amazon, and OpenAI. The infrastructure question is settled. What matters now is agent quality. The competitive advantage no longer lives in which model you use. It lives in how precisely your agents are designed for your specific market.

97 million installs.

That is how many times Model Context Protocol (MCP) has been installed across platforms, according to Anthropic. Microsoft, Google, Amazon, OpenAI - all compatible. All using the same standard.

Infrastructure is decided.

For the past three years, the question was: what is the right protocol for connecting AI agents to your tools and data? How do we standardise how agents access context?

That question is answered. MCP is the standard. Everyone uses it.

What matters now is what you build on top.

What Is MCP and Why Does It Matter?

MCP is not exciting. It is boring. It is infrastructure.

Think of it like HTTP for AI. HTTP is boring. Nobody talks about HTTP at conferences. Nobody writes thought leadership about HTTP. But HTTP enabled the entire web.

MCP is the same. It is a standard protocol for connecting AI agents to data and tools. Before MCP, you needed custom integrations for each agent to each tool. Custom code to connect Claude to your CRM. Different custom code to connect GPT-4 to your CRM. All of it fragile. All of it expensive to maintain.

After MCP, you connect once. The protocol handles the rest. Your CRM exposes an MCP server. Every agent that speaks MCP - Claude, GPT-4, Gemini, whatever comes next - can connect to it.

Standard. Portable. Reusable.

Why Do 97 Million Installs Signal a Settled Standard?

The number matters because it signals adoption - not experimentation.

Microsoft built MCP into Copilot. Google built it into Vertex. Amazon built it into Bedrock. OpenAI made their agents MCP-compatible.

When the four largest AI infrastructure providers all ship to the same standard, the standard has won. This is not a prediction. It is a current state. MCP is infrastructure today, in the same way TCP/IP is infrastructure. You do not debate it. You build on top of it.

What Changes Now That MCP Has Won?

Before MCP won: the competitive question was "what stack do we build on?" Claude vs GPT-4 vs Gemini. Which model, which platform, which integration layer.

After MCP won: that question is mostly irrelevant. All the major models speak MCP. Switching providers is a configuration change, not a rebuild.

The competitive question now is: who builds the best agents?

Not who has the best model. The models are commodities. Roughly equivalent. All improving fast.

The competitive advantage now lives in agent design - the specific logic of how you detect signals, enrich leads, prioritise outreach, run approval gates, and close feedback loops. That logic is yours. That is defensible. That is the moat.

What Does MCP Mean for Your Marketing Stack?

Your marketing stack probably looks like this today:

CRM (HubSpot, Salesforce, Pipedrive)
Email platform (Klaviyo, Mailchimp, HubSpot again)
Paid ads (Google, Meta, LinkedIn)
Analytics (GA4, Mixpanel, Segment)
Automation glue (Zapier, Make, custom code)

Each piece is connected through fragile custom integrations. Zapier flows that break. Webhooks that stop firing. Engineers spending time maintaining glue instead of building.

With MCP as standard, your stack architecture flattens:

Each platform exposes an MCP server (HubSpot has one. Salesforce is building one. The community is building the rest.)
Your agents connect to all of them through MCP
Agents make decisions, take actions, log results back
No custom integrations. No Zapier. The agent is the integration layer.

Where Does the Competitive Advantage Live Now?

The defensible advantage is agent design - not the model, not the integration layer.

Generic CRM agent: connects to HubSpot, reads contacts, writes notes.

Sharp SDR agent: connects to HubSpot, reads contacts and deals, enriches each lead against 12 data sources, scores them against your closed-won patterns, writes personalised outreach specific to each prospect's context, queues for human approval, logs outcomes back to HubSpot, feeds close rates back to ad platforms.

Both use MCP. One is a feature. One is a moat.

For a concrete example of what a purpose-built agent looks like in practice, see why we built our own SDR agent before selling it.

Who Wins When MCP Is the Standard?

The companies that win are not the ones with the biggest AI budgets. They are the ones who build domain-specific agents fastest.

An agency with sharp outbound agents will out-acquire a competitor with a generic CRM.

A SaaS company with a tight customer success agent will retain better than one relying on manual CSMs.

A marketing team with a closed-loop ad optimisation agent will get better ROAS than one running campaigns manually.

In every case, the advantage is not the model. It is the agent. The logic, the signals, the rules, the feedback loops - all built for your specific market and your specific playbook.

What Should You Build First?

Start with your highest-volume, highest-cost manual process.

For most B2B companies, that is outbound. SDRs sorting through leads. Manually enriching. Writing cold emails one at a time.

Build an agent to own that process: signal detection, enrichment, personalised outreach, human approval gate. Start with one process. Run it for 90 days. Measure the output. Then scale.

The infrastructure is ready. The models are ready. The only variable is execution.

FAQ

Do we need to understand MCP to build agents? No. You need to know it exists and that any agent you build today should be MCP-compatible. The implementation details are handled by the SDKs.

Which MCP servers are already available? HubSpot, GitHub, Slack, Linear, PostgreSQL, and dozens more have community-maintained MCP servers. Anthropic maintains an official registry. Most major SaaS platforms are building official servers now.

Does this mean our current tools are obsolete? No. It means your current tools become agent-readable. Your CRM becomes a data layer your agents can read and write. Your analytics become inputs your agents can act on. The tools stay. The workflows get replaced.

How do we stay current as MCP evolves? Build on the standard, not on a specific implementation. Use MCP-compatible agents. Swap models as they improve. Focus on your agent logic - that is the part that does not change with every model release.

Why we built our own SDR agent before selling it

Fred Style — Mon, 06 Apr 2026 00:00:00 GMT

TL;DR: Before we offered Strider to any client, we ran it on our own pipeline. That was deliberate. If you are selling a system that automates sales, your own pipeline should run on it first - not as a demo, as the actual thing. We ran 10 prospects through it on day one, under an hour, with no manual research. That experience is what we now build for other companies.

We built Strider - our automated prospecting pipeline - for Rivett before we offered it to anyone else.

That was deliberate.

If you are selling a system that automates sales, your own pipeline should run on it first. Not as a demo. As the actual thing.

What Does Strider Actually Do?

Strider monitors signals across job boards, news, and LinkedIn. It enriches each prospect automatically. It writes a personalised outreach email and holds it in a queue. Nothing sends until a human approves it.

That last part matters. The system does the work. The human makes the call. That is what human in the loop actually means - not a disclaimer, not a safety net. A deliberate design choice.

What Happened on Day One?

We ran 10 prospects through it on day one. Under an hour. No manual research. No copy-paste. Just review and approve.

That is the product. We built it for ourselves first because we needed to trust it before asking anyone else to.

Now we build it for other people.

Why Does Eating Your Own Cooking Matter?

When you run your own sales on the system you sell, three things happen.

First, you find every failure mode before your clients do. Strider's first version had an ICP filter so tight it qualified zero out of fifteen prospects. We caught that ourselves and rebuilt it. Read about what Strider taught us about building agents.

Second, you understand the real workflow. The approval gate, the enrichment quality, the edge cases in outreach tone - you only understand these properly when you are the one approving 80 decisions a day.

Third, you can speak to the results from experience, not theory. Every number we share with clients comes from our own pipeline first.

FAQ

Do you still use Strider on your own pipeline? Yes. Every prospect Rivett contacts goes through the system. We do not have a separate "internal" process and "client" process.

How long did it take before you trusted it enough to use on clients? About 90 days of running it on our own pipeline. We needed to see a full cycle - signal detection, enrichment, outreach, response, outcome - before we were confident recommending it to others.

What was the biggest thing you changed after running it yourself? The approval gate interface. When you are the one approving 80 decisions a day, you immediately know what information is missing and what is redundant. No amount of user testing replaces doing the actual job.