A founder I worked with last year told me, about three weeks into a build, that he’d started checking our Slack channel first thing every morning. Not because I’d asked him to. Because he needed to feel like things were moving.
That was a communication failure on my part.
We were on schedule. The model was performing well on the test set. Sprint two was going exactly as planned. But I hadn’t given him a systematic way to know that. He filled the silence with monitoring behavior, refreshing Slack before his coffee was done.
The technical delivery was fine. The client experience wasn’t.
Since then, I build four fixed communication touchpoints into every AI sprint. They’re not updates for the sake of updates. Each one has a specific job: answer the question the client has in their head before they have to ask it out loud.
Here’s the full template, and what each message actually does.
Why AI Builds Need a Different Communication Rhythm
In a standard software build, progress is visible at short intervals. A feature works or it doesn’t. Clients can check staging, click a button, and confirm it does what they asked.
AI systems don’t surface progress that way. An LLM-based pipeline is either not built yet, in active development, or working. There’s rarely a visible intermediate state. During the first half of most AI sprints, clients see nothing new in staging because the work is happening at the model level, not the UI level.
That gap between visible progress and actual progress is where anxiety lives.
If I don’t fill that gap proactively, clients fill it themselves. They ping on Slack, ask if things are on track, send the “just checking in” email. That’s not a difficult client. That’s a client operating without information they need. My job is to make sure they don’t have to ask.
The four-message structure gives clients a predictable rhythm. They know that Monday brings a sprint kickoff. Wednesday brings a brief status signal. The day before the demo, they know what to expect. The day of the demo, they get a decision record.
Predictable rhythms reduce reactive communication. A client who knows a message is coming Wednesday doesn’t check Slack Tuesday evening.
The Four Messages
1. Sprint Kickoff (sent Monday morning)
Purpose: Align on sprint goals and surface blockers before they compound.
The kickoff message is short: four sections, three to five sentences each. It confirms what we’re building this sprint, what the demo will show, what I need from the client before midweek, and what we’re explicitly not building.
That last section matters as much as the others. AI projects invite feature additions because clients see a working model and immediately think of related things it could do. Writing “not in scope this sprint” at the start is a gentle way to set the boundary before anyone has to enforce it.
Template:
Sprint [N] kicks off today. Here's what we're building.
Sprint goal: [one sentence describing the feature or integration the sprint produces]
What you'll see at Friday's demo: [one sentence describing the specific thing the client
will interact with]
What I need from you by Wednesday: [specific ask: access, test data, a decision, or nothing]
Not in this sprint: [one or two explicit exclusions]
Talk to you mid-week with a progress signal.The whole message takes two minutes to write because the sprint should already be scoped. If writing the kickoff takes 20 minutes of digging through planning notes, the sprint planning wasn’t finished.
2. Mid-Sprint Signal (sent Wednesday)
Purpose: Confirm we’re on track, or surface an issue while there’s still time to respond.
This is the most underrated message in the sequence. Three sentences. Sent day 3 of a 5-day sprint. In my experience running AI builds, it prevents more late-sprint escalations than any other single communication.
I use a simple conditional: either we’re on track or we’re not. If we are, I say so in one sentence and mention one specific thing that’s going well. If we’re not, I name the issue and the current plan.
Template (on track):
Mid-sprint signal for Sprint [N]: we're on track. The [model / integration / pipeline]
is performing as expected on the test set. Friday's demo is a go.Template (issue surfaced):
Mid-sprint signal for Sprint [N]: we hit a problem with [specific component]. It's
returning [specific behavior] on roughly 30% of inputs, which isn't demo-ready yet.
Current plan: [two sentences on what we're doing about it]. I'll give you a clearer
picture by Thursday morning on whether this affects Friday's scope.The second version sounds alarming written out. It isn’t alarming to receive. A client who gets that message on Wednesday has time to respond, adjust expectations, or offer access to data that might help. A client who hears the same information at Friday’s demo has none of those options.
Surprises at demos damage trust. Surprises on Wednesday build it. That’s counterintuitive, but I’ve seen it consistently. The Agile Alliance’s framing of sprint reviews as inspection events captures half the point; the other half is what happens before the inspection if you communicate mid-sprint.
3. Demo Prep Note (sent the evening before the demo)
Purpose: Prime the client to engage, not just observe.
Most clients arrive at AI demos as spectators. They watch the PM interact with the system, nod when things look right, and ask questions afterward. That’s a fine demo. It’s also less useful than one where the client tests their own scenarios.
The demo prep note is a short message asking them to bring three real queries, inputs, or cases from their own business. Not examples I provide. Theirs.
Template:
Quick note before tomorrow's call. Here's what to expect: [two sentences on what
feature we're demonstrating].
One ask: bring three real examples from your own work to test live. The model handles
our test cases well. What matters is how it handles yours.
[Staging URL or meeting link]. See you at [time].The prep note also surfaces any known rough edges. If a feature has a latency issue or an intermittent edge case, I mention it now. Clients who arrive calibrated to realistic expectations react better than clients who arrive expecting a polished product demo.
4. Decision Capture (sent same day as the demo, within 2 hours)
Purpose: Lock in verbal agreements before they become disputed memories.
Every demo produces at least one decision. Sometimes it’s small: we’re keeping the current output format. Sometimes it’s sprint-shaping: we’re adding the export feature next sprint, and the dashboard moves to sprint six.
Either way, those decisions need to be documented the same day.
The decision capture is not the sprint handoff document. The full handoff covers everything: what shipped, what changed, what’s next, blockers, and decisions needed. That goes out within two hours of the sprint review. The decision capture is narrower: just what was agreed in today’s demo, written down while it’s still fresh.
Template:
Decisions from today's demo:
1. [Decision]: [one sentence on what this means for the next sprint]
2. [Decision]: [one sentence on what this means for the next sprint]
If anything looks wrong, reply and I'll correct it. Otherwise, I'll incorporate
these into Sprint [N+1] planning tonight.Clients rarely reply to correct something. But knowing they can changes the dynamic. The decisions stop being something I recorded and start being something we agreed on.
What Breaks When You Skip This
I ran a build once where I let the communication cadence slip for two sprints. The client was responsive, the team was performing well, and I misread “no questions” as “no concerns.”
By sprint four, the founder had a list of eight items he believed were still in scope. Three had been explicitly deprioritized in sprint two. We’d agreed verbally during a demo call. I hadn’t sent the decision capture message that afternoon.
Resolving the disagreement cost a full planning session and two days of re-scoping. Not because the client was being unreasonable. Because a verbal agreement made in week three had become two different memories by week seven.
Four messages per sprint is roughly 20 minutes of writing. The conversation that replaces them takes four hours and costs more than time.
FAQ
How much communication is too much for an AI development project?
Enough to prevent surprises, not so much that it requires daily calls. Four touchpoints per sprint covers the key uncertainty windows in an AI build without requiring constant client attention. Beyond that threshold, clients shift their focus from outcomes to process monitoring, which is my job, not theirs.
What should the first message from my AI development company be?
A sprint kickoff message that states: what will be built this sprint, what you’ll see at the demo, and what they need from you. If the first message is vague about scope, that vagueness compounds over the sprint. Ask your vendor to send this on day one. If they can’t produce it without a lot of back-and-forth, that tells you something about how the sprint was planned.
What happens if the AI isn’t working by mid-sprint?
That’s what the mid-sprint signal is designed to surface. A team running this communication framework sends a message naming the issue and the current plan on day 3. If you’re finding out about a problem during the Friday demo, that’s a process failure: either the team didn’t know mid-sprint (internal monitoring gap) or knew and didn’t tell you (client communication gap). Either version is worth asking about directly.
Do I still need a weekly demo if I’m getting these four messages?
Yes, because the messages and the demo do different jobs. Messages keep you informed. The demo changes your understanding of what’s possible. Clients update their product thinking after seeing a live AI system in ways that written status updates can’t produce. The weekly demo format is designed to create that reaction efficiently in 30 minutes.
How do I know if my AI development company is communicating proactively vs. reactively?
Proactive communication arrives on a schedule before you ask. If you’re always the one initiating status checks, the cadence is reactive. A simple test: at the start of the next sprint, don’t send any messages. See if a kickoff note arrives on Monday. If it does, the pattern is in place. If it doesn’t arrive until you ask, you have your answer.
Running discovery calls for AI projects and trying to figure out how to evaluate vendors? Book a 30-minute call and I’ll walk you through our full sprint process, including what these messages look like on a real project.
