Silos at agent speed: when engineering moves fast and everyone else doesn't
By Soumen Sarkar · October 2026
Problem. "Engineering moves at agent speed, but product, design, QA and the business still work in separate silos."
When agents make building fast, the gaps between engineering and everyone else become the slow part. Teams close them with one shared record and one plain "where are we" page anyone can open, instead of status meetings.
Why does the rest of the company feel behind?
Because it works at a different speed. With Claude Code and other agents, an engineer takes an idea to a working change in an afternoon. Product, design, QA, sales and support still work in their own tools and on their own schedules. Each team is quick inside its own walls. The slow part is the space between them.
Agents make that space matter more. Google's DORA team puts it plainly in its 2025 report: "AI doesn't fix a team; it amplifies what's already there." The biggest return comes from "the alignment of teams", not the tools (DORA 2025 report announcement). When building speeds up and handoffs don't, handoffs become most of the wait.
Where do the silos show up now?
- Product writes a spec on Monday; by Tuesday it's built exactly as written, vague parts included.
- Design comments on a mock-up while the real screen has already moved on.
- QA gets a finished change to test, with no say in the plan behind it.
- Sales promises a customer something that changed yesterday.
- Support learns what shipped from the first confused ticket.
Nobody here is slow. The work just no longer waits for anyone.
What does it cost?
Mostly, time spent asking. Atlassian's State of Teams 2025 report, drawn from 12,000 knowledge workers and 200 executives, found that leaders and teams lose about a quarter of their time just searching for answers (Atlassian). At agent speed, answers go stale sooner, so people ask more often: a status meeting, a Slack thread, a quick sync. The tech lead becomes the router.
It also moves review to the end: the business sees the work last, sometimes in front of a customer.
What do teams do about it?
The teams that keep up stop passing status from person to person and keep it in one place everyone reads, people and agents alike.
- One shared record. Decisions, assumptions, plans, test results and business context in one place. Agents read it; people open it from a link.
- One plain "where are we" page. What's being built, what landed and what's waiting on whom, in words a non-engineer follows. The status meeting becomes a link.
- Questions go to the person who knows. An agent states what it assumed and keeps working; the product manager or support lead confirms or corrects it.
Meetings stay, for the decisions only people can make.
What does Campfyrr do, and what doesn't it?
Campfyrr is shared team memory for Claude Code. Every session logs what it did and why, in plain words, to the team's record. From it, the rest of the company gets:
- "Where are we on X?": what's under way, what landed in two weeks, what's waiting on whom, the latest plans and results, and what the business told the agents, at one link.
- Published pages: an agent turns a plan, test results or a sample output into a page, so design, QA and sales see it before it ships (how to publish from Claude Code).
- Assumptions answered from a link: a founder or product manager keeps, corrects or passes on an assumption from its own page, and the answer reaches the agents.
- Business context on a part of the product: a customer's words, a pricing call or a deadline. The next agent working there is briefed on it (how customer requests reach agents).
Business teammates who read, comment and answer are free (pricing).
What it doesn't do: it doesn't replace your tracker, your design tool or CI, and it doesn't run tests. It has no audit logs yet. Settling a decision from a link isn't built yet; answering an assumption from a link is. Keep talking in Slack; Campfyrr is where everyone sees the same thing.
Where do I start?
- Connect your engineers' Claude Code sessions on /connect.
- Let the agents log a few days of work.
- Open Activity and choose "Where are we?".
- Copy the link and send it to product, design, QA, sales and support.
- Replace the next status meeting with that link.
- Ask one business teammate to add one customer's words to the part of the product it affects.
For more on the people outside engineering, read how people outside engineering follow agent work. For the idea behind it, read 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.
- Comparison: Campfyrr vs Superconductor: share one agent run, or keep every run in step: If you want product, design and engineering in the same agent run, watching and steering it together, use Superconductor. If your runs on the same product keep making calls that contradict each other, use Campfyrr. Many teams have both problems.
- 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.
- 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).