The feedback that never reached the agent
By Soumen Sarkar · October 2026
Story. Customer feedback that lives in a chat thread never reaches the next agent session, so the same flaw gets built again. Let the person who heard it answer the agent's assumption from a link, and record it against that part of the product, so every later session is briefed on it.
What happens to feedback that stays in Slack?
This story is a scene, built from how teams work with agents today. What comes after it is real.
It's a Monday, a little after nine, and I'm sitting at the end of the support desk with a cup of tea going cold. Leila leads support for a small company that makes stock-tracking software for independent shops: a bike shop, two bakeries, a garden centre. Across the room, Ben's team of three engineers is getting their sessions going.
Leila's first call of the day is with Marco, who runs the garden centre. Last week the team shipped a new export: every product and its stock level, as a spreadsheet file. Marco loves it. But when he opens it, his barcodes are wrong. His suppliers' codes start with a zero, and the spreadsheet has quietly dropped it. "0412" has become "412", and his supplier's ordering system doesn't recognise any of them.
Leila thanks him, writes it down and does exactly the right thing. She posts it in the team's product channel, with Marco's words: "Codes that start with zero lose the zero when we open the export. Suppliers reject the order." Ben reacts with an eyes emoji. Priya, the product manager, replies: "Good catch, let's make sure exports keep codes as text." Ben fixes the export that afternoon. His session reads the thread he pastes in, keeps the codes as text, adds a test and ships before five.
It's a good Monday. The feedback arrived in a day, and the fix shipped the same day. Everyone goes home pleased.
I'm back on Thursday. This morning, Sara, the newest engineer, is building the thing the bakeries have been asking for: an export of supplier orders, so they can send them straight on. She writes four clear lines for her agent and lets it go.
I watch it work, and it's a pleasure to watch. It reads the order code, finds the supplier fields and builds the export cleanly, with tests. By half past eleven it's done. It even says, in its summary, that it's treating each supplier code "as a number, matching the stock count field."
Nobody blinks at that. Sara wasn't in Monday's thread. Her session started this morning with a clean slate, as every session does. It read the code, the project's instructions and Sara's four lines. Monday's lesson was in none of them. It was in Slack, three days and two hundred messages up the channel, and in Ben's session from Monday, which has long since closed.
At two, the order export ships. At ten past three, Leila's phone rings. It's one of the bakeries. Their flour supplier has rejected an order.
I watch Leila open the file. She sees it at once: the zero is gone again. She doesn't say anything for a moment. Then she says, quietly, "I told them this on Monday."
She's right, and so is everyone else. Leila passed the feedback on within an hour. Priya made the call. Ben fixed it well. The agent did exactly what it was asked, and it even said out loud what it was assuming. The feedback just never reached the agent doing the next change. It reached the people, and stopped there.
The afternoon goes on a second fix and a second apology. Sara is mortified, though nothing here was hers to know.
I come back the following Thursday.
The team has changed two things. When an agent isn't sure of something, it states its assumption and keeps going, and the assumption goes to the person most likely to know. And when someone hears something from a customer that should last, it goes into the team's record, against the part of the product it's about, not just into a channel.
At nine, Leila adds one line to the export area, the way she'd post it in Slack: "Supplier and barcode codes can start with zero. Always keep them as text. Marco and the bakeries both hit this." It takes her a minute.
At ten, Ben starts the next export the shops want: a price list for their tills. Before his session touches the export code, it's briefed on that area. Leila's line is at the top. I watch the agent plan the export with every code kept as text, and say so in its plan.
Halfway through, it hits something nobody has written down. It states the assumption, and keeps going: "Assuming prices are exported without the currency sign, as the till import expects."
The assumption goes to Leila, because she last added context to this area. Her phone buzzes at 10:40, between two calls. She opens the link. She doesn't read code, and she doesn't need to. She knows the tills. She picks "Correct it…" and writes one line: "The bike shop's till wants the sign. The bakeries' doesn't. Ask which till on export."
At its next turn, the agent reads her answer. I watch it add a choice to the export screen and a test for each till. Ben didn't relay anything. Nobody opened a ticket or scheduled a call.
At four, the price list ships. Leila sends Marco a short note that it's ready. On Friday, the phones are quiet. On Monday, Sara starts another export, and her session is briefed on both of Leila's lines before it writes anything.
Here's what I want you to notice
The agents were brilliant both weeks. Sara's agent even stated the very assumption that went wrong. What broke was the path between people and the work.
Look at where Monday's feedback went. It went to the right people, fast. Leila posted it within the hour, and Priya made the call. But a chat thread is written for the people reading it that day. A session that starts on Thursday doesn't read it. So the lesson lived in two places: a channel nobody scrolls back through, and a session that had already closed.
Stop treating "posted in Slack" as "the team knows". The team is now people and sessions, and the sessions start fresh every time. Feedback that should last has to land where the next session reads it.
And notice what it cost Leila the second week: one line in the record, and one line from a link, between two calls. She didn't learn a new tool or join a standup. She answered in her own words, at the moment her answer was cheap, and it reached the agent without anyone carrying it.
What's the proof?
- Every session starts fresh. Claude Code's memory docs say: "Each Claude Code session begins with a fresh context window." What carries across is what's written where sessions read, such as project instructions. A chat thread isn't one of those places.
- A hook can put the answer in front of the agent. Claude Code's hooks reference says the
UserPromptSubmit hook fires "when a prompt is submitted, before Claude processes it," and can add context alongside it. Campfyrr's hook uses that to tell a session what was answered since its last turn. - Fast building needs fast feedback. Google's DORA team, in its 2025 report, writes that "AI accelerates software development, but that acceleration can expose weaknesses downstream," and that without fast feedback loops, "an increase in change volume leads to instability."
- This is what Campfyrr does today. A session calls
state_assumption and keeps working. Each assumption gets a page of its own, where anyone on the team picks "Right, keep going", "Correct it…" or "Not mine to check". What the business knows goes in with add_business_context, against the part of the product it affects, and later sessions there are briefed on it.
What Campfyrr doesn't do: it doesn't read your Slack, tickets or calls for you. Someone still has to bring the feedback in, in a line. It doesn't replace your tracker or your support tool, and it doesn't run tests.
What do I do on Monday?
- Pick the last piece of customer feedback that changed how something should work.
- Find the part of the product it's about.
- Write it down there in one line, in the customer's words.
- Let the sessions state their assumptions for a week.
- Send each assumption's link to the person who'd know, including support.
- Ask them to answer in one line from the link.
- Check the next session's brief for the feedback before it starts work.
Then count how often the same customer problem comes back after it's been fixed.
For the problem in full, read we ship in a day, but feedback takes a week and what the business knows reaches the agents too slowly. For the steps after a wrong guess, read what happens when an assumption is wrong. The idea behind it is fix forward, and the feature nobody reviewed tells the same story from the review side.
The problem this answers: Feedback is broken: "We ship in a day, but feedback still takes a week, and half of it never reaches the agents."
The principle behind this: Fix forward: We don't guard the gate. We correct the course.
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).