Getting what the business knows to the agents, fast
By Soumen Sarkar · October 2026
Problem. "What the business knows reaches the agents too slowly."
Business context reaches agents late because it travels from person to person before it reaches the work. Attach it to the part of the product it affects, in the business's own words, so every agent working there is told before it changes anything.
Why does what the business knows reach the agents so slowly?
Because it has to be passed along by hand. A customer says something important on a call. Sales agrees a price. The founder promises a date. Each of these lives in someone's notes, a Slack thread or a meeting. To reach the work, someone has to remember it, find the right engineer and repeat it. That engineer then has to tell a session.
The agent can only build with what it's given. Claude Code's own docs say that "each Claude Code session begins with a fresh context window." So a session that starts on Thursday knows what's written where it reads, and nothing from Tuesday's call. Nobody here is slow. What breaks is the path between the people who know and the work.
Why does it matter more now?
Because an agent can build the wrong thing by lunch. When building took a week, a late word from sales still arrived in time. Now the change is done before the call notes are typed up.
Google's DORA team names this directly. Their AI Capabilities Model lists "AI-accessible internal data" as one of seven capabilities that amplify AI's benefits, saying company-specific context turns an AI tool into "a highly specialized and valuable tool for your developers." The same model lists a user-centric focus, and warns that without it, teams using AI "may just be moving quickly in the wrong direction." What the business knows about customers is exactly that focus.
What do teams do about it?
Teams that keep up don't add more meetings. They put the business's words where the agents already read:
- Write it once, in the business's own words. "The customer needs refunds to include shipping" is better than a summary of a summary.
- Attach it to the part of the product it affects. A pricing call belongs with billing, not in a general channel. The agent working on billing is the one who needs it.
- Say what it means for the work, if you know. One line is enough: "Show the shipping line on the refund screen."
- Let the newest word win. When the price changes again, the new call replaces the old one where agents read it.
- Let the agent ask through assumptions. When something is still unclear, the agent states what it's assuming and keeps going. The person who knows corrects it. See how customer requests reach agents.
What does Campfyrr do here, and what doesn't it do?
Campfyrr gives business teammates a way to tell the agents directly:
- Anyone on the team adds a customer's words, a pricing call or a deadline to a part of the product, or to the whole project. They do it from the project's "where are we" view with Tell the agents something, or by telling their own Claude session, which records it.
- Before an agent changes that part of the product, its area brief lists it under a heading that reads: From the business (customers, pricing, deadlines; build with these in mind).
- Each entry is recorded like a decision, with a link anyone can open. The newest word wins.
What it doesn't do: it doesn't listen to your calls, read your inbox or pull from your CRM. Someone has to add the context, in a sentence. It doesn't replace your tracker or CI, and it has no audit logs yet.
Where do I start?
- Install Campfyrr from /connect and invite one teammate who talks to customers.
- Open the project's "where are we" view.
- Choose Tell the agents something.
- Add one thing a customer said this week, against the part of the product it affects.
- Ask the next session in that area what it was told.
Context that arrives early helps agents build the right thing first. For what happens after something ships, see the feedback is broken hub. For turning that context into clear calls, see deciding what to build, and for checking the output before customers do, see review falls on the business. The why behind it is answer it yourself.
Everything on this problem
- Problem: Development is fast; deciding what to build, clearly, is the slow part: When an agent builds a feature in an afternoon, a vague spec turns into the wrong feature by lunch. Product teams keep up by writing each decision down with its reason, putting what the business knows on the part of the product it affects, and reading the plan before anything is built.
- Problem: We ship in a day, but feedback takes a week: 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.
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).