For designers: your decisions reaching the agents that build them
By Soumen Sarkar · October 2026
For you. Agents can read a design file, but not the calls behind it. Campfyrr lets a designer put a design call on the part of the product it affects, so every session working there is briefed on it, and lets sessions publish a plan or sample page you review before it ships, on a free seat.
What does a designer's day look like right now?
Your engineers run Claude Code, often several sessions at once. A screen you hand over in the morning can be working by the afternoon. The agent gets the layout right. What it misses are the calls you made along the way: why the empty state stays quiet, why red only ever means an error, why that button is a link and not a button.
Your day probably goes like this:
- The design reaches the agent, the reasons don't. Figma's MCP server lets Claude Code read design context such as components, variables and layout data (Figma's guide). That's a real step forward. But the file shows what you drew, not the rule you'd apply to a screen you haven't drawn yet.
- You repeat the same call in different threads. You tell one engineer in Slack. Their session hears it. Tomorrow's session, in someone else's hands, doesn't.
- You see the build when it's done. By the time you click through it, the agent has moved on to the next change, and your note becomes a new ticket.
None of this is the agents' fault. They are the best collaborators we've ever had, and they build what they're given, quickly. What breaks is between people: your calls don't reach the work in time, and the work doesn't reach you until it ships.
What changes with Campfyrr?
Campfyrr is shared team memory for Claude Code. For a designer, two things change.
Your design calls live on the part of the product they affect
Write a call once, in your own words, on the area it belongs to: "Reading surfaces stay white with charcoal text." Add it from "Where are we?" on Activity as context for that area. Every session that works there later sees it in its brief before it changes anything, and the newest call on an area is the one that counts. Engineers' sessions record design calls the same way when they make one with you. See where decisions should live and how decisions reach every agent.
You see what's being built before it ships
Ask a session to publish its plan or a sample page as a link before it starts on the real thing. You read it in a minute and say "that header is too heavy" while it's still cheap to change. See how to publish a plan from Claude Code.
What does that look like for real?
Here is one from our own record. On 16 October our new site theme arrived first as "a sample page to review it", marked in the commit as "not used by any page yet". It went through several versions that day: time of day and weather split into two layers, the shapes taken from "the Lucide icons this app already uses" instead of drawn by hand, a flat page instead of boxes. Each earlier version was kept so it could be restored. Only after those reviews did the next commit read "The whole site takes the weather theme". The design calls were settled on a page anyone could open, not discovered in production.
What doesn't Campfyrr do?
It doesn't replace Figma or any design tool, and it doesn't read your design files. It doesn't check a build against your design or take screenshots for you. Settling a full decision from a link isn't built yet; answering an agent's assumption from its link is.
What are the first three things to try?
- Ask an engineer to invite you to the team's project on Campfyrr.
- Add your most repeated design call as context on the area it affects.
- Ask the next session on that area to publish a sample page before it builds.
What does it cost you?
Nothing. Designers, product managers and anyone else who only reads, comments, answers or adds context are free. Teams pay for the developers whose sessions connect, and everything is free for everyone during early access. See pricing.
For the problems behind this page, read deciding what to build and when business context arrives late. If you work beside a PM, read for product managers. For the habit, read let the work speak.
The problem this answers: Deciding what to build: "Development is fast now. Deciding what to build, clearly, is the slow part."
The principle behind this: Let the work speak: Our work explains itself, so nobody ever has to come and ask us.
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).