Welcome back to The Customer Continuum. Issue #39.
A lot of you joined in the last couple of weeks, so here’s the short version of what you’ve walked into. I write this newsletter for customer marketers, cx and post-sale teams who want their work taken seriously by the people who fund it. Most issues are Build With Me, where I build something real and report what actually happened, including the parts that broke. Right now I’m in the middle of a five-part series on an AI chief of staff I built this summer. Part 1 covered where it came from and the night it refused my first instruction. This week is the plumbing, what’s actually inside it and what I got wrong. The last two parts turn it toward your job, and the finale points the whole thing at the seven pillars of Customer-Led Growth, the model I use for growing a business through what happens after the sale.
A summer I spent on purpose
I had a window between roles this summer, and I decided to spend it going as deep on AI as I could. I put in real hours, the kind that don’t fit between meetings, and I let myself be bad at it for a while.
When I talk to people who haven’t gone deep on AI yet, the thing they’re usually short on is time. They’re capable, they’re just carrying a full job with a fixed scope, and nobody’s handing them three weeks to learn something with no deliverable attached. I had that gap, and I spent it on this.
Jarvis came out of that summer, and so did the system that now produces this newsletter, which has honestly changed more about how I work. Underneath, the two are built the same way. Each has a file that tells the AI who I am and how I work, a file that collects every lesson with the date it happened, and a check that reads the work before it ever gets to me.
The first week, mostly from memory
My agent keeps a memory file. Whenever something breaks or I correct it, the lesson goes in with a date. That file has 101 entries now, and when I went back to find my mistakes from the first week, there were only two, followed by nine days with nothing at all.
A lesson gets written down when something goes wrong. The file stayed nearly empty while I was still experimenting, and it filled up once the system started touching things that mattered, like my inbox, my calendar, and the job search it was helping me run. So if you’re holding off on documenting until you feel disciplined enough, you can stop waiting. In my case, the entries started piling up the same week things started going wrong.
That means most of what I can tell you about the first week comes from memory rather than a documented memory file.
I wanted something like Jarvis and had no idea how to put one together, so I started with the three things I could connect: my meeting notes, my email, and my calendar. Most of that first stretch was me going back and forth on scope. I couldn’t decide whether to pull in my text messages, and I still haven’t. I started building a feed of industry reading, and that’s still unfinished, which is a pretty accurate picture of what happens when something sounds interesting and I haven’t thought about what it’ll cost me in strategy and planning.
At the start there was no conversation at all. Jarvis read me a brief each morning, and that was the whole interaction. What I really wanted was to talk to it, because that was the version I’d pictured ever since I saw it in Iron Man. I held off anyway, because a readout that worked every morning was more use to me than a conversation that only half worked. So I shipped the readout, and I used it every day.
Talking to it came much later. My Customer Marketing Summit keynote gave me a deadline, and I’d be lying if I said that didn’t help. I also knew what I’d actually ask it, which is what made building it worthwhile and valuable. The first version had a long pause every time I spoke, 15-30 seconds long to process what it just heard which made me think I broke something. Thankfully I managed to refine the response time considerably.
Underneath all of it was one question: was this actually useful to me on an ordinary Wednesday? It took a lot of iteration before I trusted what it knew and how it judged things enough to stop checking everything it told me.
What’s actually in it
The code is 3,809 lines across twelve files. Two of those files, the dashboard and the server that runs it, make up more than half. The rest handle speech, the public demo, a transcriber for my voice notes, and a basic test.
The writing is 47,709 words. When I counted for Part 1 it was about 3,500 lines and 33,000 words, and both have grown since, because I kept changing things after the Summit.
So a summer of learning to build with AI produced mostly writing, and that writing lives in a handful of files.
The constitution is about 5,400 words, and the agent reads it at the start of every session. It covers who I am, what data it can see, the rules it works under, what the morning brief should contain, and how it’s allowed to write. It’s essentially an employee handbook written for something that follows it to the letter.
The memory file holds those 101 dated entries. Nothing in it ever gets rewritten, so when the agent gets something wrong and I correct it, the correction goes in with a date, and it reads all of them the next time it runs.
The roadmap is about 1,300 words, and it’s there so that what I build next comes from a plan instead of from whatever seems exciting that morning.
The friction log is where I tracked a week of dry runs before I trusted the whole thing to run on its own.
Then there are four small files, one for each of the agents that run in parallel every morning. Each carries the rules for its own job, so the rules travel with the work instead of depending on whoever calls it to remember them.
Two scheduled jobs make it run without me. One keeps the dashboard server up, and the other starts the morning run at 6:30 on weekdays. It all runs on one Mac that wakes itself up.
This newsletter runs on the same three pieces
The system behind this newsletter follows the same pattern. There’s a file of writing rules with the reasons behind them, a file of every tic and habit I’ve caught in my own drafts, which grows whenever a new one slips through, and a checker that reads each draft against both before I see it. I’m not going to open those up here, but once you’ve seen the same three pieces twice, you can start using them anywhere.
For a customer marketing or post-sale team, those pieces are your playbooks and your post-mortems, written down in a form something can actually read and follow. When a team hasn’t written them down that way, every new hire relearns the same lessons and every campaign starts from scratch. If you write playbooks, briefs, and post-mortems for a living, you already have the part that took me longest to develop.
The one that got away from me
The security incident is the part of this build I least enjoy telling you about.
On August 13th I had a simple web server running so I could see the dashboard in my browser. The standard way to start one makes every file in the folder available to every device on your network, and one of those files held the key for my voice service.
For a few hours, anything on my home wifi could have downloaded that key. It wasn’t reachable from the internet, which is the one piece of luck here, but it was still sitting there for any device on the network.
The agent found it during a routine check. It shut the server down, built a replacement that only listens on the machine itself and won’t serve hidden files, tested the fix with real requests, and told me to replace the key.
That last step required my intervention, and it sat undone longer than it should have, because I was busy and nothing was on fire. I replaced it this week while writing this issue, which tells you how much writing in public helps me follow through.
The bug that looked like bad judgment
I spent two days thinking the agent had a reasoning problem, when the problem was in the tool it was using.
It told me twice that someone had gone quiet on a thread that mattered to me, when she’d actually replied and I’d already answered her. When I corrected it, it told me the thread was stuck waiting on me, which was wrong in a different way.
I assumed it was reading meaning into silence again, which was the lesson from Part 1. When we finally dug in, the cause turned out to be the search function, which returns threads with some of their messages missing. We confirmed it on a live thread, where search showed the other person’s message as the most recent one and opening the same thread showed my reply from five hours later. The agent was reasoning fine on an answer it had no way of knowing was incomplete.
That’s now a rule in the constitution: a search result tells you a thread exists, and it’s never evidence of what’s in it. If you build anything on top of someone else’s software, expect to hit some version of this, where the tool gives you a partial answer and assumes it’s complete.
What this means for you
You don’t need an agent to use any of this. Write down how you work, with the reasons. Keep a running list of what you learn, with dates, and don’t delete the old entries. Then have something check your work against both before it goes out. The first two are just documents, and you can start them this week.
And start with the readout. The impressive version can wait until you know what you’d ask it.
What’s next
Part 3 is what changed and what didn’t: six weeks of running this every morning, an honest before and after, and the parts of my week it never touched.
This week’s free starter: the constitution skeleton
It’s the blank version of the file that makes all of this work, with the section headings, the questions each section answers, and prompts to fill it in for your own setup. You can write a usable first draft in an afternoon, and it helps whether you’re building an agent or just want more consistent output from a chat window.
FOR PAID SUBSCRIBERS
The actual constitution, redacted and ready to use
Last week I promised you this file. It’s my real constitution, with every private detail swapped for a placeholder you fill in yourself.
All fifteen operating rules are there, worded exactly as they run. The section headings are the same. When a rule came from something going wrong, I kept a short note on what happened. Without the reason, a rule is easy to delete the first time it gets in the way, and I'd be the first to do it. There are 42 placeholders, and each one has a note on what belongs there and why.
When I built it, the redacted version came out longer than the original, 5,749 words against 5,414, because a private detail like a number turns into a placeholder plus an explanation of how to pick your own. The private details were a small part of the file, and nearly everything else carries over to your setup.
Your task brief this week
Test the template and fill in the first three sections: who you are, what data the agent can see, and your first five operating rules. Stop at five. Mine got to fifteen because things went wrong fifteen times and I kept iterating.
Then point it at the two agents in your kit that are closest to your own week. Run each one once with the file loaded and once without, and compare what comes back.
— Kevin
P.S. If you keep telling yourself you’ll get into this properly once things calm down, I’d gently point out that they rarely do. I got here because I had a gap and used it. Forward this to someone who’s waiting for theirs.