A 12 agent ↔ Linear ↔ Notion setup

The constraints

What made this hard?

What made it hard:

• Agent identity had to survive across sessions. Each specialist agent carries a distinct persona, write contract, and voice register. Re-loading that from scratch on every prompt is the failure mode I'd already lived through.
• The agents had to actually write to Notion, not just read from it. Notion is the substrate for the operating layer (10 DBs, locked read/write contract v1.0). Read-only agents would mean a parallel record in chat threads and no single source of truth.
• Per-project context isolation. Marketing OS, Delivery OS, and tincture-site each have different agent rosters, different repo CLAUDE.md instructions, and different write contracts. The platform had to load the right identity for the right context without me wiring it manually.
• History had to be addressable, not just retained. Slack threads technically retain history; nobody can find anything in them. The requirement was that every decision, every revision, every "we tried X and it broke" sat against the work, client, and project it referenced.
• Email integration. I work asynchronously with the agents the same way I work asynchronously with collaborators. If I could only reach them at a terminal, the asynchrony broke. The shape I needed: per-project email address that I could BCC or forward to from any inbox conversation, with the contents landing as a project update against the right work.
• Always-on availability. A laptop-bound setup is a laptop-bound setup. Linear comments left at 11pm sit until morning; a project email forwarded from a flight queues up behind me. The platform had to live somewhere I didn't have to be physically present for the work to happen.
• Linear couldn't hold everything. Linear is shaped for shipping and conversation. It doesn't carry the financial picture, the company handbook, the longer-horizon objectives, the additional task surface, or the daily dash. Those have to live somewhere queryable, structured, and not embedded inside an issue thread. So the constraint wasn't "pick one tool", it was "pick the two and run a mirror bridge between them cleanly enough that nothing falls through the gap."

The approach

How did Tincture frame the problem?

The strategic move was to stop trying to make one tool do two jobs, and instead pair two tools that were each shaped for one of them. Linear is shaped for ship-and-talk: threaded issues, assignees, project and cycle structure, resolved/unresolved state. Notion is shaped for state: 10 DBs with a locked read/write contract, the financial picture, the company handbook, the longer-horizon objectives. Neither tool, on its own, does the other's job acceptably. Paired, they do both.

The bridge is the Model Context Protocol (MCP), Anthropic's open spec, with Linear and Notion both shipping documented MCP server implementations against it. Each agent reaches both surfaces through MCP and writes against a per-persona contract that is tighter than its read access. The contract is what stops agents from clobbering the wrong DB; the read access is what lets them stay coherent across the operating layer.

Identity persists through repo-specific instruction injection at session start, so the same model loads as Mara in one repo and Sasha in another without manual re-briefing. Parallelism is safe because each Linear issue gets its own git worktree, so twelve agents can work concurrently without stepping on each other.

Four moves, in plain English: pair the tools, bridge via MCP, persist identity in code, isolate in worktrees.

The build

What was shipped?

What I shipped, in eleven pieces. The first six are the visible surface; the last five are the mechanics underneath that make the visible surface actually work.

The visible surface

1. Linear as the agent communication substrate. Each Linear issue is a thread. Tagging @tincture-mara (or any of the twelve specialists) on an issue spawns an agent session in the right repo with the right identity loaded. The Linear thread holds the conversation; the agent does the work in a git worktree branched off the issue. Threaded comments, resolved/unresolved state, and Linear's project/cycle structure all come for free.
2. Notion MCP wired into every agent. Every specialist has the Notion MCP loaded with the tools that match their write contract. Mara can create Pitches rows. Sasha can create Cornerstones rows. Nora can create Distribution rows. Drew has read access across all 10 DBs and writes only to Weekly Plan. The write-contract enforcement lives in prose in the agent files and in the notion-contract.md the agents load before writing.
3. Full chat history retained per issue, addressable per thread. Every Linear thread becomes the audit trail for the work it references. "Why did we kill that Substack experiment?" is one Linear search away, with the full agent reasoning and Alice's responses in line.
4. Notion as the mirror for everything Linear can't carry. The financial model, the company handbook, the objectives, the additional tasks surface, the daily dash; all live in Notion's 10-DB structure (locked read/write contract v1.0). The agents have Notion MCP write access scoped per persona's contract, so the mirror updates as the work happens rather than as a separate end-of-day reconciliation chore. The bridge between Linear and Notion is what stops anything falling through the gap.
5. Per-project email integration over the top. Each project has a unique address of the shape [email protected]. I BCC it on outbound or forward inbound, and the email lands attached to the right project as an update, the same way a CRM threads correspondence onto a deal. The asynchrony I run my own working day on extends cleanly to the agents without me needing to be at a terminal.
6. Hero content in its own setup. This case study was drafted inside the setup it documents. The work came in as a Linear issue handled by Mara, written in a worktree the setup spun up, committed against the issue, and posted back to the thread Alice responded into.

The mechanics underneath

1. Git worktree isolation per Linear issue. Each agent session lands in its own worktree (.cyrus-mara/worktrees/MKT-14/ for this one), so two agents working on two issues never step on each other. This is the detail that makes "tag all your specialists at once" actually safe to do; twelve agents can work concurrently without colliding on the same files. Without this, the rest of the setup would deadlock the moment parallelism got real.
2. Memory and context that compound over time. Two layers sit underneath Linear's thread history. Per-agent memory: each specialist has a persistent memory directory (~/.claude/projects/.../memory/) read at session start and written to during work. Linear holds the conversation; memory holds the distilled "what we learned, what to do next time" lines. Per-repo context: each repo's CLAUDE.md and per-agent identity files load at session start and define what that specialist knows about this engagement, this client, this stack. The compounding effect is the point: the longer an agent runs against a repo, the more context it carries about that repo's history, decisions, and prior screw-ups. A new Sasha session today knows what a Sasha session three weeks ago learned about Alice's voice register, without re-briefing.
3. Repo-specific instruction injection as the identity mechanism. The <repository-specific-instruction> block that fires at session start is what declares "you are Mara, here's your remit, here's what you don't do, here are your write contracts, here are your handoff rules." Same model, twelve distinct specialists, no manual re-briefing. This is the technically interesting move and it's the one another operator could reproduce most directly.
4. MCP stack composition per specialist. It's not just Notion MCP. Each agent has some combination of: Linear MCP (issue and comment manipulation), Notion MCP (DB writes), cyrus-tools (agent-session orchestration), Sanity MCP (for the website), Chrome MCP (browser automation when an agent needs to actually click), and a docs MCP for cyrus internals. The composition is what makes any given specialist actually capable in their lane rather than just articulate about it. The Model Context Protocol itself is an open spec published by Anthropic; Linear and Notion both ship documented MCP server implementations against it, which is what makes this composition available off the shelf rather than something I had to build bespoke.
5. Cross-repo agent collaboration via shared contracts. Some agents (Iris, Vita) are shared across tincture-marketing-os and tincture-delivery-os. The shared-agent contract in bridge-contracts.md is how the same agent runs in two engagement contexts without identity bleed: same persona, different remit per repo, no confusion about which world it's operating in. This is the detail that lets the setup scale to a multi-team configuration without forking the agents.
6. Hosted on a Hetzner VM, not my laptop. A Helsinki CPX42 instance running Ubuntu 24.04 holds 26 systemd-managed services: one per specialist agent plus the Cyrus runtime that orchestrates them. The Linear webhook hits the VM; the VM spawns the right agent in the right repo on the right worktree; the Notion update lands; I see the result in Linear the next time I look. About $40 a month, the only new line item beyond the Claude subscription and the existing Linear and Notion seats. The migration from "Alice's MacBook" to "a Helsinki box" took a working day and turned the setup from a desktop convenience into actual infrastructure.

The outcome

What were the results?

Measurable results, with baselines and timeframes.

Operating shape, qualitatively confirmed: Mara is drafting this case study inside the very setup it documents. The brief came in as a Linear issue at 22:02 on 2026-05-14; the agent was spawned, context loaded, and framework drafted in the same thread Alice responded into. Recursion is the proof.

What it took

What tools and methods were used?

Named deliverables and dependencies, listed for the operator reading this and for the LLM building an entity graph around Tincture's methodology.

Tools and platforms. Linear (issue tracker; threaded comments; project and cycle structure; assignee model that extends to agents). Notion (10-DB operating layer with a locked read/write contract v1.0). Claude (the underlying model). Claude Code (the agent runtime). Hetzner Cloud (CPX42 instance in Helsinki, Ubuntu 24.04, running 26 systemd-managed agent services for about $40 a month, so the operating layer is always-on rather than laptop-bound). Model Context Protocol (MCP), Anthropic's open spec for tool-and-data access from language models. Linear MCP server and Notion MCP server are the two MCP implementations this setup depends on hardest.

MCP server composition per specialist. Linear MCP (issue and comment manipulation). Notion MCP (DB writes scoped per persona's write contract). cyrus-tools (agent-session orchestration; spawn, give-feedback, session-create-on-comment). Sanity MCP (website CMS access for the agents that touch the site). Chrome MCP (browser automation when an agent needs to actually click). A docs MCP for cyrus internals. The composition is what makes any given specialist actually capable in their lane.

Frameworks and methods. Repo-specific instruction injection as the identity mechanism: the <repository-specific-instruction> block that fires at session start declares persona, remit, write contracts, and handoff rules. Per-repo CLAUDE.md and per-agent identity files define what each specialist knows about a given engagement, client, and stack. Per-agent persistent memory directories (~/.claude/projects/.../memory/) read at session start and write during work; they hold the distilled "what we learned, what to do next time" lines that compound over time. Per-Linear-issue git worktree isolation for safe parallelism. Per-project email routing via the address shape [email protected]. The notion-contract.md write-contract spec, scoped per DB per persona. The bridge-contracts.md shared-agent contract for personas that operate across two repos without identity bleed. An issue-anchored audit trail where every Linear thread is the addressable record of the work it references.

Cost model. No metered APIs. The agents reach Linear, Notion, Sanity, and the browser via MCP servers, so the unit-economics line items are the Claude subscription, the existing Linear and Notion seats, and the Hetzner VM at about $40 a month. Scaling agent count or agent-work volume doesn't change the bill.

The takeaway

What's the transferable principle?

The transferable principle, for any founder or operator weighing a similar build:

The bottleneck on agent-augmented work isn't model quality or prompt craft or even tool access. It's identity persistence and addressable history. Without those two, every session starts cold, every decision evaporates, and the agents stay stuck in the role of "smart contractor I keep onboarding." With them, the agents become specialists you actually collaborate with over time, whose context compounds, and whose work is auditable a quarter later.

The right substrate for this isn't a chat tool (Slack, Discord) and isn't a long-context window (Claude Projects, ChatGPT canvas). It's an issue-anchored project tool with threaded conversations, per-project email routing, and a clean MCP path to whatever system actually holds the business's state. For Tincture that's Linear plus Notion, with a deliberate mirror bridge between them so neither tool has to do a job it wasn't shaped for. For another operator it'd be whatever pair maps to "where the work lives" and "where the state lives."

Tincture builds this kind of layer end-to-end. The handover state is one the client's team can run themselves; an ongoing maintenance retainer is available for clients who'd rather not own the upkeep themselves.