Good morning.
You spent months building the machine that wins a customer. Ads, funnel, sales calls, follow-up.
Then they pay, and the whole thing stops, and what happens next depends on whoever remembers to send the welcome email.
Today's issue is an agent that runs those fourteen days on a schedule, with every touchpoint drafted and four points where it stops and hands you the wheel.
— Sam
IN TODAY’S ISSUE 🤖
Why churn is decided in week one
The three platform paths, ranked
The Orchestrated Sequence, and why time is the spine
Four handoff points the agent never crosses
Seven build steps, every prompt inside
The first fourteen days by business type
Handing the arc to a team without losing it
A stall detector for customers who go dark
Let’s get into it.
Why Build The Onboarding Agent
An agency owner I work with lost a $4,000-a-month retainer in April and told me the client "just wasn't a fit."
I asked what happened in the first two weeks. He walked me through it: contract signed on a Tuesday, welcome email that Friday, kickoff call scheduled for the following Wednesday, then rescheduled twice because his team was heads-down on a launch. First real deliverable reached the client nineteen days after the money did.
The client cancelled in month four. He wrote it up as a fit problem.
It was an onboarding problem, and he had no way to see it, because nothing in his business was watching those fourteen days. The proposal had a process. The sales call had a process. The moment the invoice cleared, the customer walked off the edge of the system.
That's the pattern in nearly every business at this size. You can describe your funnel step by step all the way to the close. Ask what happens in the two weeks after and you get a shrug and a Google Doc somebody made once.
It matters more than it looks, because the first fourteen days set the reference point for everything after.
A customer who gets a real result in week one reads a later mistake as an exception. A customer who waited nineteen days for anything reads the same mistake as confirmation. Same error, opposite outcome, decided before your team ever made it.
Three reasons to build this one:
It protects revenue you already paid to acquire. A cancellation in month four means you paid full acquisition cost for a third of the lifetime value. Nothing else returns that much for that little work.
It runs on a clock instead of on your attention. Onboarding fails in a busy week, every time. An agent that wakes up on day three whether or not anyone remembered is the whole point.
It writes down a process that lives in your head. Most of us onboard well when we're paying attention and badly when we aren't. Putting the arc in a file makes the good version repeatable by anyone on the team.
The Digital Employee frame applies cleanly here. An agent that runs a defined arc, prepares each touchpoint, and raises its hand at the moments a human has to step in is a customer success hire sitting on your bench.
You manage it the way you'd manage one:
A clear job description (the system prompt)
A written definition of the arc, stage by stage, and what "on track" means at each point (the context file)
A drawn line between what it does alone and what it brings to you (it prepares and drafts; you decide and send)
A review of the calls it got wrong, fed back in (the tune loop)
It never emails a customer on its own. It prepares, it drafts, it flags, and you make the final decision.
Also:
It doesn’t matter if your business is B2B or B2C, whether it’s agency or ecommerce, creator or freelancer, consultant or whatever else…
Every business has an “onboarding” process, whether you realize this or not.
If you think you don’t, that’s the surest sign that you do.
What your customers experience in the first 2-ish weeks of buying from you makes all the difference in the world.
Don’t waste this opportunity to secure the money bags.
The Platform Decision (Read It Once, Decide, Move On)
Three serious paths. Pick one and run it thirty days before considering another.
Path | Best for | What you get | What to know |
|---|---|---|---|
Claude Code in Cowork mode | Operators already working in Claude | A folder-based context file you can version and edit, read access to your customer records, scheduled daily runs | The path I run on. Lowest setup if Claude is already in your day. |
The Codex app | Operators in Microsoft 365, Slack, or Notion | Memory that persists across runs, so it knows which day of the arc each customer is on, plus plugins for the tools your customer data already sits in | Cross-run memory matters more for this agent than for most, because the arc is stateful. |
A CRM-native automation layer | Operators whose customer records already live in one system | The agent runs where the records are, reads the purchase date directly, and writes its daily prep back as a task | The natural fit when your CRM is already the single source of truth. |
Quick Decision Rule
Already in Claude? Use Cowork mode.
Already in Microsoft 365, Slack, or Notion? Use the Codex app.
Customer records centralized in one CRM with automation hooks? Run it CRM-native.
The architecture below is identical across all three. Only the wiring changes.
The Orchestrated Sequence
Most business agents watch something and report what changed. This one does a different job, and it changes how you build it: it runs a process forward on a clock.
A monitoring agent asks what is true right now. An Orchestrated Sequence asks what day is this customer on, what was supposed to happen by now, and what comes next. Time is the spine and every other decision hangs off it.
Three parts make it work.
The Arc
The arc is your onboarding written as stages, each with a day range, a purpose, and a definition of done. Four or five stages covers most businesses at this size. More than six and you're describing your ideal rather than your real process.
A generic version to replace with yours:
Stage | Days | Purpose | Done means |
|---|---|---|---|
Welcome and orient | 0-1 | Confirm the purchase, set expectations, remove immediate confusion | They know what happens next and who their person is |
Gather what you need | 1-4 | Collect access, assets, answers required to start | You have everything and are not blocked |
First real result | 4-8 | Deliver something they can see, use, or react to | They have received real work rather than a plan for work |
Check and correct | 8-11 | Confirm the result matched expectations, catch mismatches early | They have said what they think, and you have adjusted |
Set the rhythm | 11-14 | Establish the ongoing cadence and the next milestone | They know what normal looks like from here |
The day ranges are what turn a document into an agent. "Send a welcome email" is a task. "By day one they know what happens next and who their person is, and if that isn't true on day two the agent flags it" is a system.
The Touchpoints
Each stage carries one or more touchpoints: a specific thing that goes to the customer, from a named owner, by a named day. The agent drafts each one from that customer's own details rather than from a template with their first name pasted in.
The rule that keeps this from becoming a drip sequence: every touchpoint is prepared, none are sent automatically. A drip fires regardless of what happened. This agent reads what happened with that customer, drafts accordingly, and waits for you.
The Handoffs
Four points where the agent stops and a human takes over. They're designed into the arc rather than being error states, and naming them is what makes the agent safe to run daily.
The kickoff conversation. Whatever form it takes in your business, a person runs it. The agent prepares the brief and the agenda.
The first real result. The work itself is yours. The agent confirms the inputs arrived and flags if the day-eight window is at risk.
Any negative signal. A complaint, a confused reply, a request to pause. The agent surfaces it and stops. It never handles displeasure.
The relationship moment. The point where somebody senior says hello for reasons that have nothing to do with process. The agent reminds you; it never fakes it.
Everything between those points is preparation, drafting, and tracking. Most of the work, almost none of the judgment.
The Protocol
Seven steps. Every prompt below is usable as written.
Step 1: Pick The Platform And Confirm Access
Pick the platform from the decision section above. Confirm the agent has access to:
The source where new customers appear, with a purchase or start date on each record
The folder or workspace where the context file and the daily log will live
Read access to the fields the arc needs: customer name, what they bought, start date, owner, and whatever your first deliverable depends on
Your inbox or chat, if you want the drafted touchpoints delivered where you'll act on them
You don't need a sophisticated stack. A customer list with start dates and a markdown log file is enough.
Step 2: Build The Context File
This is the most important step. The agent is only as good as the arc you write down, and nobody can write it for you, because your first fourteen days are specific to what you sell.
Create a markdown file the agent reads on every run. Name it onboarding-context.md and put it where the agent can reach it.
# Onboarding Context
## About The Business
- What you sell, the typical price point, and what the customer is buying (a service, a subscription, a product, a program).
- What "a successful first two weeks" means in your business, in one sentence.
## The Arc
List your onboarding stages in order. For each stage: the day range, its purpose, and what done looks like in observable terms.
- Stage 1 [name]: days [N-N]. Purpose: [what it accomplishes]. Done means: [observable condition].
- Stage 2 [name]: days [N-N]. Purpose: [what it accomplishes]. Done means: [observable condition].
- [continue through the end of the arc]
## The Touchpoints
For each touchpoint: which stage it belongs to, what goes to the customer, who it comes from, and the day it is due.
- [Touchpoint name]: stage [N], from [role], due day [N]. Content: [what it contains].
- [continue for every touchpoint]
## The Handoffs
The moments a human takes over. For each: what triggers it, who owns it, and what the agent prepares beforehand.
- [Handoff name]: triggered by [condition]. Owner: [role]. Agent prepares: [the brief, agenda, or draft].
- [continue for every handoff]
## What Blocks Progress
The things you need from the customer before you can move, by stage. Name each one and the day it becomes a problem.
- [Item]: needed by day [N]. If missing at day [N], flag it.
## Signals
- On track: [what a healthy customer looks like at each stage].
- Off track: [no reply for N days, a required item still missing at day N, a stage overdue by N days].
- Negative: [a complaint, a confused reply, a pause request, a refund question]. Any of these stops the agent and goes to a person.
## Voice
- How touchpoints should sound. Two or three sentences, plus one example of a message that sounded right.
## What The Agent Should Never Do
- Never send anything to a customer without approval.
- Never handle a complaint, a refund question, or a pause request. Surface it and stop.
- Never mark a stage complete without a dated signal that it happened.
- Never invent a customer who is not in the source. If a note mentions one, list it once under "Not on the arc" and stop there.
The Tacit-to-Explicit Knowledge work happens here. You already know what a customer needs in their first week. That knowledge lives as pattern recognition built over years. The context file moves it onto the page, where the agent applies it the same way to every customer, including the one who bought during your busiest week.
Step 3: Install The System Prompt
Put this in a file called onboarding-agent-system-prompt.md in the same folder.
You are the Onboarding Agent for [Business Name].
Your job is to run the first fourteen days after a customer buys. Each day you read every customer currently inside their onboarding window, work out which stage each one is on, check whether the stage is on track, prepare the touchpoints that are due, and flag anything that needs a human.
Read onboarding-context.md before every run. Everything in that file takes precedence over your defaults. The Arc, the Touchpoints, the Handoffs, and the Signals govern every judgment you make.
For each run, do the following in order.
STEP 1: READ THE ROSTER
Read every customer whose start date is within the last fourteen days. For each one pull the name, what they bought, the start date, the owner, and the current day number (today minus start date). If a field is missing, mark it "unknown" and do not infer it.
STEP 2: PLACE EACH CUSTOMER ON THE ARC
Using the day number and the Arc in onboarding-context.md, determine which stage each customer is in. Then check the "done means" condition for every stage they should have completed by now. Cite the dated signal behind each judgment: a logged touchpoint, a received item, a reply. A stage with no cited signal is not complete.
STEP 3: CLASSIFY STATUS
Assign each customer exactly one status: On Track, Waiting (blocked on something you need from them), Behind (a stage is overdue), or Stopped (a negative signal appeared). Cite the specific signal and its date. If you cannot tie a status to a dated signal, assign On Track and note that you could not verify it. Do not raise urgency on a hunch.
STEP 4: PREPARE WHAT IS DUE
For every touchpoint due today or overdue, write the message from that customer's own details: what they bought, what has happened so far, what they said in their last exchange. Never a template with a name pasted in. For every handoff reached, prepare the brief the human needs.
STEP 5: FLAG WHAT NEEDS A PERSON
List every Stopped customer first, then every Behind customer, then everything Waiting past its flag day.
OUTPUT TEMPLATE (use exactly):
## Onboarding Board, [date]
### Needs you today
[For each Stopped or Behind customer:]
- [Customer, what they bought] | Day [N], Stage [name] | [Status] | [the signal, with its date]
Why: [the specific thing that is wrong]
Prepared: [the brief, draft, or agenda]
### Ready to send
[For each touchpoint due today:]
- [Customer] | Day [N] | [Touchpoint name]
Draft: [the message, written from this customer's details]
### Waiting on the customer
[Each blocked customer, one line: what is missing and how many days it has been outstanding.]
### On track
[One line each. No action.]
### Not on the arc
[Any customer referenced in notes but missing from the source. Name once. Do not track until entered.]
Do not pad. A customer with nothing due and nothing wrong belongs in the tail.
Two things this prompt does under the hood:
It computes a day number and places the customer on the arc before anything else. Every other judgment depends on that number.
The cited-signal rule is a hard gate. Tying every status to a dated signal stops the agent filling your morning with customers it feels vaguely uneasy about. In my testing it does more for trust than any amount of stage tuning, because it keeps the "Needs you today" list short enough to work.
Step 4: The Three Runtime Prompts
The Daily Board prompt:
Run today's onboarding board using your system prompt and onboarding-context.md.
Read every customer inside their first fourteen days, place each on the arc, check the done-conditions for every stage they should have finished, and assign a status with a cited signal. Prepare every touchpoint due today, written from that customer's own details. Prepare the brief for any handoff reached today.
Produce the output using the OUTPUT TEMPLATE. Keep "Needs you today" to customers who genuinely need me, and tell me at the bottom how many customers are currently inside the window.
The Approved Send prompt:
For the touchpoints I have marked approved below, send each one.
Send only what I have approved here. For anything else, hold it and tell me you are holding it. After sending, log each one: customer, touchpoint, date sent. Do not change any field in the customer record.
The Cohort Review prompt (weekly):
Produce the weekly onboarding review.
For every customer who completed or exited the fourteen-day window this week, show how the arc really ran: which stages hit their day range, which slipped and by how many days, and where they ended up. Then call out separately: the stage that slipped most often across the cohort, every customer who finished the window without reaching a first real result, the average day the first result arrived against the target, and anything a customer said that I should read myself.
Keep it to something I can read in five minutes before I plan the week.
That last prompt improves the business rather than the week. A stage that slips for one customer is a busy week. The same stage slipping across a cohort is a process problem, and you won't see it from inside the daily board.
Step 5: Run It Backward First
Don't start live. Start on customers whose ending you already know.
Pull your last two quarters of customers, both the ones who stayed and the ones who left. Reconstruct roughly what happened in each of their first fourteen days from your records: when the welcome went out, when the first deliverable arrived, when they replied. Run the agent against that history and see how it would have called each one.
What to check | What you are looking for |
|---|---|
The customers who churned early | Did the agent mark them Behind or Waiting during onboarding? If somebody who cancelled in month four looked On Track the whole way through, your done-conditions are describing activity rather than outcomes. |
The customers who stayed and expanded | Did their arcs run on time, or did you get away with a slow start? If your best customers were also Behind, the day ranges are tighter than your real process and the agent will cry wolf. |
The blocked ones | How long did missing items really sit? Set your flag days against that number rather than against what you wish it were. |
The misses tell you which stage to fix, and it's usually the same stage for everyone.
Step 6: Tune After The Backtest And The First Live Week
The Onboarding Agent drifts in predictable directions. These four cover most of it.
Activity mistaken for progress. The agent marks a stage done because a touchpoint went out, not because the outcome happened. Reinforce in the context file: "A stage is complete when its done-condition is observably true, not when its touchpoint was sent. A welcome email that got no reply does not complete 'they know what happens next.'"
Template voice. Drafts come back generic because the agent is pattern-matching a template rather than reading the customer. Add: "Every draft must reference at least one specific detail from this customer: what they bought, something they said, or where they are in the work. A message that would read identically to any other customer is wrong."
Day-count drift. The agent counts calendar days where your business runs on business days, or the reverse. State it explicitly: "Day numbers count [calendar / business] days from the start date. The start date is day zero."
Handoff creep. The agent drafts a reply to a complaint because the reply seemed obvious. Restate the boundary: "A complaint, a confused reply, a pause request, or a refund question stops the agent. Surface it with the customer's full context and draft nothing."
Step 7: Set The Cadence
Daily, first thing. Schedule the board before your day starts, so the drafts and the flags are waiting when you sit down. This is the run that catches the customer who has been waiting since day three.
Weekly, for the cohort. Schedule the review for your planning day. The daily run keeps customers from falling through. The weekly run tells you which stage of your onboarding is costing you renewals.
Both Claude Code in Cowork mode and the Codex app support scheduled automations, and a CRM-native build can run on the CRM's own workflow trigger. Point it at your customer source, set the daily run, and route the board wherever you'll act on it.
What This Looks Like By Business Type
The agent stays the same. The arc, the first real result, and the thing that blocks progress change with the business.
Agency | SaaS | Ecommerce / DTC | Expert / Creator | |
|---|---|---|---|---|
The window starts | Contract signed | Trial converts or plan starts | First order ships | Program or engagement begins |
First real result | A deliverable they can review, not a plan | The first workflow completed inside the product | The product arrives and works as expected | The first session, module, or piece of feedback |
Usual blocker | Access, brand assets, the answers only the client has | Data import, a seat invite nobody accepted | An address problem or a delivery exception nobody saw | An intake form left half-finished |
Best early signal | They replied to the kickoff brief with edits | They came back a second day without being prompted | They opened the follow-up and did not contact support | They completed the first assignment |
Watch-Out | A quiet client reads as a happy client. It usually means they have not started. | Product usage is not onboarding. Somebody can be clicking around and still not have reached the first result. | No news is not good news when the only signal you have is the absence of a complaint. | Enthusiasm at signup predicts nothing about week two. |
Every business has one signal it habitually reads as health, and in onboarding it's almost always the absence of a complaint. That's the Watch-Out row. The agent measures against the arc instead, so a customer who has said nothing since day one shows up as Behind rather than as fine.
Deploying This Across Your Team
It works solo and compounds when everyone who touches a new customer runs off the same arc.
You own the arc, the day ranges, and the handoffs. Those rules are how your onboarding is defined, and they live in a shared file your team can read but not change. That is what makes "behind" mean the same thing on every desk.
Each owner works their slice. The board filters by owner, so a customer success lead opens the day to their own customers, their own drafts, their own flags.
Misses go back into the file, not into somebody's memory. When the agent flags a customer who was fine because of an agreed exception, the exception goes in the context file. A rule fixed in the file holds for everyone. A rule fixed in a hallway conversation breaks again next month.
You own the send boundary. The agent drafts, a human reads and sends. These go to customers in their first two weeks, the least forgiving audience you have, so I keep sends human-approved indefinitely rather than turning on auto-send.
The compound effect: nobody's first fourteen days depend on how busy your team was that week.
Want The Full Agent Build Pack?
You can build (most of) the Onboarding Agent from the prompts above. If you'd rather skip the setup work, Cortex subscribers get the full Onboarding Agent Build Pack as a download:
The installable Claude Skill that sets up the agent in Cowork mode in one command
The Codex configuration pack with system prompt, plugin list, and the daily and weekly automation specs
Four pre-filled context files (agency, SaaS, ecommerce, and expert / creator) with real-feeling arcs, day ranges, touchpoints, handoffs, and signals you can adapt instead of starting blank
The Tune Pack: the most common drift patterns I've seen for this agent (activity mistaken for progress, template voice, day-count drift, handoff creep, and four more), with the exact context-file edits and prompt patches that fix each one
Three example onboarding boards with annotations on why each customer classified where it did
This is only available to paying Cortex subscribers.
What is Cortex?
Cortex is the premium monthly membership version of Bionic Business, helping entrepreneurs and business owners grow and scale with AI and Agents.
In addition to 3-4 full, unrestricted regular issues per month, you also get:
1x SIGNALS Strategic Briefing issue (strategic moves you must make now to secure your business revenue, market share, and profits).
1x CIRCUITS Tactical Guide issue (workflows, how-to’s, prompts, very practical implementation inside a self-driving business).
Access to all Agents and Skills issues (full details, download files, tutorials).
Claude Cowork as your marketing team special issue (full guide on how to run Cowork as an agent marketing team for your business).
50% OFF workshops on prompt engineering, agent operating systems, and more. Only active Cortex subscribers get any kind of discount, no one else.
So, if you’d like to receive full issues and the monthly special Signals and Circuits issues, then you should sign up for Cortex, which is $50/month (and you have full archives of previous regular issues for as long as you’re a paying member).
One note on Signals and Circuits: You only get these special issues for the months you’re subscribed—which means if you skip a ~30 day period, about a month, you won’t get them for that month. There are no back-issues for past months, so now is your chance to lock-in these upcoming issues while you can.
After you’ve upgraded to Cortex, log in to the website and come back to this issue, and the Agent Build Pack will be unlocked below.
Ready? Get the Agent Build Pack, full regular issues, and the upcoming Signals and Circuits issues:
Cortex is a monthly premium version of Bionic Business, helping entrepreneurs grow and scale with AI and Agents. You can cancel at any time. But there are no refunds, for any reason. All sales are final.
The agency owner wrote that cancellation up as a fit problem, and he believed it.
It's the easiest explanation available, it costs nothing to accept, and it points at the customer instead of at the process.
Nineteen days is a long time to wait for the thing you already paid for. He never saw it because nothing in his business was counting.
Run this for a month and I’m sure you’ll notice the difference.
Talk soon,
Sam Woods
The Editor
.
