How do I give every agent session context automatically?
By Soumen Sarkar · October 2026
Short answer: Give every agent session context automatically by loading it at fixed moments instead of relying on the agent to fetch it: a brief of the team's state when the session starts, a brief for each part of the code the first time the session touches it, and news at each turn. In Claude Code, hooks run at exactly those moments.
Why not let the agent fetch context itself?
It can, and it should be able to. But an agent only searches for what it suspects exists. It won't look up a teammate's half-finished change it has never heard of, or a decision made yesterday in a part of the code it hasn't opened yet. Context that waits to be asked for arrives late or not at all.
Context loaded at fixed moments arrives whether or not anyone thinks to ask. Nobody has to remember, which is the only way it works across dozens of sessions a day.
Which moments matter?
- When the session starts: what changed in the team since this person's last session, and their own unfinished work and handoffs at the top.
- The first time it touches a part of the code: what is being changed there now, the decisions that stand, what was tried and dropped, the open assumptions. This is the area brief.
- Each turn: anything new for this session, such as an answer or correction to one of its assumptions, or work it built on that has just landed.
- When it stops: the reverse direction, a handoff for whoever comes next.
How do I set this up in Claude Code?
With hooks: shell commands Claude Code runs at fixed points in a session. They are configured in .claude/settings.json, which can be checked into the repository so everyone on the team gets them. For example, to load a brief at the start of every session:
{
"hooks": {
"SessionStart": [
{ "hooks": [{ "type": "command", "command": "./scripts/team-brief.sh" }] }
]
}
}What a SessionStart hook prints is added to the session's context. Hooks on each prompt and around tool use can add context the same way, which is how a brief can arrive the first time a session reads a folder.
What does this look like in a session?
A developer starts a session to raise the file size limit in Uploads · lib/uploads. Before it does anything, the session is told that a teammate's work in progress is moving uploads to direct-to-storage links, expected tomorrow, with a plan that removes the server-side size check entirely.
So instead of raising a limit that is about to disappear, the agent sets the new limit in the shared config both versions read, and notes that it did so because of the migration. When the migration lands, the session is told what changed, and the limit still holds.
How much context is too much?
Keep each brief to what changes decisions: a page, not an archive. Long briefs push the actual task out of the agent's attention. Lead with what is happening now and what is decided; leave history to search.
What does Campfyrr set up?
Campfyrr's one-line Claude Code setup adds the connection and these hooks together: the session brief, the area brief on first touch, news each turn, and a handoff when the session stops or compacts. Other MCP clients don't get hooks; they follow the server's instructions and call the same tools.
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.
- Team record: The team record is everything a team has written down that a person or agent can search before asking: decisions, rules, handoffs, assumptions and the reasons behind changes.
- 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).