We ship in a day, but feedback takes a week
By Soumen Sarkar · October 2026
Problem. "We ship in a day, but feedback still takes a week, and half of it never reaches the agents."
Feedback is slow because it travels from person to person before it reaches the work. Close the loop: let whoever knows answer the agent's assumption from a link, so the answer reaches it at its next turn, and record corrections where the next session is briefed on them.
What does broken feedback look like?
A change goes out on Tuesday afternoon. By Friday, the reactions to it are in five places: a thread in Slack, two support tickets, a note from a sales call, and a comment the founder made in a meeting. Each one is useful. Few of them reach the agent that makes the next change in that part of the product. So the next change is built on what the team knew on Tuesday.
Nobody here is slow. Product answered in Slack. Support filed the tickets. Sales wrote it down. What breaks is the path between them and the work: feedback has to be found, summarised, turned into a ticket and passed to an engineer, who then has to pass it to a session.
Why does it hurt more now?
Because the building side got fast and the feedback side didn't. An agent can turn an idea into a working change in an afternoon. The answer to "is this what you meant?" still arrives at the pace of meetings and inboxes.
Two things follow:
- The gap fills with guesses. An agent that doesn't know something either stops and waits, or picks an answer. Picking is usually right, but only if someone can see the pick and correct it while it's small.
- Corrections don't stick. A product manager corrects something in a chat with one engineer. That engineer's session hears it. Tomorrow's session, run by someone else, doesn't.
What do teams do about it?
Teams that keep up tend to do three things:
- Make the agent's unknowns visible. The agent states what it's assuming and keeps going, instead of asking a question nobody sees.
- Send each unknown to the person who knows. That's often someone outside engineering: the product manager, support, the founder.
- Write the answer down once, where the next session reads it. Not in a chat, a call or one engineer's memory.
None of this needs a meeting. It needs a short path from the person who knows to the work. See what happens when an agent's assumption turns out wrong for the steps in detail.
What does Campfyrr do about it?
Campfyrr gives feedback that short path:
- Assumptions go to the right person. A session calls
state_assumption and keeps working. If the team's record already answers it, the answer comes straight back. If not, it goes to whoever made the closest decision, or last worked in that area. - They answer from a link. Each assumption has a page of its own. Send it to anyone on the team. They choose "Right, keep going", one of the likely answers, "Correct it…", or "Not mine to check" to pass it on. They don't need to open a terminal.
- The answer reaches the agent at its next turn. Claude Code lets a hook add context before each prompt is processed (Claude Code hooks). Campfyrr's hook uses that to tell the session what was answered and whether its assumption held. Nobody relays it.
- Corrections that should last go in the record. What the business knows, such as a customer's words, a pricing call or a deadline, is added as business context against the part of the product it affects. Every later session in that area is briefed on it before it changes anything. A correction that is really a rule becomes a decision in the same record.
What it doesn't do: Campfyrr doesn't collect feedback from Slack, tickets or calls for you. Someone still has to bring it in, in a line or by telling their agent. It doesn't replace your tracker or your support tool, and it doesn't run tests.
Where do you start?
- Connect one repository from /connect.
- Let the sessions state their assumptions for a day.
- Send each open assumption's link to the person who knows.
- Add one piece of customer feedback as business context.
- Check the next session's brief for it.
Business teammates join free (see pricing). For the product side of this, read how customer requests reach AI coding agents quickly. For why correcting beats approving, read fix forward.
Everything on this problem
- For you: For product managers: deciding clearly when agents build in hours: When agents build a feature in hours, a product manager's job is to decide clearly and early. Campfyrr lets you answer an agent's product assumptions from a link, put what you know on the part of the product it affects, and see what's being built in plain words, 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).