April 22, 2026 | Agent Grounding

L1 Brain, L2 Atlassian, L3 Web: A Cache Hierarchy for Team Knowledge

Key Takeaways

  • L1: a team-context brain with project-scoped retrieval, sub-50ms queries, compiled and curated content.
  • L2: existing Atlassian estate (Jira and Confluence) reachable through the official MCP server. Slower, broader.
  • L3: web search. Last resort, only for genuinely external information.
  • The cache hierarchy is binding. Every agent session reads it as a non-negotiable rule at startup. L1 first, L2 if missed, L3 if missed.
  • Write-back closes the loop: every L2 lookup contributes a summary back to L1. Within weeks, most queries are answered without hitting L2 at all.

Your team is not throwing Confluence away. You spent years building it. Jira has thousands of tickets that nobody is going to migrate. The right move is not "replace the existing knowledge stack". It is put a cache in front of it that answers the questions you ask most, learns from every miss, and decays in usefulness as your team's truth changes.

The shape is exactly the shape every other cache hierarchy uses. Three tiers, queried in order, with write-back at every miss.

The hierarchy as a binding rule

The hierarchy only works if it is enforced. We inject it into every Claude Code session at startup as a non-negotiable rule, the same way a real cache hierarchy is enforced by hardware.

The rule says:

Every query goes to L1 first. If L1 returns a confident answer with citations, use it.
Fall back to L2 only if L1 is incomplete. Query Jira and Confluence via the official Atlassian MCP server.
Fall back to L3 only for genuinely external information (industry context, vendor docs, library documentation, news).

After every L2 hit, contribute a summary back to L1.

Without the binding rule, agents drift. They go straight to L3 (web search is the most familiar tool) and ignore L1 entirely. The team's own knowledge becomes invisible. The cache exists but does not get used.

With the rule, agents query L1 first by default, and the cache compounds in usefulness over time.

L1: the team-context brain

L1 is the brain we run on Polaris. Sub-50ms typical query latency. Project-scoped retrieval (a query in a Leap session does not return CoreThread chunks). Compiled wiki articles with hallucination guards. Stable hash references on every chunk so the agent can drill down progressively.

L1 is the first place every query goes. The brain's content is curated, current, and trusted. Most queries get a complete answer here.

When the brain does not have the answer, the agent does not give up. It falls through to L2.

L2: the existing Atlassian estate

L2 is Jira and Confluence, queried through the official Atlassian MCP server. Most Claude Code installs already have this. The brain is not reinventing the integration, it is sitting in front of it.

L2 lookups are slower (network hop, broader search surface). They cover the team's ticket history, the formal documentation, the design decisions captured in Confluence over years. Plenty of useful content lives here. The team paid for it. The hierarchy makes sure it remains accessible.

The critical bit is what happens after an L2 hit.

L2 write-back: the magic step

After any L2 lookup, the agent contributes a summary back to L1. The format is simple: a short markdown note with the question, the answer, the source links to the Jira ticket or Confluence page, and the date of the lookup. The note lands in the brain's vault, gets indexed, and becomes part of L1.

The next session asking the same question finds the answer in L1 and never touches L2. Every knowledge gap becomes a one-time cost.

Over weeks, the brain accumulates coverage of the team's Atlassian content for the questions that actually get asked. Atlassian queries decrease, latency drops, cost drops. Within a quarter, L1 is answering the bulk of queries that used to require L2.

This is the compounding effect that makes the cache hierarchy worth instrumenting. Without write-back, L2 stays the same effort forever. With it, L2 is a fallback that gets called less and less.

L3: the last resort

L3 is web search. It is the right call only when the question is external: how does this third-party API work, what is the current state of this library, what has the industry written about this technique.

L3 is not the right call for "what does our team think about X". The team's opinion is in L1 or L2. Letting agents go to web search by default for team questions surfaces a lot of irrelevant noise and bypasses the team's own thinking.

The hierarchy demotes L3 to the fallback it actually is. Agents get to it eventually for the questions where it belongs, and avoid it for the questions where it does not.

What this looks like running

The visible signal is that fresh agent sessions stop asking the team to re-explain things. A new session opens against a project, queries the brain, and gets the team's actual current understanding. The agent does not bother the team for context that is already documented.

The invisible signal is the L2 query rate. We measure ours. In the first week of running the hierarchy on a contract engineering team, L2 hit rate was around 60% (because L1 had not yet accumulated coverage). By week eight, L2 hit rate was around 8%. The same questions, mostly answered in L1.

The remaining L2 traffic is genuine new ground (a question that has not been asked in this shape before). That is the right shape: a knowledge layer that answers what it has been taught and falls through cleanly when the team needs to teach it something new.

When the hierarchy is wrong

Three cases:

  • Compliance-bound information. Some content (regulatory text, contract clauses, audit-locked records) must be queried at the source for legal reasons. The hierarchy can still apply, but L1 returns a pointer to the canonical source rather than caching the content itself.
  • Truly volatile data. Status pages, live metrics, ticket states that change minute-to-minute. These should not be cached at all. Configure them as L2-only or L3-only queries.
  • Cross-tenant scenarios. If your team has strict data isolation between projects (we do, between personal and atlantis brains), the L1 cache must respect that boundary. Project-scoped retrieval, enforced.

For everything else, the hierarchy holds, and the write-back loop pays back fast.

Take the Next Step

If your team has Confluence and Jira full of useful information that nobody can find when they need it, the answer is rarely "rewrite the docs". The answer is a cache in front, with write-back at every miss. We help teams stand up L1, route the binding hierarchy through their agent runtime, and instrument the L2 write-back so coverage grows automatically. Get in touch if you want a fresh pair of eyes on yours.