Showing non-technical teammates what the agents built
By Soumen Sarkar · October 2026
Problem. "I can't easily show non-technical people our plans, test results or sample outputs."
Publish the work as pages people can read: the plan before it starts, test results and a sample output as it lands, each with the point first in plain words and a link to share. Campfyrr does this from Claude Code; it doesn't run your tests or replace your demo.
Why is it so hard to show people what we built?
Because the work lives where only engineers can read it. The plan is in a developer's Claude Code session. The proof is a pull request, a diff and a wall of test output. A founder, a product manager or a support lead can't open any of that and tell whether it's what the customer asked for.
So the lead translates. They screenshot, summarise in Slack, book a demo, or answer "is it done?" one person at a time. Each answer is lost by next week, and the next change starts the same loop again.
Why does it matter more now?
Agents are the best collaborators a team has had. They turn a plan into a working change in an afternoon, so there is more to show, more often. The usual ways to show work run on a slower clock. Scrum's Sprint Review, where the team presents its results to key stakeholders, is timeboxed to at most four hours for a one-month sprint (Scrum.org, what is a Sprint Review). That's a good conversation, but at agent pace it shows dozens of changes after they've shipped.
When the business sees the work late, the review falls on whoever meets it first, often a customer. See when review falls on the business.
What do teams do about it?
- They paste it into chat. It's quick, but it gets lost in a thread, and people outside engineering can't tell what the output means.
- They hold more demos. Useful for discussion, but each demo costs everyone an hour and shows the work after it's built.
- They write status in the tracker. "Done" says nothing about what the change does or how it was checked.
What works is simpler: each thing worth showing becomes one page with a link. It starts with the point in a plain sentence, such as "all refund tests pass, including partial refunds", and puts the detail underneath for whoever wants it. People talk about it anywhere, in Slack, a meeting or a call, but they all look at the same page.
Three kinds of page cover most of it:
- The plan, before the work. Anyone who knows better can say so while it's still cheap to change.
- Test results, when a change is risky. Proof a non-engineer can read, not a log.
- A sample output. An example email, export or screen that support or sales can judge in a minute.
What does Campfyrr do, and what doesn't it do?
- Publishing from Claude Code. A session runs
/campfyrr:publish, or you just ask Claude to publish the plan. Claude writes the page point first and returns the link (how publishing works). - Labelled by kind. Each page is marked as a plan, test results or an output, and appears on the project's Activity.
- Team or anyone with the link. Pages go to your signed-in team by default. Choose "anyone with the link" to show someone outside it, such as a customer.
- Answers that reach the agents. When an agent states an assumption that's a business call, the right person confirms or corrects it from its own link, and the agent reads the answer at its next turn.
We work this way ourselves. The instructions every Campfyrr session in our own repo reads include this line: "To show a plan, test results or a sample output to teammates, including people who don't read code, publish it and share the link."
What Campfyrr doesn't do: it doesn't run your tests or publish their results on its own. A session publishes them when you ask. It doesn't replace your tracker, CI or demo, and it has no audit logs yet. Pages hold only what the session chooses to publish, so keep tokens and customer data out of them.
Where do I start?
- Install Campfyrr for the team from /connect.
- Invite one business teammate. People who only read and answer are free (pricing).
- Ask the next session to publish its plan before it builds.
- Send the link to the person who talks to customers.
- Ask for test results or a sample output when the change touches money or customers.
For testers, see testing left out of planning. For more on what non-engineers should see and when, read showing non-technical teammates the work. The idea behind it is let the work speak.
Everything on this problem
- Field note: Field note: building the business layer in a week: In one week we turned Activity into one read-only feed, put the business teammates into the plan, and built the pieces that let them see and answer the work from a link. We also changed our price, our philosophy's name and our content plan, and shipped a blank-page bug we fixed three times.
- Story: The feature nobody reviewed until the customer did: When a feature is built and shipped in a day, the first person with the customer's context to see it is often the customer. Show the plan and a sample output to the person who knows the customers before it ships, and send them the agent's assumptions to answer in a line.
- Problem: When building is easy, review falls on the business: When agents build faster than anyone can check, review falls on whoever meets the output first: support, sales, the founder or the customer. Move review earlier: show the plan and a sample output before it ships, and send each assumption to the person who knows the answer.
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).