Making Claude handle every system yourself: when the glue becomes the project
By Soumen Sarkar · October 2026
Problem. "We tried to make Claude handle all our moving systems ourselves, and the glue became the project."
When a team wires Claude into Slack, the tracker, GitHub, docs and CI itself, the glue grows with every tool and breaks with every change. A shared layer of hooks and one MCP server can carry the team's context to every session, so you keep only the connections that do real work. It doesn't replace your tracker, your CI or the tools' own connectors.
Because every connection is a small project of its own. Claude is a superb collaborator, so the team wants it everywhere: reading the ticket, posting to Slack, opening the pull request, checking the docs, reacting to CI. Each of those is a server to configure, a token to store, a script to keep working and a habit to teach.
Anthropic named the problem when it introduced the Model Context Protocol in November 2024: "Every new data source requires its own custom implementation, making truly connected systems difficult to scale." MCP fixed the plug. It didn't decide what your team's agents should know, or keep that the same on every laptop.
What does the glue look like on a real team?
It grows one reasonable step at a time:
- A GitHub MCP server, added by one developer with a personal token. Claude Code's MCP guide shows exactly this, and it works well.
- A Slack bot or webhook script, so the lead hears what shipped.
- A shell hook that injects "read the decisions doc first" at session start. Claude Code hooks run at points like session start and after each tool call, which makes them the right place for it.
- A long CLAUDE.md that tries to hold the team's decisions, and a script that copies it between repositories.
Each piece is fine. Together they're a system nobody owns. They live in different people's settings, so two teammates' sessions see different things. When a tool changes its address or its token, something quietly stops, and the person who wrote it is the only one who notices.
What does a shared layer take off your plate?
The part that is about the team, not about any one tool. Claude Code already lets you share MCP servers through a checked-in `.mcp.json`, and plugins bundle hooks, skills and MCP servers into one install. Campfyrr uses both: one plugin, one MCP server, one token.
That one install gives every session:
- A brief at session start: what changed since the last session, open questions and the team's rules.
- Area briefs the first time a session reads or edits a part of the code: work in progress there, the decisions that apply, what was tried.
- Reasons for each change on commit, with the link added to the pull request when the session opens it.
- Plain-language updates, with a daily update and milestones posted to the project's Slack channel through an incoming webhook.
- The same tools in every client. The MCP server works from Claude, Claude Code, Codex and Cursor (see the guide for other clients).
Our own repository runs on exactly this. Its instructions say: "The MCP connection (.mcp.json) and the hooks (.claude/settings.json) read the token from the CAMPFYRR_TOKEN environment variable. Never commit a token." Six hook events and one server connection replace the scripts we would otherwise keep alive ourselves.
What doesn't it replace?
Be clear about this before you remove anything:
- Your tracker. Campfyrr doesn't sync tickets. Keep the tracker, and its MCP server if Claude needs to read issues.
- Your CI. Campfyrr doesn't run tests or builds. Your pipeline stays where it is.
- GitHub's own tools. If agents open issues or review comments, keep the GitHub MCP server.
- A Slack reader. Campfyrr posts to Slack. It doesn't read your channels.
- Audit logs. It has none yet. It never stores your code; /trust lists what it keeps.
So the shared layer removes the glue that carries context between people and sessions. The connectors that act on a tool stay, and get simpler, because they no longer have to carry the team's memory too.
Where do we start?
- List every hook, script and MCP server your team runs today, and who owns each.
- Mark each one "carries team context" or "acts on a tool".
- Install Campfyrr from /connect for one teammate and yourself. The two-minute setup has the steps.
- Remove the context scripts that the briefs now cover.
- Keep the tool connectors, and move them into a shared
.mcp.json so every session sees the same ones.
For the background, read what MCP does for a team and Claude Code hooks for teams. The principle behind it is answer it yourself: every session looks in one place first.
Everything on this problem
- Comparison: Campfyrr vs Conductor: parallel agents that don't collide, and don't contradict: If you want to run many coding agents at once without them trampling each other's files, use Conductor. If those agents keep making calls that contradict each other, use Campfyrr. Most developers running agents in parallel on a team end up with both problems.
- Comparison: Claude Code memory vs team memory: when CLAUDE.md and auto memory stop being enough: If you work alone, or each person owns their own repository, Claude Code's CLAUDE.md, auto memory and Projects are enough: keep using them. If a second person's sessions change the same product, a call made in your session has to reach theirs the same hour, and that's what shared team memory like Campfyrr adds. Most teams start with the first and grow into the second.
- Comparison: Building your own Claude glue vs a shared layer: what to build, what to hand over: If you need Claude to act on a tool, build the glue yourself: an MCP server, a hook, a Slack webhook. If you need every session to know what the team decided, use a shared layer like Campfyrr, because that glue breaks quietly. Most teams need both.
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).