.webp)
Part 1 of our build-in-the-open series introduced the studio's AI teammates one at a time. This is the three of them together, because they turned out to be one idea in three shapes. The opening post covered why we built them at all.
A chatbot waits for a question. You open it, you ask, it answers. All three of these are the opposite shape: they come to you. One speaks the moment a build breaks, one puts a briefing in your DMs before a call you half-forgot, and one hands back the reasoning behind a decision months after everyone forgot it. Nobody asks any of them to look.
Pulse: the one that tells you it's broken
It was a Wednesday afternoon and I was deep in something else when Slack lit up in a channel I don't sit in. Not a person pinging me. A message that started with the word failed. Our main branch had just broken. A deploy had gone out, a check had gone red, and the thing telling me about it wasn't a teammate who happened to notice. It was Pulse.
Nobody asked it to look. Nobody was watching the pipeline with a coffee, waiting. It saw the branch go from fine to not-fine and it said so, in the room where the people who could fix it already were, moments after it happened. I read it, pinged the right person, and it was handled before it became the kind of thing a client finds first.
That last part is the whole point of this post. The expensive failures in most businesses aren't the loud ones. They're the quiet ones, the thing that broke at 2 p.m. that nobody clocks until 5, or until the customer clocks it for you. The gap between it broke and someone noticed is where the cost lives. Pulse's job is to close that gap.
It speaks first
If you read the last part, you have met Pulse already. It's one of three AI teammates that live in our Slack, and its beat is the projects: what shipped, what stalled, what broke. Last time I described it as the thing that posts a summary every morning. True, and that is the calm, boring 90% of what it does.
But a summary is still something you sit down and read. The part that changed how the studio feels is the other 10%, the moment Pulse stops waiting for morning and interrupts you, because something is wrong right now and morning is too late.
A chatbot waits for a question. You open it, you ask, it answers. Pulse is the opposite shape. Most of the time it is silent. Then, unprompted, it puts a hand on your shoulder. You already know what it's like to ask software a question. It's a genuinely different feeling to have software come find you.
The one thing it will interrupt you for
Here's where I want to be precise, because "AI that monitors everything" is a promise that usually means "AI that pings you about nothing useful."
Pulse interrupts you for exactly one kind of event: a build or a deploy failing on the branch that ships. Not a pull request. Not someone's half-finished experiment on a side branch. Not a passing build, not a flaky test that sorted itself out on the retry. When the branch your customers actually get breaks, and only then, an alert lands in the project's channel.
That narrowness is not a limitation I'm apologizing for. It's the feature. An alert you can trust to mean "drop what you're doing" is worth ten alerts you have taught yourself to swipe away.
The hard part was making it shut up
I'll admit I expected the alerting to be the easy bit. Something breaks, send a message, how hard can it be. The hard part, it turned out, was the silence.
The first honest version of a monitor is unbearable. A build can fail, get retried, and fail again, three times in five minutes. GitHub can deliver the same event to us twice. A branch that's broken stays broken until someone fixes it, and a naive alerter will happily remind you of that every few minutes, like a smoke alarm with a low battery. Within a day you would mute the channel, and a muted alarm is worse than no alarm, because now you believe you're covered.
And that failure is human, not technical. Nobody swipes an alert away on purpose. Attention just wears down. A signal you see many times a day stops registering as a signal, however conscientious you are, and no amount of willpower fixes it, because the problem was never willpower. This is the one place software genuinely has us beat. Pulse has nothing wiser to say than a good engineer would. It simply never gets tired, and never learns to tune itself out.
So most of the engineering went into restraint. Pulse alerts on the transition, the moment a branch crosses from passing to failing. It's the difference between a car that chimes once when you leave a door open and one that chimes the whole time the door stays open. One tells you something. The other becomes noise you stop hearing. A build that's still failing an hour later is not news; it's the same news, and it stays quiet. Duplicate deliveries get dropped. There's a cooldown floor so a thrashing pipeline can't spam the room. Each repository keeps its own little memory of "have I already said this," so one noisy project can't drown out the others.
The result is a channel where a message from Pulse actually means something. It has earned the right to interrupt you, by spending most of its existence saying nothing. If there were one idea from this whole series I would want a non-technical owner to take away, it's that: the value of an alerting system is mostly in what it declines to send.
There is a practical version of that, if you ever go to build one. Don't start from what you could detect, because almost anything can be detected. Start from a harder question, asked of every candidate alert: is this worth spending a person's attention on, every single time it fires, forever? Most don't survive it. The few that do are the only ones worth wiring up. Attention is a budget that doesn't refill, and the whole craft is spending it like you know that.
The calm 90 percent
Underneath the alerts is the quieter habit. Every morning, before most of the team is online, Pulse posts a digest for each active project: what moved yesterday, what's open, what's waiting on someone. On Friday afternoon it posts the week in review. I don't trigger these. They arrive because it's morning, or because it's Friday.
It's the difference between walking into a room already knowing where things stand and spending the first hour of your day reconstructing it from twelve browser tabs. Nothing dramatic. Just a floor under the day.
Scout: the one that briefs you before the call
Ten minutes before a client call last month, I opened Slack to grab a link and found a message from Scout already waiting for me. It was a briefing on the company I was about to talk to: what they do, the work we had done for them, the two things most likely to come up, and a short list of sources. I had not asked for any of it. I had not even opened the calendar invite yet. Scout had read my day, worked out who the meeting was with, gone and looked them up, and written the whole thing down while I was doing something else.
I walked into that call already knowing where things stood. Not scrambling through old email threads in the first five minutes, not nodding along while I tried to place a name. Ready. And the thing that made me ready was sitting in my DMs before it occurred to me that I would want it.
That is the whole point of this post. In most jobs the meeting is not the hard part. The hard part is the ten minutes before it, the reconstruction, the "wait, who are these people again," the quiet gamble that you remember enough to not look unprepared. Scout's job is to close that gap, and to close it without being asked.
The prep you did not do
If you read the first two parts, you have met Scout already. It is one of the AI teammates that live in our Slack, and its beat is people and meetings: who we are talking to, what we know about them, what is coming up. Last time I introduced it as the one that does research. True, and I will get to that.
But research you ask for is still research you have to remember to ask for. The part that changed how the day feels is the part nobody triggers. Scout watches the calendar, and about an hour before a meeting it puts a briefing in your DMs on its own.
A chatbot waits for a question. You open it, you ask, it answers. That is useful, and Scout does that too. What is different in kind is the message that arrives before you thought to open anything. You did not prompt it. It read the situation and decided you were about to need something, and it was right.
What is actually in it
The briefing is short on purpose, four sections you can read in the time it takes an elevator to arrive. Who they are, in a couple of lines. Our relationship with them, pulled from what we already know. A few talking points worth having in your head. And the sources it used, linked, so you can check its work rather than take it on faith.
That last part matters more than it looks. A brief you cannot trace is a brief you have to either believe blindly or redo yourself, and both defeat the purpose. Scout shows its receipts so you can glance, confirm, and move on.
The hard part was not the research
I will be honest about what impressed me here, because it was not the part I expected. Anyone can research a company. You can, I can, a search box can. If you sell for a living you are probably already doing it by hand, pasting the company name into a chatbot on the morning of the call. If the clever bit were the looking-things-up, this would not be worth an part.
The hard part is the timing. A briefing is only useful in a narrow window. Too early and you read it, forget it, and it is stale by the time you sit down. Too late and the meeting has already started and you are reading it under the table. Twice and it is just noise, the calendar-reminder problem where you mute the thing that was supposed to help. The brief has to land once, in the right window, before the meeting and not after, and it has to do that even though the machinery checking your calendar wakes up every few minutes and has no memory of what it did last time.
So most of the engineering went into when, not what. Scout only fires inside a forward-looking window that opens shortly before the meeting and closes the moment it starts. It never sends a reminder for a meeting already underway. And because the calendar check runs on a short loop, two ticks can easily overlap the same meeting. To make sure you get exactly one message and not two, Scout claims each meeting in the database before it sends anything. Whichever check gets there first wins and sends; the other finds the meeting already claimed and quietly stands down. If there were one idea a non-technical owner should take from this, it is that the value of a well-timed nudge is mostly in the timing. The information is the easy half.
You can also just ask
None of that stops you from summoning it directly. Type /scout research and a company name and you get the same kind of briefing on demand, in seconds, cited.
I use both, and they serve different moods. The calendar brief is for the meeting I half-forgot was happening. The command is for the moment a name comes up in conversation and I want to know who they are before I reply. Same engine, two doors.
Memo: the one that remembers why
"Why is the client's staging environment in their cloud and not ours?"
The question showed up in a Slack thread on a Tuesday, from someone who had joined after the decision was made. Reasonable thing to ask. It was an unusual setup, and I was the one who had built it that way. I knew there had been a good reason. I could not, staring at the message, produce it. The person who had been on the call with me when we decided had left the company months before.
So I did what you do. I went looking. A channel I half-remembered, a thread that turned out to be the wrong thread, a doc that stopped just short of the part I needed. Twenty minutes later I found it, buried in a message from the spring: a compliance requirement. The client's data had to stay inside their own subscription. Obvious once I saw it. Completely gone until I went and dug it up.
That is the post. Not the twenty minutes, which I will happily never spend again. The thing underneath it: the decision survived, but the reason for it did not. And a reason you cannot reconstruct is a decision you are doomed to relitigate, usually at the worst possible moment, usually with the one person who remembered already gone.
Where the "why" goes to die
There is a good line I ran into while writing this. When a team asks "why did we decide this?" and nobody can answer, it is not because the decision was bad. It is that the context that made it sensible has evaporated. It is not a documentation problem so much as a context-preservation problem.
That rings true to how it actually fails. The what of a decision tends to leave a trace. Staging is in their cloud, you can see that, it is a fact about the world. The why is softer. It lived in a conversation, in the half-hour of back-and-forth where someone raised compliance and someone else said fine, their tenant then, and everyone moved on. Nobody wrote "we decided their cloud because data residency" on a board anywhere. The reasoning was load-bearing and completely undocumented, and it walked out the door with a person.
Every growing team knows it should keep a decision log. Almost none of them do, because the discipline of writing "we decided X because Y, owner Z" after every meeting is exactly the kind of thing that loses to the next meeting. So the log does not get kept, and the why rots quietly until the day you need it.
You hand it the meeting
If you read the earlier parts you have met Memo. It is one of the AI teammates that live in our Slack, and its job is the one nobody enjoys: remembering. Not the code, not the calendar. The decisions. What we chose, why we chose it, who owns the follow-through.
Here is the part I want to be straight about up front, because it shapes everything else. Memo does not sit in every channel eavesdropping. You hand it the meeting. After a call, you drop the transcript into Slack and mention it, or point it at a synced note, and that is the raw material. It remembers what you give it. I will come back to what that costs you later, because it is the honest limit of the whole thing, but it is also the reason it works at all: a thing that quietly logged every conversation you had would be a liability, not a teammate.
The magic isn't storing it. It's the mess.
What Memo actually does with that transcript is the part worth the part. An hour of people talking over each other goes in. What comes back out is short and structured:
- The decisions that actually got made. Usually two or three, dug out from under the tangents.
- The reasoning behind each one. The why, the part a plain transcript quietly loses.
- The action items. Each with a name and a date attached to it.
Storing text is easy. Anyone can save a transcript. The hard part, the part that took the real work, is pulling shape out of a shapeless hour. A meeting is not a list of decisions. It is tangents and second-guessing and three people agreeing in slightly different words, and somewhere in there, a choice. Getting a machine to reliably find the choice, separate it from the noise, and write down why it was made without inventing a reason that sounds plausible, that is the whole engineering problem. The record is the easy half to describe and the hard half to build.
Months later, you just ask
The reason you do that work is so that the future has somewhere to look. Months on, when someone asks the question I could not answer, the answer is one message away. You ask Memo, in plain words, what did we decide about the client's staging, and it comes back with the decision, the reason, who made it, and a link.
The citations at the bottom matter more than they look. Memo does not tell you what it thinks probably happened. It answers only from what was actually captured, and it shows you the receipts for every line, so you can click back to the exact decision and the exact action item it is drawing from. If it has nothing, it says it has nothing. An answer you can check is worth ten answers you have to trust.
That is the whole loop closed. A decision made in a meeting, its reasoning preserved as a byproduct rather than a chore, and pulled back intact long after the meeting ended and the people moved on.
What the three of them cost
All three share one shape, and it is the whole reason the bill is small: the half that runs around the clock never calls a model. Watching a branch, reading a calendar, storing a decision — that is plain, fast, deterministic code. No reasoning, no tokens, no bill. You pay only when there is prose worth generating.
- Pulse: watching is free. A morning digest is a model doing real work, and costs about half a cent.
- Scout: the calendar poll is free. A brief is a web search plus a short burst of writing — a few cents. A day with no meetings costs nothing at all, because there was nothing to write.
- Memo: capturing a meeting is a few cents, one pass over the transcript. Asking a question is a cent or two. Storing a decision and finding it again is a rounding error, and matching up names is plain code with no AI in it.
I like that split because it kills the scariest version of the question. "You have an AI watching your systems all day, what does that cost?" Nothing, until it has something to say. And then, pennies.
The arithmetic, worked out against published prices rather than asserted, is in the cost appendix.
Where it gets thin
Now the seams, because a build log that only shows the wins is an ad wearing a lab coat. Each of the three is narrow, and in every case the narrowness is deliberate — it is the reason the thing is trustworthy at all. But narrow has a cost, and it is worth naming per teammate.
Pulse catches fires, not fevers
The restraint I just bragged about cuts both ways. I tuned Pulse to only shout when something clearly, cleanly breaks. That means it's excellent at the sharp failures and blind to the slow ones. A problem that never trips a hard red check, a thing that just gets quietly worse, won't set it off. The textbook version is a site that passes every health check with a cheerful all-clear while a customer sits there staring at a checkout button that won't load. Every light green, and the thing is still broken. Pulse watches the build, not the customer's screen, so that's a gap it would miss too. It's a smoke detector, not a doctor. It catches fires, not fevers.
And it only watches what we pointed it at, which is our own code. Client work that lives on other systems is simply outside its view. The morning picture it paints is real, but it's the picture of one room, not the whole building. Knowing that is the difference between a tool you trust appropriately and one you trust blindly.
Scout is matching an email domain, not understanding your day
Scout does not actually understand your meeting. It guesses. To know who a meeting is with, it looks at who is invited and reads the company off their email address, and if that does not work it takes a stab at the meeting's title. That works well for a call with someone@acmecorp.com. It falls apart the moment the person you are meeting used a personal Gmail address, or the invite is titled something generic like "weekly sync." When Scout cannot place the company, it says so plainly and gives you the calendar basics without the research, rather than confidently briefing you on the wrong company.
I would rather it admit that than paper over it, but it is a real limit worth naming: this is pattern-matching on an email domain, not comprehension of your day. A couple of smaller edges sit next to it. Scout reads your primary calendar and only that, so a meeting living on a shared or secondary calendar is invisible to it. And it is read-only by design. It will brief you on a meeting, but it will never move one. Knowing that is the difference between trusting it appropriately and trusting it blindly.
Memo does not eavesdrop, and that is the point
Memo does not eavesdrop. I said this early and I am saying it again because it is the real limit, not a footnote. It remembers what you hand it and nothing else. A decision made in a side conversation, in a call nobody captured, in a thread you never pointed it at, simply never enters the record. It is not secretly listening as a backstop. If the meeting did not get handed over, the why is as lost as it ever was, and Memo will tell you it has nothing rather than invent something to fill the silence. The upside of that limit is a teammate you do not have to be afraid of. The cost is that the discipline did not vanish, it shrank: you still have to feed it the meeting.
A couple of smaller edges sit next to that one. Memo matches people by the way their names are spelled, not by knowing them, so when a transcript says "Sam" and two Sams could be meant, it stops and asks you rather than guess wrong.
And recall is only as good as the words you use. Ask about a decision in language far from how it was recorded and it can slip below the line the search draws, and come back as "nothing found" when the thing is right there. Absence of an answer is not proof of absence of a decision, it can just mean you and the record chose different words. Last, Memo surfaces the record, it does not act on it. It will remind you what you decided. It will never quietly change it.
The pattern travels
Strip the words "branch", "client" and "deploy" off all three and you are left with one move almost any operation can use: watch quietly, and put something in front of a person only at the moment they can act on it. One example each, because the shape is easier to see than to describe.
- A clinic doesn't lack alerts. It drowns in them. Electronic records fire so many pop-ups that staff learn to click past them, and that fatigue is a known patient-safety problem, not a hypothetical. The win there isn't one more notification. It's the discipline to send far fewer, so the ones that land are believed.
- A salesperson walks into back-to-back discovery calls and a renewal, and the difference between a good one and a wasted one is whether they remember what this account bought last time. A brief that lands before each call, unasked, is the difference.
Nothing about this is specific to building software. Take the word "client" off it and you have a move for almost any team where decisions outlive the people who made them: a consultancy that cannot afford to re-learn an account every time someone moves on, a finance team defending a call a year after they made it, any group with enough turnover that the reasoning keeps leaving with the people who hold it. Preserve the why while it is cheap, so nobody has to reconstruct it later when it is expensive, or gone.
Same move every time. Stay silent through the normal, speak once on the thing that changed, and preserve the reasoning while it is still cheap to capture.
We're building this in the open. Follow along for the next teammate, and if you're already picturing it in your own shop, say hi.
Technical readers, each of these has its own engineering companion: how the alerting stays quiet and the webhooks are deduplicated, how the calendar poll stays free and claim-it-first guarantees exactly one brief, and how a transcript becomes a searchable decision record.