Telling your CEO and PM what shipped, without a meeting
By Soumen Sarkar · October 2026
Problem. "I can't tell my CEO or PM what shipped."
Let the work report itself. Each session records what it finished in plain words as it goes; at the end of each person's day that becomes a short update, the big calls post to Slack the moment they're made, and a "where are we" page answers anyone who asks.
Why can't you say what shipped this week?
Your CEO asks what shipped. Your PM asks whether the export fix is live and what you decided about trial limits. You know the team did a lot. Everyone ran several Claude Code sessions every day, and plenty landed. But the answer is spread across pull requests, commit messages and the heads of five people, and none of it is written for someone who doesn't read code.
So you either call a meeting, or you spend an hour stitching an update together from GitHub. Both cost you the time you wanted for the next piece of work.
Why does it happen now?
Because there is so much more to report. When every engineer runs several capable agents, more lands in a day than anyone can keep in their head. The work happens. The telling doesn't keep up.
The records that do exist are written for engineers. A commit message names the code it touched, with a prefix and a scope. That's right for review, and it means little to a founder. The translation into plain words falls on the lead, every time someone asks.
What do teams do about it?
The fix is to write the plain-words line at the moment the work is done, by whoever did it, and to let the update assemble itself.
- Record each finished change in one plain sentence. Outcome first, no file names. The agent that did the work knows best what changed and why, so it writes the line.
- Roll the day up on its own. At the end of each person's day, their lines become a short update: what got done, what was decided, what's next.
- Post only the moments that matter. A call made, a call reversed, a task finished. These go where the business already reads, often a Slack channel.
- Keep one page that answers "where are we?" Anyone can open it, at any time, without asking you.
We work this way on Campfyrr itself. The instructions in this repository tell every session: "After each change you finish, call `logwork` ... what changed and why, in plain words a non-engineer follows (outcome first, no file names or jargon) ... Your end-of-day update and the Record are written from these."_
What does Campfyrr do, and what doesn't it do?
Campfyrr writes the update for you from what the team and its agents already record:
- A daily update in plain words. At 18:00 in each person's time zone, their day is added to the project's "Daily update" page. It has a one-line summary, then what got done, what was decided or reversed, and what's next. Every line passes a plain-words check that strips file paths, function names and commands, whoever wrote it.
- Slack milestones. Connect a project to a Slack channel with an incoming webhook, which Slack ties to one channel. Each new decision posts there with the call and why, each reversal with the call that replaced it, and each finished task. Each person's daily update posts there too.
- "Where are we on X?" One page per project, from Activity. It shows what's being worked on, what's waiting on whom, what landed in the last two weeks, and the latest published plans and results. It has a link to pass to your CEO.
What it doesn't do: it only reports what is recorded in Campfyrr, so work nobody logged doesn't appear. It posts to Slack but doesn't read Slack. It doesn't replace your tracker or your release notes, and it doesn't know what's deployed; "landed" means finished and recorded. People who only read and answer join free.
Where should you start?
- Install Campfyrr from /connect for yourself and one teammate.
- Add the plain-words instruction above to your project's CLAUDE.md.
- Connect your project's Slack channel on Activity.
- Send your PM the "where are we" link instead of booking the next status meeting.
For more, read how can people outside engineering follow agent work? and what should an engineering lead look at each day?. When the business needs to see plans and results before they ship, see showing the work and silos at agent speed.
The principle behind it is let the work speak.
Everything on this problem
- Comparison: Campfyrr vs Slack Code and Linear: hearing what the agents assumed before it ships: If you want to watch and steer one agent task where you already work, use Slack Code or Linear. If you keep finding out what the agents assumed only after it shipped, use Campfyrr. Many teams have both problems.
- For you: For founders: seeing the work without being the last reviewer: A founder doesn't need to review every change an agent makes. With Campfyrr you read one plain-words page on what's in progress and what landed, answer the assumptions that are yours from a link, and put what customers told you where the agents will read it, on a free seat.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).