What should an agent know before it starts work in a shared codebase?
By Soumen Sarkar · October 2026
Short answer: Before it changes shared code, an agent should know what is being changed in that part of the code right now, the decisions that stand there, what changed recently, what was tried and dropped, and which assumptions are still open. Together that is an area brief, and it belongs in the agent's context before its first edit.
Why does it matter before the first edit?
An agent can read the code, but the code only shows what is there now. It doesn't show what another session is halfway through changing, why a strange-looking choice was made on purpose, or what was tried last week and abandoned. An agent that doesn't know these things undoes good decisions, repeats dead ends and builds on code that is about to change.
Learning it after the first edit is too late: by then the agent has planned around the wrong picture. So the context has to arrive before the agent writes anything in that part of the code.
What are the five things it should know?
- What is being changed there right now: by whom, the goal, the plan and when it is expected, so the agent builds on that work rather than around it.
- The decisions that stand: each with its reason, so the agent follows them instead of deciding again.
- What changed recently: this week's landed work, so it isn't surprised by fresh code.
- What was tried and dropped: so it doesn't spend an hour on an approach that already failed.
- Open assumptions: calls still waiting for someone to confirm, so it knows which ground is soft.
What does a brief look like?
Say an agent is asked to add SMS reminders in Notifications · lib/notifications. A useful brief is short:
Notifications · lib/notifications
Being changed now: Priya's session is merging the email and push send
queues into one. Plan: one queue, one retry policy. Expected Thursday.
Decisions:
- Every send goes through the queue, never straight from a request,
because request timeouts were dropping messages.
Tried and dropped:
- Per-channel retry settings: too many combinations to test.
Open assumptions:
- Quiet hours (10pm to 7am local) apply to every channel. Not yet confirmed.
With that, the agent adds SMS as a new channel on the merged queue, applies quiet hours, and states one assumption of its own: SMS has the same retry limit as push. It has not touched the old email queue, which is about to disappear.
What doesn't it need?
It doesn't need the whole history of the area, every conversation about it or the code it can read for itself. A brief is a page, not an archive. Older decisions that nobody has relied on for months should still appear, but marked as worth checking, because they may no longer hold.
How does an agent get this automatically?
With Campfyrr in Claude Code, a hook gives a session the area brief the first time it reads or edits a part of the code. Areas are named from their folder, like the example above, and can be renamed. Recent decisions and ones still in use come first; one that nobody has written to or relied on for four months is shown with "check it still holds". To write the same summary by hand, start from the area summary template.
Words used here
- Area brief: An area brief is what a person or agent is told the first time they touch a part of the code: what's changing there now, what was decided, and what was tried.
- Decision: A decision is a call made in the work, recorded with its reason at the moment it is made, so it travels to everyone who touches the same ground.
- Work in progress: Work in progress is work under way, shown with its plan, so others build on it rather than around it.
The principle behind this: Keep moving: The work never waits, and neither do we.
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).