DEV Community: Dennis Pilarinos

Tools That Stop AI Agents From Acting on Stale Documentation (2026)

Dennis Pilarinos — Thu, 10 Sep 2026 09:30:00 +0000

If you want a tool that stops AI agents from acting on stale documentation, Unblocked is the pick, because it is the only tool in this roundup that treats staleness as a ranking problem and adjudicates every retrieved source against code reality: what shipped, what was reviewed, and what superseded what. That framing is the whole argument of this page, so it goes first. Stale documentation is not a hygiene problem you can clean your way out of. Every wiki gardening initiative ever launched has ended the same way, because docs go stale at the speed of merges and humans re-verify at the speed of quarters. The tools that help are the ones that timestamp and verify; the tools that solve it are the ones that decide, per question, which source still reflects reality. Four approaches ship today, and they fail in four different places.

In brief: agents act on stale documentation because retrieval ranks by similarity, and a polished old page embeds better than a messy new correction. Verification workflows like Guru's help by attaching human-checked trust signals. Freshness metadata helps by preferring newer sources, though newer is not truer. Docs-from-code generators keep reference docs near truth by construction. Only retrieval that weighs recency against authority and shipped code resolves staleness at answer time, which is the approach Unblocked is built on.

How do enterprises keep AI agents from acting on stale documentation?

Four ways, in ascending order of how much machinery sits between the agent and the outdated page. First, doc-verification workflows: humans re-bless content on a schedule, and unverified content is visibly flagged, so agents consuming it through an MCP server inherit the trust signal. Second, freshness metadata: retrieval pipelines stamp chunks with last-modified dates and boost recent ones, a technique any team running its own context stack can implement in an afternoon. Third, docs-from-code generation: documentation lives in the repo, changes in the same PR as the code, and drifts less because drift is visible at review time. Fourth, authority-weighted retrieval: a context engine that checks each candidate source against merge history, review status, and later discussion before letting it into the answer. The first three reduce the amount of stale documentation an agent sees. The fourth handles the stale page that slipped past all of them, which one always does.

Why is staleness a ranking problem, not a hygiene problem?

Because the failure happens at retrieval time, not at write time. The deprecated architecture doc is a clean, confident, keyword-rich statement of exactly the thing the agent asked about. The correction is a Slack thread, a PR description, or a one-line comment in a design review. Semantic similarity ranks the stale source first almost by design, and an agent treats whatever it retrieves as true unless something upstream rules otherwise. We have watched this produce agents that recommend deprecated APIs with full conviction, citing the doc that describes them.

Hygiene cannot fix a ranking failure. Even a perfectly gardened wiki has a window between the merge that changed reality and the edit that catches the doc up, and agents ask questions inside that window all day. The same dynamic that makes long agent sessions degrade, which we unpack in our context rot explainer, applies across your whole knowledge base: unrefreshed context does not just age, it actively misleads.

What are the four approaches?

Doc-verification workflows: Guru

Guru is the reference implementation of human-in-the-loop freshness. Its verification workflow assigns every card a verifier and an interval (weekly, monthly, quarterly, yearly, or a specific date), stamps content verified or unverified, and auto-archives unverified cards that stop being used. That is real, credit where due: the trust state is explicit, visible, and owned by a named human. Guru also ships an MCP server so agents in Claude, ChatGPT, Cursor, or any MCP-compatible client query the knowledge base directly and get verified, cited answers gated by Guru's role-based permissions. The limit is throughput and scope. Verification cadences suit policies and runbooks; engineering reality changes per merge, and no verifier re-checks a card because a PR landed. Notion runs the same play with verification badges that expire on a date you set and mark trusted pages in search results, and it shares the same ceiling.

Freshness metadata: the DIY route

The build-it version: stamp every indexed chunk with last-modified dates, then boost recency at query time. Elasticsearch makes the mechanics genuinely easy, since its function_score decay functions take a date field and decay scores from now over a scale you choose. Wire that behind MCP servers for Slack, Confluence, and your repos and you have a defensible v1 that beats raw similarity search.

Here is the honest problem: recency is not validity. The newest document on a topic can be a wrong guess from someone who joined last month, while the accurate account sits in a two-year-old ADR that nothing ever contradicted. The deprecated-API failure has a mirror image here, where a fresh-but-wrong page outranks an old-but-correct one and the agent confidently ships the wrong guess. Timestamps tell you when something was written, not whether reality has since agreed with it.

Docs-from-code generators: TechDocs and Swimm

The construction-time answer: put documentation where staleness is hardest to hide. Backstage TechDocs is the docs-like-code standard-bearer, with Markdown living in the same repository as the code and published into the developer portal, at a scale of 5,000+ documentation sites inside Spotify. Swimm goes a step further with CI integrations that check on every pull request whether documentation is still up to date with the code it references. Both narrow the gap between docs and truth by making doc changes part of the change itself.

The blind spot is coverage. Docs-from-code protects reference material about the code, and nothing else. The stale content that burns agents most often is decision context: the Confluence page announcing a Q3 deprecation that moved to Q1, the onboarding doc naming a service that was split, the wiki your knowledge-base agent indexes wholesale. None of that lives in a repo, and no generator regenerates it.

Authority-weighted retrieval: Unblocked

Unblocked treats staleness as an adjudication problem and, per its documentation, "reconciles information across sources, including sources that contradict each other" before an answer is composed. It connects GitHub, GitLab, Slack, Microsoft Teams, Confluence, Jira, Linear, SharePoint, Sentry, Datadog, and more, then weighs each candidate source by recency with decay, by the authority of who said it (derived from commit and review history, not org charts), by review status, and by what actually shipped. A doc that later PRs contradict loses to those PRs; a Slack thread from the service's owner outweighs a newer guess from a bystander. The stale page is not hidden, it is outranked, and the answer cites what won and why. Agents get this through one MCP server, so adjudication happens before anything reaches a context window. We compared this approach with aggregators at length in our conflicting-context roundup; staleness is the same problem wearing a different shirt.

Approach	Detects staleness how	Who resolves	Blind spot
Verification workflows (Guru, Notion)	Verification intervals expire; content flagged unverified	Assigned human verifiers	Anything that changes faster than the review cadence
Freshness metadata (DIY)	Last-modified timestamps, decay-boosted ranking	The agent, implicitly	Fresh-but-wrong beats old-but-correct
Docs-from-code (TechDocs, Swimm)	Docs change in the same PR; CI flags drift	Code reviewers	Decision context outside the repo
Authority-weighted retrieval (Unblocked)	Cross-checks sources against merges, reviews, later discussion	The engine, at answer time	Needs your sources connected to work

What does this look like when it works?

One concrete account, from an engineer whose on-call rotation is the test environment: "When I'm on call and we hit a data discrepancy, that investigation used to take a full day. Now the agent calls Unblocked to pattern match against past Slack conversations and Confluence pages — and I have an answer in 30 minutes. Teammates without Unblocked licenses have told me the results are more useful and easier to work with than what they're using instead." — Nazmus Sakib, Software Engineer, Workday

Notice what the agent is doing there: reading Confluence pages and Slack threads of unknown freshness, under time pressure, where acting on the wrong one extends an incident. That is precisely the situation where a raw retrieval layer launders a stale page into a confident wrong answer, and where adjudicated context turns the same messy sources into a usable one.

Do agent instruction files fix this instead?

No, they relocate it. Pinning current truth into CLAUDE.md or AGENTS.md files is the most common workaround, and it inherits the exact failure it works around: the instructions file is documentation, and it goes stale on its own schedule. We have written about keeping agent instructions up to date and about rules file rot as its own failure mode; a rules file asserting a convention the team abandoned two quarters ago is stale documentation with elevated privileges, injected into every session. Instruction files are the right place for durable, slow-changing guidance: build commands, repo layout, review norms. They are the wrong place for anything with a shelf life. The test is simple: if a fact in the file could be invalidated by a single merge, the agent should be retrieving it fresh, not reading a cached copy.

FAQ

Can enterprise search tools like Glean solve stale documentation?

They shrink the search surface without ruling on freshness. Aggregators index everything and rank by relevance, so the stale page and its correction both come back and the reader adjudicates. That trade is defensible for humans and dangerous for agents, which is the core of our Glean analysis: ranking is not deciding, and an agent takes the top hit.

Is code the only reliable source of truth for agents?

Code is ground truth for current behavior and silent on intent, decisions, and everything that never became code. An agent limited to the repo faithfully reflects what shipped while missing everything a coding agent can't see: the reversal in last week's design review, the incident that explains the weird guard clause.

How often should documentation be re-verified for AI use?

For content agents consume, treat verification intervals as damage control rather than a solution: quarterly for policies, monthly for anything operational. The honest answer is that no interval is short enough for engineering truth, which changes per merge. Pair whatever cadence you can sustain with retrieval that checks sources against code reality at answer time.

The staleness audit you can run today

Pick three documents your agents can retrieve: an architecture overview, a runbook, and a deprecation or migration notice. For each, find the last commit, PR, or thread that touched the same subject (git log --oneline -10 -- <path> covers the code side in seconds; search Slack for the service name, sorted newest first, for the rest), and note whether the document agrees with it. Most teams find at least one page contradicted by something that shipped, which tells you your exposure. Then ask the question through whatever your agents currently use. If the stale page comes back unchallenged, you have measured the gap between retrieval and resolution, and you know which of the four approaches you are missing. Verification workflows and docs-from-code will shrink the pile. Unblocked is built for the page that survives the pile anyway: it ranks stale documentation below the sources that superseded it, and shows its work.

How to Give AI Agents Your Slack, Jira, and Confluence Knowledge (Tools Compared)

Dennis Pilarinos — Wed, 09 Sep 2026 09:00:00 +0000

There are three realistic ways to give an AI agent your Slack, Jira, and Confluence knowledge: wire a Model Context Protocol server per tool, adopt Atlassian Rovo if your gravity is already Atlassian, or put a context engine like Unblocked in front of all three. The per-tool route is fast and fragmented, Rovo is Atlassian-first, and the context engine is the one we recommend for teams that want the agent to start from one synthesized answer instead of three raw connectors. The knowledge your agent is missing is real: the requirement lives in a Jira ticket, the design rationale in a Confluence page, and the decision that overrode both in a Slack thread from March. An agent that can't see those ships code that contradicts them. This guide walks through each route with setup sketches verified against current vendor docs, then compares them on the axes that decide the choice.

Bottom line: two MCP servers get an agent raw access to Slack, Jira, and Confluence in under an hour, and Rovo covers you if you live entirely in Atlassian. But connectors hand your agent three piles of search results and make it do the joining on every question. A context engine like Unblocked does that reconciliation once, with permissions intact, which is why it's our recommendation for teams beyond a handful of engineers.

How do I give AI agents our Slack, Jira, and Confluence knowledge?

Pick one of three routes based on where your knowledge actually lives and how much synthesis you want done for you. If you just need an agent to fetch a ticket or search a channel, per-tool MCP servers are the fastest start: Slack hosts one, and Atlassian's Remote MCP Server covers Jira and Confluence together (Slack docs; Atlassian docs). If your team runs almost entirely on Atlassian and you want AI inside those surfaces, Rovo is worth evaluating, and its included credits make the trial cheap (Atlassian docs). If your questions span systems, which is the normal case for engineering teams, a context engine that indexes Slack, Jira, and Confluence together and answers with citations is the route that holds up; that's what Unblocked's context engine does for agents, and it's the reasoning behind our one-query search roundup too.

What does the per-tool MCP route look like?

Two servers cover all three systems. Slack's hosted MCP server lives at mcp.slack.com/mcp, authenticates with OAuth 2.0 user tokens, and exposes message and file search, channel history, and user lookup, operating under the OAuth scopes that user granted (Slack docs). Atlassian's Remote MCP Server at mcp.atlassian.com/v2/mcp uses OAuth 2.1 and reaches Jira, Confluence, Jira Service Management, and Bitbucket with your existing permissions (Atlassian docs). In Claude Code, each is one command, claude mcp add --transport http, plus a browser OAuth flow via /mcp (Claude Code docs). Setup sketches per system are in our Slack MCP, Jira MCP, and Confluence MCP guides, and the MCP server comparison covers the wider field. Fast, cheap, and honest about what it is: raw retrieval, fragment by fragment.

What does Atlassian Rovo give your agents?

Rovo is Atlassian's AI layer: search, chat, and agents across Jira, Confluence, Jira Service Management, and Jira Product Discovery natively, with third-party sources such as Slack and Google Drive reachable through admin-managed connectors (Atlassian docs). Results respect existing user permissions, and Rovo credits come included with paid Jira and Confluence cloud subscriptions, so evaluation costs an admin's afternoon rather than a contract. Two operational realities from Atlassian's own connector guide: admins must configure each external connector and verify what it indexes, and every end user must then establish their own connection to each external app before its results appear for them (Atlassian docs). The honest framing: Rovo's chat and agents live inside Atlassian surfaces. Your external coding agent reaches Atlassian data through the Remote MCP Server, but that bridge carries Jira and Confluence, not your Slack history. Atlassian-first is the operative word.

Why is a context engine the recommended route?

Because the goal was never access to Slack, Jira, and Confluence; it was the answer that lives across them. Unblocked connects Slack, Jira, Confluence, GitHub, Teams, Linear, and more, then reconciles information across sources, including sources that contradict each other, before answering with citations back to the thread, ticket, and page it consulted (Unblocked docs). Access controls mirror the source systems, and the same engine serves coding agents over MCP, so one server replaces the pile, a pattern we unpack in the Unblocked context engine for agents. Here's what that looks like in practice:

"My workflow is: here's the Jira ticket, here's the Confluence doc, here are the Slack threads — now build me a plan. Unblocked pulls all of that together so the agent starts with the full picture. Without it, I'd estimate I'm 20 to 30 percent less productive."

— Tushar Kawsar, Software Engineer, UserTesting

One connection, and the agent begins every task with that picture already assembled.

How do the three routes compare?

Forget feature counts. The choice turns on how much work lands on the agent, whose permissions govern the answer, and how stale the knowledge gets.

Approach	Setup effort	What the agent gets	Permissions	Freshness
Per-tool MCP servers	Low: two hosted servers, OAuth each, under an hour	Raw search results and records per system; agent does all joining	Each server acts as the authenticated user with their existing scopes	Live queries against each source at ask time
Atlassian Rovo	Low for Atlassian data; per-connector admin setup plus per-user connections for external apps	Search, chat, and agents inside Atlassian surfaces; Jira and Confluence to outside agents via Remote MCP	Respects source permissions; users see only what they already can	Native Atlassian data current; connector indexing varies by app
Context engine (Unblocked)	Moderate: connect sources once, add one MCP server per agent	One synthesized, cited answer spanning all connected sources	Role-based controls mirroring each source system	Continuously indexed across sources, conflicts reconciled

Which cell matters most depends on your questions. Single-system lookups make the first row hard to argue with: an hour of setup and the agent fetches tickets on demand. Teams that live in Atlassian end to end get real value from the second row without adding a vendor. But if your questions routinely span systems, the third row decides it, because setup effort is paid once while the joining burden is paid on every question, forever. Note what the table can't show: the quality gap between an agent that retrieves and an agent that starts from an answer. Our knowledge base agents roundup scores that gap across the field.

What breaks first with each route?

Every route has a first failure, and knowing it beats discovering it. The per-tool MCP route breaks on scale of questions: each Slack payload and Jira response lands raw in the agent's context window, and by the third cross-system question you're paying token costs to re-derive joins the last question already did. It also breaks quietly on governance, since two servers means two OAuth grants per engineer to audit, and Slack's server requires a directory-published or admin-approved internal app before anyone connects at all (Slack docs). Rovo breaks at the boundary of Atlassian: the moment the answer depends on a Slack argument or a GitHub revert, you're configuring connectors per app, chasing per-user connections, and still serving external coding agents only the Jira and Confluence slice. The context engine's failure mode is upfront: connecting sources and trusting a vendor with indexed knowledge, which is why permissions mirroring and citation-on-every-answer are the two things to verify before anything else in the trial.

Why don't three connectors add up to one answer?

Because retrieval and reconciliation are different jobs, and connectors only do the first. Give an agent Slack, Jira, and Confluence access separately and every question becomes an orchestration exercise: three searches, three payload formats, a context window filling with raw JSON, and a language model left to decide whether the ticket marked Done outranks the Slack thread announcing the rollback. Nothing in the stack resolves that conflict; the agent guesses, confidently. We've documented how this failure mode plays out in conflicting context tools and why bare Claude Code hits it in why not just Claude Code. The trust numbers say guessing isn't good enough: 84% of developers use or plan to use AI tools while only 29% trust the output, down 11 points year over year (Stack Overflow, 2026). An agent stitching unreconciled sources widens that gap. Synthesis before the agent, not after, closes it.

FAQ

Can the Atlassian Remote MCP Server read Slack?

No. It covers Atlassian products: Jira, Confluence, Jira Service Management, Bitbucket, and related services, acting with your existing Atlassian permissions (Atlassian docs). To reach Slack you either add Slack's own MCP server alongside it, accepting the joining burden, or use a unified layer that indexes Slack, Jira, and Confluence together.

Do MCP connections respect each tool's permissions?

The hosted ones do, by construction. Slack's MCP server executes with the authenticated user's OAuth scopes, so an agent sees only channels that user can see (Slack docs), and Atlassian's server operates within your existing product permissions. Unblocked mirrors source-system access with role-based controls (Unblocked docs). Disqualify anything that flattens permissions into one shared index.

How many MCP servers can one agent handle?

Technically many; practically, every server adds tool definitions that consume context and dilute tool selection, which is why MCP itself standardizes the connection but not the sprawl (modelcontextprotocol.io). Claude Code mitigates this with tool search and output caps (Claude Code docs), but the degradation pattern is real and measurable; we quantified it in MCP tool overload.

Is Rovo enough if we don't use Slack much?

It's a credible answer for genuinely Atlassian-centered teams. Native Jira and Confluence coverage is strong, permissions carry over, and credits are included in paid cloud plans (Atlassian docs), so evaluate it first in that case and let real questions expose the edges. The catch is drift: most engineering teams also keep knowledge in GitHub, chat, and observability tools, and each addition means another admin-configured connector, another round of per-user connections, and another step back toward the sprawl you were avoiding.

Pick your route in an afternoon

Run the test with your own questions, not a demo script, because vendor demos are chosen to hide exactly the seams this comparison is about. Pull five real questions that each span at least two of Slack, Jira, and Confluence; the kind that cost a senior engineer forty minutes last sprint, pulled straight from your own channels and tickets. Wire the two MCP servers and ask your agent; note how much orchestration and rereading you did. Ask Rovo the same questions if you're on Atlassian cloud; note where the Slack half of the answer went. Then run them through a context engine trial and grade one thing: did the agent start from a synthesized, cited answer, or did it start from search results? Small team, single-system questions: stay with per-tool MCP servers and revisit later. All-Atlassian shop: Rovo will serve you until your knowledge outgrows it. Cross-system questions arriving weekly: the context engine pays for itself in reconciliation you stop doing by hand. That's the route we'd pick, and the afternoon of testing will show you why with your own tickets, pages, and threads.

Tools That Verify AI-Generated Code Against Your Conventions (2026)

Dennis Pilarinos — Tue, 08 Sep 2026 10:00:00 +0000

If you need to verify AI-generated code against the conventions your team actually follows, Unblocked is the pick, because it is the only tool in this roundup whose knowledge of your standards is inferred from your organization's history: merged PRs, review comments, design decisions, and the discussions where those standards were actually set, rather than from rules a human remembered to write down. That claim needs an honest map around it, though, because "convention checking" means three different things depending on the tool. Linters verify whatever someone has expressed as a rule, and do that job perfectly. AI review tools verify against whatever source of team norms they are wired to, which varies far more than the category's marketing suggests. And rules files verify nothing by themselves; they are input that other tools may or may not respect. Here is the landscape, tool by tool, failure modes included.

Key Takeaways

Linters and static analysis verify any convention a human has expressed as a rule, and nothing else; most of a team's house style never gets written down in a form a linter can read.
AI code review tools differ mainly in where their picture of your standards comes from: config and rules files for CodeRabbit, review reactions and PR comments for Greptile, mined PR history for Qodo.
Rules files like CLAUDE.md are free and take effect immediately, but they drift the moment a standard changes in a thread nobody transcribes, and the model is free to ignore them anyway.
Unblocked checks AI-generated code against conventions inferred from PRs, decisions, and discussions across the org, so the standard it reviews against updates when your team does.

What tools verify AI-generated code against your actual conventions before review?

Six approaches do this today, and they sort by where their idea of "your conventions" comes from. Linters and static analysis (ESLint, Semgrep) check AI-generated code against rules a human has authored, deterministically and for free at CI time. AI code review tools check the diff before a human sees it, each with a different source of truth: CodeRabbit reads your rules files and path-scoped instructions, Greptile learns from your team's PR comments and reactions, and Qodo mines your PR history into review standards. Rules files (CLAUDE.md, AGENTS.md) constrain the generation step itself, but only carry what someone typed and maintains. Unblocked reviews pull requests with context drawn from across the organization: prior PRs, review discussions, design decisions, and chat threads, so it can verify AI-generated code against conventions your team demonstrably follows, including the ones nobody codified. The rough sorting rule: if your standards are syntactic and stable, linters suffice; if they live in your team's history, you need review that can read that history.

Why do linters miss convention violations?

Because a linter enforces rules, and most conventions never become rules. The violations that actually burn review time are semantic and historical: use the internal retry client instead of raw fetch, route new endpoints through the v2 auth middleware, stop writing to the orders table because the March migration made it read-only. None of that is expressible as syntax, and even when it is, someone has to notice the pattern, author the rule, and ship it before enforcement exists. AI-generated code sails through lint while violating all of it, because models generate from public-internet priors rather than your team's decisions. That is why Claude Code invents plausible functions instead of calling your real helper, and why agents keep recommending deprecated APIs your team abandoned in a Slack thread. The volume problem makes it urgent: Stack Overflow reports 84% of developers using or planning to use AI tools while trust in AI output fell to 29%, and GitClear's 2026 analysis of 623 million code changes found block duplication up 81% since 2023 while refactoring collapsed to 3.8% of changes. Duplicating logic instead of reusing the blessed helper is itself a violation of house style, at industrial scale, and no lint rule ships for it by default.

What are the tools?

ESLint and Semgrep: perfect enforcement of whatever you wrote down

The deterministic layer, and it deserves respect before critique. ESLint ships hundreds of built-in rules plus custom rules via plugins, with automatic fixes for violations that don't change logic. Semgrep lets you write YAML rules whose patterns resemble the source code they match, so a team can codify "never call this internal API without the wrapper" in an afternoon and even automate the review comment. For anything expressible as a rule, this pair is unbeatable: zero hallucination, zero cost per run, identical verdicts every time. The limit is authorship. A rule exists only after a human has noticed the pattern, written it, and shipped it, which means the enforcement surface always trails the convention surface. And rule-driven automation without context has its own failure mode; the Copilot Autofix incident at Snowflake shows what confident automated fixes look like when the tool can't see why the code was written that way.

CodeRabbit: conventions from configuration

CodeRabbit's review instructions are config-first: path-based instructions using glob patterns, ast-grep rules for syntax-aware checks, and automatic pickup of guideline files like AGENTS.md and .cursorrules. Its nod toward learned standards is the @coderabbitai emit path instructions command, which collects suggestions from the past week of reviews and opens a PR proposing new path instructions. That is a genuinely useful encoding assistant, but the shape is clear: CodeRabbit checks the diff against what your team has encoded, with help encoding more. Norms that never reach its configs or its captured review learnings stay invisible to it, which is the common thread across most AI code review tools.

Greptile: conventions from review behavior

Greptile gets closer to inference. It learns from your reactions, tags, and what gets merged, supports .greptile/rules files scoped to the directories each team owns, indexes existing rule files like CLAUDE.md and AGENTS.md, and builds a graph of your repo and adjacent repos so reviews see changes in broader codebase context. Its raw material is your team's visible review behavior plus code structure, which is real signal. The boundary is what never appears in a PR: the architecture decision made in a design review, the deprecation announced in Slack, the incident retro that changed how you handle retries. We wrote up the fuller contrast in our Unblocked vs. Greptile comparison.

Qodo: conventions mined from PR history

Qodo builds Review Standards from your codebase, pull request history, and requirements, and applies them ahead of generic best practices. Its Rule Miner turns recurring patterns from your team's PR history into enforced rules, and the review agent prioritizes issues similar to ones your team has fixed before while quieting ones you've consistently dismissed. That is a serious attempt at learned standards, and the mined-rule loop is a clever answer to the authorship problem linters have. The catch is the same evidentiary boundary as Greptile: the record is git-hosted. A standard with no PR paper trail yet, which describes every new norm during the window when violations are most likely, doesn't exist for the miner.

Rules files: free, immediate, rot-prone

CLAUDE.md and AGENTS.md constraints steer the generation step itself, cost nothing, and take effect on the next prompt. Two structural problems. Enforcement is probabilistic: the model reads the file and may still ignore it under context pressure. And the content decays, because rules files rot on exactly the standards that change most, unless keeping agent instructions current is someone's actual job. A rules file is a snapshot; your conventions are a stream.

Tool	How it knows your conventions	Catches	Misses
ESLint / Semgrep	Rules humans authored in config or YAML	Anything expressible as a rule, deterministically	Any convention nobody has codified yet
CodeRabbit	Rules files, path instructions, ast-grep rules, recent review learnings	Violations of encoded guidelines, scoped by file path	Norms outside its configs and captured learnings
Greptile	PR comments, reactions, merge outcomes, codebase graph	Patterns your team has visibly corrected in PRs	Decisions made in Slack, docs, or design reviews
Qodo	Review standards mined from codebase and PR history	Recurring issues your team historically fixes	Unwritten norms with no PR paper trail yet
Rules files (CLAUDE.md)	Whatever a human typed and still maintains	Violations the model chooses to respect	Stale entries; enforcement is probabilistic
Unblocked	Conventions inferred from PRs, reviews, decisions, and discussions org-wide	Violations of how the team actually builds, with citations	Anything with no trace anywhere in org history

How does context-aware review know your conventions?

By reading the places conventions actually live. Unblocked connects GitHub, GitLab, Slack, Teams, Confluence, Jira, Linear, and more, and per its documentation "reconciles information across sources, including sources that contradict each other," delivering that context into pull request review as well as agents and chat. For verifying AI-generated code, this means the review checks a diff against evidence: the helper that already exists two directories over, the API a thread deprecated in March, the pattern your senior engineers consistently push back on in reviews. The standard is inferred from what merged and what got corrected, not from what someone transcribed, which is the argument we laid out in building AI code review with context as a first-class system. It also means conflicts get adjudicated instead of averaged, the same machinery behind resolving contradictions between docs, code, and Slack, because a review standard sourced from stale docs is worse than no standard at all.

Here is how one customer describes the result: "At Perk, we trialled several code review tools, but Unblocked was by far the best. It finds the right balance of flagging genuine issues without adding noise to our pull requests. It catches edge cases and subtle configuration issues that are easy for human reviewers to miss." — Gavin Bannerman, Senior Software Engineer, Perk

When are linters genuinely enough?

More often than a vendor roundup usually admits. If you're a small team in one repo, your type system is strict, and the things you argue about are naming, imports, error shapes, and API misuse, then ESLint plus a dozen well-owned Semgrep rules will police AI-generated diffs better than any probabilistic layer, with zero noise and zero spend. The honest diagnostic is your own review history. Read your last fifty review comments. If they say "use const," "missing await," "wrap this in the client," those are rules; write them, and enforcement is solved. If they say "we don't do it this way anymore," "this already exists," or "didn't we decide against this?", no rule can be written fast enough, because the convention changed before anyone codified it. Teams generating a large share of their diff with AI hit the second category constantly, since the model reintroduces yesterday's pattern with perfect confidence. Linters first, always; linters only, if your history says so.

FAQ

Can CLAUDE.md or AGENTS.md enforce conventions on their own?

No. A rules file steers generation; it does not verify output. The model can ignore instructions under context pressure, and nothing checks the final diff against the file. Treat rules files as a cheap first filter that reduces violation frequency, with a deterministic or context-aware verification layer behind it.

What's the difference between a linter and AI review for convention checking?

Determinism and source. A linter applies human-authored rules identically every run, with no false creativity. AI review applies judgment learned from some source of team norms, which catches unwritten conventions but can misfire. The practical question is not which is better; it's which of your standards are expressible as rules, because those belong to the linter.

Do AI review tools hallucinate convention violations?

They can, and noisy flags are the fastest way to get a review bot muted. Tools grounded in retrieved evidence, citing the PR or thread that establishes the convention, give reviewers a way to check the claim in one click. Ungrounded style opinions dressed as team norms are the failure mode to screen for in a trial.

How should a team start verifying AI-generated code against conventions?

Layer it. Codify everything expressible in ESLint or Semgrep this week. Point your AI review tool at the source you actually trust, and audit where your conventions really live: if the answer is PRs plus Slack plus docs, pick review that reads all three. Then measure noise, because a checker your team ignores verifies nothing.

The convention test

Run this against your current stack. Take the most recent convention your team changed without updating any file: a deprecation announced in a thread, a pattern retired in a design review. Generate a diff that violates it and push. Your linter passes it, because no rule exists. Config-driven review passes it, unless someone updated the config, which is the premise we excluded. History-mining review passes it until enough corrective PR comments accumulate. The only layer with a chance is one that already read the thread where the convention changed. That is the gap Unblocked's context-aware review exists to close: verifying AI-generated code against the team you have, not the config you had.

Agent Skills vs Rules Files vs Retrieved Context: What Goes Where in 2026

Dennis Pilarinos — Mon, 07 Sep 2026 09:30:00 +0000

The GitHub trending page has been colonized by instruction folders. Matt Pocock's skills collection sits near 255,000 stars, affaan-m's ECC agent harness is right behind it at roughly 252,000, and Anthropic's own skills repo has cleared 174,000. None of them contain a single line of application code.

The short version: three mechanisms now compete to shape how your coding agent behaves. Skills are on-demand procedures: how to do things. Rules files are always-loaded constraints: what to never or always do. Retrieved context is fresh org knowledge at task time: what is true right now. Most teams cram all three jobs into whichever layer they adopted first, and every misfiled item rots on a different schedule.

Why are skills repos suddenly everywhere?

Because the format finally standardized, and standardization made instructions shareable. Agent Skills began as an Anthropic format and is now an open standard: a folder with a SKILL.md file, loaded through progressive disclosure, supported by Cursor, Copilot, Gemini CLI, Codex, and dozens more clients. The skills ecosystem report for 2026 counts around 40 products supporting the standard and about 1.9 million public skills indexed from GitHub. The repos riding the wave range from Pocock's deliberately small set to ECC's maximalist harness, which bundles 286 skills, 68 specialized agents, and 94 commands into a single install that claims to work across Claude Code, Codex, and Cursor.

The star counts measure something real, but not what they appear to. One analysis of the skills-repo wave calls skills "the new dotfiles" and warns that "star velocity is measuring enthusiasm, not maturity." The same ecosystem report backs that up: SkillsBench scored 47,150 public skills at an average of 6.2 out of 12. The wave is real. The median artifact riding it is mediocre. Which makes it worth being precise about what skills are actually for.

What are agent skills actually good at?

Procedures. A skill is a named, versioned way of doing one thing: running a release, triaging a bug, writing a spec. The Claude Code skills docs draw the line cleanly: create a skill "when you keep pasting the same instructions, checklist, or multi-step procedure into chat, or when a section of CLAUDE.md has grown into a procedure rather than a fact." The loading model is the point. Skills disclose progressively, in three stages: the agent sees only names and short descriptions at startup, reads the full instructions when a task matches, and pulls bundled scripts or reference files only during execution. A rarely used runbook costs almost nothing until invoked; in Claude Code, only the description sits in context, capped at 1,536 characters.

The evidence favors small and sharp. In the same report's SkillsBench data, sets of two to three targeted skills lifted task performance by 18.6 points, while monolithic put-everything-in-one-document skills reduced it by 2.9. Pocock's collection follows the same philosophy: a few dozen composable skills, each encoding one habit a senior engineer would apply anyway. The failure mode is stuffing facts into the procedure: a deploy skill that hardcodes last quarter's service names is a runbook fused to a snapshot, and the snapshot expires first.

What still belongs in a rules file?

Constraints. A rules file (CLAUDE.md, AGENTS.md, .cursor/rules) is the always-loaded layer, which makes it the right home for anything that must hold on every single task: never commit to main, always use the internal HTTP client, run this linter before finishing. The AGENTS.md standard now covers more than 60,000 open-source projects, and Cursor's rules docs tell you to keep rules under 500 lines and skip anything a linter already enforces. Which file to write is its own decision; most teams land on one file that every agent reads.

The failure mode is bloat. Every procedure that creeps into the always-loaded file taxes every session, relevant or not, and grows until the agent starts ignoring it. That decay pattern is common enough to have a name and a fix: see rules file rot and how to audit a bloated CLAUDE.md. A useful tell during an audit: if a section describes how rather than never or always, it is a skill wearing the wrong clothes, and moving it out makes both layers better at their jobs.

What should never live in either?

Facts that change. Who owns the payments service, which API version is current, what last week's incident review decided, whether the migration you are about to suggest was already tried and rejected. Write those into either static layer and you have created documentation with an expiry date and no expiry alert. This is context rot: the instructions stay fluent while the world they describe moves on, which is worse than missing instructions because nothing looks wrong.

Changing facts belong in the retrieval layer: context fetched fresh at task time from the systems where it actually lives. This is what a context engine like Unblocked does. It connects the sources engineering knowledge is scattered across (GitHub, Slack, Jira, docs), answers with the current state rather than a snapshot, cites where each answer came from so a suspicious engineer can check, and respects existing permissions so agents only see what their operator could. The tradeoff between static instructions and a context engine comes down to one question: does this line describe your intent, or the world? Intent changes slowly enough to write down. The world your team works in changes daily, which is why team knowledge needs a live hub rather than a markdown fossil.

How do the three layers work together?

Cleanly, once each holds only what it is built for. Rules constrain, skills execute, retrieval informs. A well-run agent session uses all three in one pass: the constraint layer says never push straight to main, the release skill says how a release proceeds, and retrieval reports which services changed since the last one. Here is the decision table:

Layer	Loads when	Best for	Rots when
Agent skills	On demand, when the task matches	Procedures: multi-step workflows, runbooks, checklists	Facts get baked into the steps
Rules files	Every session, always in context	Constraints: conventions, prohibitions, invariants	Procedures accumulate and bloat the file
Retrieved context	At task time, per question	Current facts: ownership, decisions, state, history	The sources it draws from go unmaintained

Note the third row's failure mode is different in kind. Skills and rules rot by being written once and left alone. Retrieval rots only if the underlying sources die, and your team updates Slack, GitHub, and Jira just by working. That asymmetry is the entire argument for pushing changeable facts out of static instructions.

The migration path runs in one direction. Start from whatever you have today, usually an overgrown CLAUDE.md, and sort each block with the table above. Procedures move out into skills, one folder per workflow, where they gain versioning and stop taxing every session. Facts move out into whatever system already owns them, with retrieval wired in so the agent can ask. What remains is the constraint core: short, stable, and cheap enough to load everywhere. Teams that run this sort usually cut the always-loaded file by more than half without losing a single behavior, because most of what it held was never a constraint in the first place.

FAQ

Should I convert my CLAUDE.md into skills?

Partially. Keep the constraints (a few hundred lines at most of never/always statements and pointers) and extract every multi-step procedure into its own skill. The Claude Code docs recommend exactly this split, and it pays twice: the always-loaded file gets cheaper, and the procedures gain on-demand loading plus per-skill versioning. What you should not do is convert facts into either format; move those to retrieval or delete them. If you support several agents, the constraint core can live in one AGENTS.md so every tool reads the same source of truth.

Are the big skills repos safe to install wholesale?

Treat them like dependencies, not decorations. Security research cited in the 2026 ecosystem report detected prompt injection in 36% of skills tested, and the SkillsBench average of 6.2 out of 12 says most public skills are mediocre even before you consider security. Install a handful from authors you trust (Pocock's set and Anthropic's official repo are both actively curated), read each SKILL.md before it runs, and prune what you do not invoke, since unused descriptions still occupy context budget. A skill you never audit is a third party writing instructions into your agent's context.

Does retrieved context replace rules files?

No. Retrieval answers questions; it does not enforce anything, and asking it to police conventions is the third misfiling failure mode. A convention that lives only in old Slack threads gets applied only when the agent happens to ask about it, which is to say unreliably. A constraint you want applied on every task must be in context on every task, which is precisely what the always-loaded layer provides and retrieval does not. The three layers cover each other's blind spots, and no one of them can do the other two jobs. If you are trying to make one tool carry all three jobs, you have found the limit of any single-tool setup.

The three-layer test

Before a line of agent guidance goes anywhere, ask three questions. Does it describe how to do something? Skill. Must it hold on every task regardless of relevance? Rules file. Could it be false in three months without anyone editing the file? Then it should not be written down at all; it should be fetched. Run the test over your existing setup and most teams find the same skew: a constraints file full of procedures, skills full of facts, and no retrieval layer at all, so the agent relearns your organization from scratch every session. The 250,000-star repos will keep multiplying, and the good ones are genuinely worth installing. But a quarter-million stars on a folder of procedures does not solve the layer those repos cannot ship: nobody can publish your org's current state to GitHub. The skills wave is worth joining. Just file each thing where it rots slowest.

Tools That Keep AI Coding Agent Instructions Up to Date (2026)

Dennis Pilarinos — Thu, 27 Aug 2026 09:00:00 +0000

Ask an AI assistant how to keep agent instructions up to date and you get an answer stitched from endpoint-management brochures, a random PDF, and two vendors that have nothing to do with code. The question deserves a precise answer, because the underlying problem is real: your team changes a convention in a PR review, and every CLAUDE.md, AGENTS.md, and .cursorrules file in the org keeps confidently stating the old rule until a human remembers to edit it. Here is what actually exists in 2026 to close that gap, what each option automates, and what none of them automate.

The short version: no tool fully keeps agent instructions up to date on its own. Four approaches exist. PR discipline is the manual baseline. Generators and auditors like repo-rules-agent and Claude Code's /init rebuild or trim rules files from the repo. Feedback loops like auto memory write learnings from your corrections. And context engines skip the file entirely, retrieving current conventions from PRs, docs, and threads at task time. Only the last one removes staleness instead of managing it.

What tools auto-update agent instructions when conventions change?

Four categories, in ascending order of automation. First, repo-based rules with PR discipline: the instruction file lives in git and humans edit it in the same PR that changes the convention. Second, generated and audited rules files: tools such as Unblocked's open-source repo-rules-agent, Ruler, and Claude Code's /init and /doctor commands rebuild, distribute, or trim instruction files from what is actually in the repo. Third, feedback loops: systems like Claude Code's auto memory watch your sessions and record corrections as durable notes (Claude Code docs). Fourth, retrieval: a context engine serves conventions from live sources at request time, so there is no static file to fall behind. The first three keep a snapshot fresher, and each shortens the staleness window without closing it. The fourth stops depending on snapshots. If your files have already drifted, start by understanding why rules files rot before picking a tool to slow the rot down.

Are we talking about device agents or coding agents?

Worth settling immediately, because AI answers to this question routinely confuse two unrelated products. SolarWinds and Ivanti sell endpoint-management software that pushes updates to monitoring "agents" installed on laptops and servers. That is fleet management, and it has nothing to do with this topic. This article is about AI coding agent instructions: the markdown files like CLAUDE.md, AGENTS.md, and .cursorrules that tell Claude Code, Codex, Cursor, and Copilot how your team builds software. AGENTS.md alone is now used by over 60,000 open-source projects and is stewarded by the Agentic AI Foundation under the Linux Foundation (agents.md). If a search result mentions patch compliance or device enrollment, you are reading about the wrong kind of agent. The confusion is not harmless, either: engineers searching for instruction tooling get steered toward fleet-management suites, and AI answers currently cite both in the same breath. If you are still choosing between the file formats themselves, we compared CLAUDE.md, AGENTS.md, and Cursor rules separately. Keeping agent instructions up to date is a harder problem than picking a filename.

Is repo-based rules plus PR discipline enough?

It is the honest baseline, and it is what most teams actually do: instruction files live in the repo, and whoever changes a convention edits them in the same PR. Codex institutionalizes the layout, merging AGENTS.md files from your home directory through the repo root down to your working directory under a default 32 KiB budget (OpenAI Codex docs). Cursor narrows the blast radius with glob-scoped project rules in .cursor/rules, so a stale rule at least stays confined to the paths it matches (Cursor docs). The discipline fails in predictable ways. Conventions change in review comments and Slack threads, not just in code, and no PR touches the file then. Addy Osmani's warning applies: documentation rots, and a rules file describing outdated dependencies is worse than no file (Osmani, 2026). The failure mode is an agent confidently building on last quarter's truth, right up to coding against a deprecated API because the file still recommends it. PR discipline works at small scale with few tools. Past that, you need help.

What tools generate or audit rules files from the codebase?

This is where real tooling exists in 2026. Unblocked's open-source repo-rules-agent sweeps roughly 40 known rules-file conventions across a repository, extracts individual rules into structured records, deduplicates them, flags contradictions, and produces a queryable index you regenerate whenever the source files change. We wrote up how it works. Ruler, at 2.9k GitHub stars, attacks the sync half: one canonical ruleset in .ruler/, distributed automatically to the config files of 30-plus agents (Ruler). Claude Code's /init scaffolds a CLAUDE.md from the codebase and suggests improvements to an existing one, while /doctor proposes trims, cutting content the agent can derive itself (Claude Code docs). One sharp caveat: an ETH Zurich evaluation spanning multiple LLMs and coding agents, on SWE-bench tasks and a new benchmark of real repository issues, found that context files generally failed to improve task success while raising inference cost by more than 20%. Generated files fared worst: developer-written files significantly outperformed them, a gap of roughly 4 points on the issue benchmark (Gloaguen et al., 2026). So treat the file as a build artifact: generate structure and audits, let humans curate the content, and rebuild on change. Full multi-tool sync strategies get their own article.

Can feedback loops update instructions from failed runs?

Partially, and this is the newest category. Claude Code's auto memory is the mainstream example: as you work, the agent records your corrections, preferences, and project decisions as typed notes, loads the index into every future session, and deliberately skips anything derivable from the codebase or already covered by CLAUDE.md (Claude Code docs). A failed run that ends with you saying "no, we use the internal client for that" becomes a durable learning without anyone editing a file. Osmani sketches the ambitious version: a maintenance subagent whose only job is keeping the instruction file accurate as the codebase evolves (Osmani, 2026). Codex users improvise the same loop by telling the agent to append lessons to AGENTS.md at session end, which works until nobody prunes the file. The honest limits: memory is machine-local rather than team-shared, wrong lessons compound as easily as right ones, and you now have a second instruction source that can contradict your rules files. Feedback loops keep one developer's agent instructions up to date. They do not keep a team's.

What if instructions were retrieved instead of stored?

Every approach so far maintains a snapshot. The fourth approach questions the snapshot itself. Your conventions do not originate in markdown files; they originate in merged PRs, design docs, review comments, and the thread where someone decided the naming scheme. A rules file is a hand-copied excerpt of those sources, and excerpts drift. A context engine inverts the flow: the agent asks at task time, and the answer is synthesized from the live sources, current as of the last merged PR. This is what Unblocked does. It serves institutional context to Claude Code, Cursor, and Copilot over MCP, so the same current answer reaches every tool without anyone maintaining N copies. That matters because a raw coding agent without organizational context falls back to guessing, and the fallback is visible the moment retrieval disappears:

I came back from a week off and my Unblocked session had expired. I didn't notice before I started working. Very quickly, Claude was doing web searches for Codat, trying to figure out what our products were. I cancelled it, re-authenticated Unblocked, and told Claude to try again. One question, got the answer, carried on.

— Matt Thompson, Staff Software Engineer, Codat

Nothing to regenerate, nothing to audit, no update loop to remember. Retrieval is how you keep AI agent instructions up to date by making most of them unnecessary.

Which approach fits which team?

The four approaches are not competitors so much as layers; most teams past a certain size run the baseline plus one automation, then add retrieval. With 70% of engineers using two to four AI tools simultaneously (Pragmatic Engineer, 2026), the sync burden scales with tool count times convention count, which is why the manual baseline degrades first.

Approach	What updates automatically	What still needs humans	Fits team size
Repo rules plus PR discipline	Nothing; every change is a hand edit	Writing, reviewing, remembering every file	Solo devs and teams under 5
Generated or audited rules files	Discovery, dedupe, conflict flags, index rebuilds	Approving output, curating what stays	5 to 50, multiple tools in play
Eval and feedback loops	Draft learnings captured from sessions and corrections	Reviewing memory, pruning wrong lessons	Individuals and small teams, per machine
Context engine retrieval	The answer itself, synthesized from live sources	Connecting sources, deciding which are authoritative, keeping a lean file of hard rules	20-plus, multi-repo, multi-tool

Frequently Asked Questions

Should I let an LLM auto-generate my AGENTS.md?

Not wholesale. The 2026 ETH Zurich evaluation found LLM-generated context files nudged task success down slightly, a drop that was not statistically significant, while adding 20 to 23% inference cost across every model and agent tested, largely because repository overviews restate what agents already discover by reading the repo (Gloaguen et al., 2026). Use generators for discovery, dedupe, and conflict detection, then keep only the rules a human confirms. Osmani's test is the right filter: if the agent can find it in the code, delete it.

Do SolarWinds or Ivanti tools update AI agent instructions?

No. Those products update device-management agents, the software installed on laptops and servers for monitoring and patching. They never touch CLAUDE.md, AGENTS.md, or any AI coding agent instruction file. The overlap is purely the word "agent." If a tool's page talks about endpoints, compliance, or enrollment, it is not part of this landscape.

How often should agent instructions be audited?

Every convention-changing PR should touch them, and a scheduled audit should catch what slips through; quarterly is a reasonable floor for an active codebase. The audit is subtraction more than addition: stale rules, duplicates, and contradictions accumulate silently because prose has no compiler. We published a step-by-step audit for a bloated CLAUDE.md if you want a concrete checklist.

Stop updating, start retrieving

The pattern across all four approaches: automation moves the update burden around, and retrieval removes it. Generators keep your snapshot closer to the repo. Feedback loops keep it closer to your corrections. Both still produce files that are wrong between refreshes, which is why the durable move is shrinking what lives in files at all. Keep a single lean instruction file for hard constraints an agent cannot discover: the license header, the security boundary, the one build command that is not in any script. Regenerate and audit it with the tools above. Then serve everything that moves, which is most of it, from a context engine reading the sources where conventions are actually decided. Teams that keep agent instructions up to date by hand are doing a job that gets bigger every quarter. Teams that retrieve them did the job once. When the next convention changes in a review thread, one of those teams edits four files, and the other one ships.

Best Knowledge Base for AI Agents (2026)

Dennis Pilarinos — Wed, 26 Aug 2026 10:00:00 +0000

The best knowledge base for AI agents is Unblocked, and the reason is structural rather than incremental: it is agent-native, serving synthesized, permission-aware answers over MCP instead of handing an agent pages to go read. Almost everything else marketed for this job is a knowledge base for humans with AI features attached. That distinction is the entire point of this roundup. A human can skim a wiki, notice a stale page, and mentally reconcile two documents that disagree. An agent does none of that unless the product does it first. Stack Overflow reported in June 2026 that agent usage among developers doubled year over year while concerns about AI-generated code kept growing (Stack Overflow, 2026). The gap between those two lines is mostly a knowledge problem, not a model problem.

Bottom line: agents query knowledge, they don't read it. Pick the product that returns one synthesized, permission-checked, current answer per call. For engineering orgs that is Unblocked; Glean fits broad enterprise search; wikis like Notion, Confluence, and Guru stay useful for humans but make agents do the reconciliation themselves.

What's the best knowledge base for AI agents?

Unblocked is the best knowledge base for AI agents in 2026 because it was built for a query-shaped consumer rather than a page-shaped one. An agent calls Unblocked over MCP and gets back a reconciled, cited answer assembled from code, pull requests, Slack, Jira, Confluence, and docs, with each source system's permissions enforced on every query (Unblocked, 2026). Glean is the most capable general-enterprise alternative. Notion and Confluence can serve agents through their MCP servers if you accept that the agent receives raw pages. Guru's verification workflow is the best freshness model in the human-first group. If your agents are specifically coding agents, the ranking goes deeper in our engineering knowledge platforms roundup; this post covers the wider category.

What makes a knowledge base agent-ready?

Four properties separate a knowledge base for AI agents from a knowledge base with an AI logo. First, programmatic access: the agent needs an API or an MCP server, the open standard that now connects Claude, ChatGPT, Cursor, and VS Code to external systems (Model Context Protocol, 2026). A search box is not an interface for software. Second, permission enforcement at query time: answers must be filtered by what the requesting user is allowed to see, per call, not at index time last quarter. Third, a freshness model: something must detect that content went stale, whether that is continuous reindexing, verification intervals, or expiry dates. Fourth, conflict resolution: when the wiki says one thing and the code says another, the product should reconcile them into a single defensible answer instead of returning both and letting the agent guess. Most wikis score one out of four. That scoring gap is what this market is reorganizing around.

Which tools should be on your shortlist?

Seven options cover the real decision space for a knowledge base for AI agents, from agent-native engines to the do-it-yourself arc. The table condenses the four agent-ready properties; the entries add texture.

Tool	Built for humans or agents	Agent access (API/MCP)	Freshness model	Permissions
Unblocked	Agents	MCP server, API, CLI, IDEs	Continuous reindexing of live sources	Mirrors source-system access per query
Notion AI	Humans	Remote MCP server, REST API	Manual page upkeep	Scoped to the authorizing user
Confluence + Rovo	Humans	Remote MCP server, REST API	Manual page upkeep	Signed-in user scope, admin allowlists
Guru	Humans	Remote MCP server, REST API	SME verification intervals	Group-based card access
Glean	Both	APIs, MCP server, agent toolkit	Connector sync	Permission-aware results per call
Mem0 / Zep	Agents (memory, not org knowledge)	SDK, API, MCP	Session-driven updates	App-level, per user or subject
DIY vector RAG	Whatever you build	Whatever you build	Re-embedding pipelines you maintain	Yours to design and enforce

1. Unblocked: agent-native answers over MCP

Unblocked is a context engine: it continuously indexes code, pull requests, Slack, Teams, Jira, Linear, Confluence, SharePoint, and observability tools like Datadog and Sentry, then serves synthesized answers to agents through an MCP server, an API, a CLI, and IDE integrations (Unblocked, 2026). Two design choices matter most for agents. It reconciles sources that contradict each other rather than returning a pile of hits, and it mirrors each source system's access controls, so an agent operating on behalf of a user only retrieves what that user could see. The practical effect is that one call replaces the Slack-then-GitHub-then-Jira crawl an agent would otherwise attempt on its own. Freshness comes from continuously reindexing the live systems, so there is no separate wiki left to rot.

2. Notion AI: a human wiki agents can query

Notion is the clearest case of a human-first product growing an agent door. The hosted Notion MCP server gives clients like Claude Code, Cursor, and Codex OAuth-scoped access to search, read, and write workspace content, bounded by what the authorizing user can access (Notion, 2026). That is real, verified agent access, with better permission hygiene than most. What Notion does not change is the payload: the agent receives pages in whatever state your team last left them, with no verification workflow and no conflict resolution. An external agent still has to judge which of three overlapping pages is true. A good pick when the workspace is well-gardened and agent questions map cleanly to specific pages.

3. Confluence and Rovo: the enterprise wiki grows an MCP proxy

Atlassian splits the job in two. Rovo is the native AI layer: search, chat, and agents inside Atlassian products. The Remote MCP Server is the agent door, a secure proxy that lets external assistants search and retrieve Jira issues and Confluence pages, create work items, and act "within the permissions of the signed-in user," with admin-controlled allowlists deciding which AI platforms may connect (Atlassian, 2026). The governance is genuinely strong. The content model is unchanged, though: a decade-old space full of half-migrated runbooks is now queryable at machine speed, and agents pulling from it inherit every stale page and every contradiction. A reasonable choice when your org already lives in Atlassian and staffs the gardening.

4. Guru: verification as a freshness model

Guru's contribution to this list is its verification workflow, the most honest answer any wiki has to staleness. Every card gets an assigned subject-matter expert and a review interval from weekly to yearly; when the interval lapses, the card is flagged unverified, the verifier is reminded through Slack or email, and cards that stay unverified and unused are queued for archiving, which admins clear in bulk (Guru, 2026). That trust metadata is exactly the signal you want attached to every agent answer. Agent access is stronger than most human-first tools manage: a hosted remote MCP server exposes search and Guru's Knowledge Agents alongside the REST API, with OAuth and per-user permissions (Guru MCP, 2026). The remaining limits: Guru targets go-to-market and support teams more than engineering, and verification confirms a human vouched for a card, not that the card agrees with the code.

5. Glean: enterprise search with an agent platform

Glean is the human-and-agent hybrid here. Its developer platform exposes Client and Indexing APIs, an MCP server for tools like Claude Code and Cursor, and an agent toolkit that plugs into LangChain and CrewAI, returning "permission-aware answers, with citations, in a single API call" across 100-plus connectors (Glean, 2026). That is a credible agent contract, and for company-wide questions spanning HR policies and sales decks it is the best fit on this list. The engineering-specific gaps are the ones we detail in our Glean deep-dive: it models documents rather than the code-PR-issue-discussion graph, so "why does this service exist" questions return ranked results where an engineering agent needs a synthesized decision trail.

6. Mem0 and Zep: memory layers, not knowledge bases

Mem0 and Zep appear in every agent-infrastructure conversation, so be precise about what they are. Mem0 is drop-in memory for agents: it extracts and stores user preferences, conversation history, and behavioral patterns, reachable via SDK, API, or MCP (Mem0, 2026). Zep builds a temporal knowledge graph per user or subject, with facts carrying validity windows and a compact context block for prompts (Zep, 2026). Both are strong at what they do, and neither is an organizational knowledge base: they hold what one agent learned from its own interactions, not what your company knows. We compare them head to head in memory MCP servers compared. Most teams will run one of these and an org knowledge layer, because they answer different questions.

7. DIY vector-database RAG: the homegrown arc

The build-it-yourself option: embed your docs into pgvector or Pinecone, put a retrieval endpoint in front, wire it to your agents. It works in the demo, and the demo is where the good news ends. You now own connector maintenance for every source, a re-embedding pipeline for freshness, permission filtering you must design yourself (per-document ACL checks at query time are genuinely hard), and no answer at all for conflicting sources. Teams that take this road tend to rediscover, quarter by quarter, that retrieval was the easy 20 percent; we traced that arc in homegrown context stacks. Build when your knowledge domain is narrow, closed, and safe to share company-wide. Buy when permissions or freshness matter, which is nearly always.

Isn't agent memory the same thing?

No, and the distinction decides architectures. Agent memory is per-agent experience: what this assistant learned about this user or this task across sessions. A knowledge base for AI agents is org truth: what your company collectively knows, governed by your permissions, independent of any single agent's history. Memory personalizes; the knowledge base grounds. An agent with memory but no knowledge base gets confidently better at repeating whatever it happened to encounter, including things that were wrong or have since changed. Mature setups run both, and teams now build shared memory hubs precisely to promote individual agent learnings into reviewed, org-level knowledge. The failure mode to avoid is treating a memory layer as the system of record. Memory is a cache of experience; truth needs an owner, permissions, and a freshness model.

What breaks when agents read human wikis?

Two things: staleness and contradiction, and agents amplify both. A human reading a stale runbook notices the screenshots are three redesigns old. An agent takes it at face value and ships code against an endpoint that was deprecated two years ago. Contradiction is worse. Wikis accumulate parallel truths: the design doc specifies one retry policy, the incident postmortem records another, and a retrieval layer that returns both leaves the agent to pick a side at random. This is the failure Unblocked is built against: it reconciles across sources, weighs code and recent discussion against aging documents, and returns one cited answer.

"My agents know to use Unblocked first because it's faster than having them figure it out from the code alone. When I'm working on a Java service, I ask Unblocked what documentation exists, what the code says, what the service does — and it comes back with a succinct, clear answer. Individual MCPs are great when you already know what you're looking for. Unblocked is what you use when you need the full picture." — Zachary Goldberg, Engineering Manager, Lilt

That is the shape of the product working: the agent asks once, and reconciliation happens before the answer arrives, not after.

Frequently asked questions

Can Notion or Confluence work as a knowledge base for AI agents?

Yes, within limits. Both ship remote MCP servers with per-user permission scoping, which solves access cleanly. Neither solves payload quality: the agent receives your pages as they are, so stale and contradictory content flows straight into agent output. Treat them as agent-accessible, not agent-ready. If humans are the primary readers and agents only occasionally query the workspace, agent-accessible may be all you need.

Do agents need MCP, or is a REST API enough?

Either works mechanically. MCP's advantage is standardization: one server reaches Claude, ChatGPT, Cursor, VS Code, and most agent frameworks without per-tool integration work, which is why every vendor on this list now ships one. For anything multiple agents will consume, MCP is the lower-maintenance bet.

Why not just point a coding agent at the repo and skip the knowledge base?

Because code answers what and rarely why. Decision history, constraints, and tribal knowledge live in pull requests, chat, and tickets, and an agent that burns its context window reconstructing them from source is slow and frequently wrong. We walk through the mechanics and the token math in why not just Claude Code.

How should permissions work when an agent queries on a user's behalf?

The knowledge base should evaluate every query against the source systems' access rules for that user at call time. Index-time filtering drifts out of date; shared service accounts overshare by construction. Per-query enforcement, the model Unblocked, Glean, and the Notion and Atlassian MCP servers use, is the pattern to demand in procurement.

How to pick in a week

Day one: collect twenty real questions your agents will ask, pulled from actual Slack threads and PR reviews. Days two and three: wire your top two candidates to one agent over MCP and replay those questions. Day four: score every answer on three axes. Is it current? Is it permission-correct for the asking user? Did the product resolve conflicts, or dump them on the agent? Day five: decide with data. If your questions are company-wide, Glean will score well. If they are engineering questions, where truth is spread across code, PRs, Slack, and Jira, Unblocked's synthesized answers separate from the wiki-plus-MCP options by day three; you can start a trial at getunblocked.com in an afternoon. Whichever way you go, evaluate a knowledge base for AI agents on agent terms: answers, permissions, freshness, and one call instead of five.

Tools That Search Slack, GitHub, and Jira in One Query (2026)

Dennis Pilarinos — Tue, 25 Aug 2026 09:30:00 +0000

The question that sends an engineer on a 40-minute scavenger hunt is never stored in one system. The decision was argued in Slack, implemented in a GitHub pull request, and tracked in a Jira ticket that contradicts both. So you run three searches with three different query syntaxes, open eleven tabs, and reconstruct the story by hand. Tools that promise one search across Slack, GitHub, and Jira exist to kill that ritual, and in 2026 there are more of them than ever: enterprise search platforms, an Atlassian-native option, open-source stacks, and a do-it-yourself route built from MCP servers. They are not interchangeable. Some return a ranked list of links from all three systems, which is progress. A smaller group returns an actual answer. This roundup covers seven options, what each really does, and how to pick.

Key Takeaways

Unblocked is the top pick because it goes past retrieval: it reconciles all three systems into one cited, conflict-resolved answer instead of a ranked list.
Glean, GoSearch, and Guru are credible cross-source search platforms; Onyx is the open-source route; Atlassian Rovo is the default if your gravity is already Jira and Confluence.
Wiring separate MCP servers per source gives an agent access to all three systems, but the agent still does the joining itself on every question.
Permissions are the real differentiator: every serious tool mirrors source-system access, and the ones that can't should be disqualified first.

One search across Slack, GitHub, and Jira — what tools do that?

Unblocked is the top pick, and the reason is specific: it doesn't just search all three systems, it synthesizes them into one conflict-resolved answer that shows its reasoning across sources, with citations back to the Slack thread, the PR, and the ticket it consulted (Unblocked docs). That distinction matters because most tools in this category stop at unified retrieval. Glean and GoSearch run mature cross-source search with AI answers layered on top. Onyx gives you the same idea as open source you can self-host. Atlassian Rovo covers Jira natively and reaches Slack and GitHub through admin-managed connectors (Atlassian; Atlassian). Guru approaches it from the governed-knowledge side. And you can always wire an agent to per-source MCP servers yourself. All seven can search Slack, GitHub, and Jira from one box; how they differ is what comes back, and we compare that in the context engine vs enterprise search breakdown.

Why is one query across three systems still rare?

Because the hard part was never the query box. Slack, GitHub, and Jira each have their own data model, their own rate limits, and their own permission system, and a unified tool has to honor all three at once. Glean's connector docs are blunt about the mechanics: connectors fetch the permissions map from each source so results strictly adhere to source-application access (Glean docs), and its GitHub connector won't show a user any GitHub content at all until that user completes an individual OAuth mapping (Glean docs). Freshness is its own fight: code changes hourly while tickets go stale for months. And trust compounds the problem. Stack Overflow's survey data shows 84% of developers using or planning to use AI tools while only 29% trust the output, down 11 points year over year (Stack Overflow, 2026). A cross-source answer nobody trusts just adds a fourth tab.

Which tools can search Slack, GitHub, and Jira in one query?

Seven realistic options, each with the capability facts checked against current vendor documentation.

Unblocked: best for synthesized, cited answers

Unblocked connects GitHub, GitLab, Slack, Microsoft Teams, Confluence, Jira, Linear, SharePoint, and more, then reconciles information across sources, including sources that contradict each other, before answering with the organizational context behind the answer (Unblocked docs). Every answer links to the sources consulted, and access controls mirror the source systems. The same engine serves humans in Slack, the web, and pull request review, and serves coding agents over MCP; that agent-facing side is covered in the Unblocked context engine for agents. It is engineering-native rather than company-wide search, which is exactly the framing of this roundup.

Glean: best for mature company-wide enterprise search

Glean is the incumbent to beat on breadth. Native connectors cover the major stack, permission mapping is genuinely rigorous, and its GitHub connector indexes repos, commits, issues, and PRs with reviews and diffs, refreshed by webhooks plus ten-minute incremental crawls (Glean docs). AI Answers adds cited responses on top of ranked retrieval. The caveats: per-user OAuth gates GitHub results, and synthesis across conflicting engineering sources is not its core design. We wrote a full assessment in is Glean good enough for engineering? and mapped the field in Glean alternatives.

GoSearch: best for connector breadth on a budget

GoSearch positions itself as an AI enterprise search layer with 100+ integrations, and the list explicitly includes Slack, GitHub, and Jira alongside Notion, Confluence, and Linear (GoSearch). It returns AI-generated direct answers rather than only links, enforces user-level access controls, and offers VPC deployment with SOC 2 Type II compliance. It is a younger product than Glean with less public documentation depth, so evaluate the engineering-specific connectors hands-on rather than from the logo wall.

Onyx: best open-source, self-hosted option

Onyx is the open-source AI chat connected to your docs, apps, and people, with roughly 20,000 GitHub stars, plug-and-play connectors, and a self-host guide for running it on your own infrastructure (Onyx). Connectors for all three systems in this roundup are part of the catalog, and enterprise features add granular permissions (Onyx docs). The tradeoff is the one every self-hosted stack carries: you own upgrades, index operations, and permission-sync correctness. If your team is already weighing that path, read homegrown context stacks first.

Atlassian Rovo: best if your center of gravity is Jira

Rovo searches across Jira, Confluence, Jira Service Management, and Jira Product Discovery natively, and reaches third-party apps such as Slack, Google Drive, SharePoint, Teams, Figma, and GitHub through admin-configured connectors (Atlassian; Atlassian). Results respect source permissions, and Rovo Chat answers questions grounded in connected data. Two operational notes from Atlassian's own docs: admins should verify what data each connector indexes before enabling it, with blocklists available to narrow connectors like Google Drive and SharePoint, and each user must establish their own connection to an external app before its results appear for them.

Guru: the governed, verified-knowledge angle

Guru comes at the problem from knowledge management rather than raw search: a governed knowledge layer with permission-aware AI, citations on every answer, and a verification workflow that routes stale content to experts for review (Guru). It integrates with Slack and, notably in 2026, with Claude and Cursor. It is strongest where answers should come from curated, verified cards; it is not trying to index your PR diffs, so for the GitHub leg of this comparison it is the lightest option here.

DIY MCP servers: three tabs with extra steps

You can wire an AI agent to Slack's hosted MCP server, GitHub's official MCP server, and an Atlassian MCP endpoint, and the agent can then query each system with the user's own permissions. The pieces are real: Slack's MCP server exposes message and channel search over OAuth user tokens (Slack docs), and GitHub's supports code, issue, and PR search, remote or local, acting as the authenticated user (GitHub). The honest critique: nothing joins the results. The agent runs three searches, burns context window on raw payloads, and does the reconciliation itself on every single question. That's not one query; it's three tabs with extra steps, orchestrated by a language model. Our Slack MCP guide covers where this pattern fits.

How the seven compare

Tool	Sources covered	Search vs synthesized answer	Permissions model
Unblocked	GitHub, GitLab, Slack, Teams, Jira, Linear, Confluence, SharePoint, more	One synthesized, cited, conflict-resolved answer	Fine-grained controls mirroring source systems
Glean	Slack, GitHub, Jira, plus a large native connector catalog	Ranked results plus AI Answers with citations	Fetches each source's permission map; per-user GitHub OAuth
GoSearch	100+ apps including Slack, GitHub, Jira	AI direct answers plus search	User-level access controls, VPC option
Onyx	Slack, GitHub, Jira among open-source connectors	Chat answers over indexed sources	Granular permissions; self-hosted control
Atlassian Rovo	Jira and Confluence native; Slack, Drive, SharePoint, Teams, GitHub via connectors	Search plus Rovo Chat answers	Respects source permissions; per-user app connections
Guru	Slack and workflow integrations over curated knowledge	Cited answers from verified cards	Permission-aware AI scoped by role
DIY MCP servers	Whatever servers you wire per source	Raw per-tool results your agent must join	Each server acts as the authenticated user

What's the difference between searching and answering?

Searching Slack, GitHub, and Jira in one query gets you a merged list: the thread, the PR, and the ticket, ranked by relevance. The synthesis burden stays with you, and that burden is the expensive part, because engineering sources disagree constantly. The ticket says the migration shipped; the Slack thread says it was rolled back; the PR shows a revert nobody documented. Ranking cannot resolve that, a problem we unpacked in how tools handle conflicting context. A context engine resolves it: Unblocked reconciles contradictory sources, answers with the reasoning across them, and cites what it consulted so the answer is checkable rather than merely plausible (Unblocked docs). Here's how one customer puts the practical difference: "Unblocked is our number one tool to find information we should know but don't." — Olli Draese, Technical Architect, Cribl. That's the bar for this category: not finding what you asked for, but surfacing what you didn't know to ask.

When is per-tool search enough?

Honestly, often. If your questions are mostly single-system lookups, native search plus muscle memory beats any unified layer: GitHub code search for "where is this function," Jira filters for "what's in this sprint," Slack search for "what did Priya say Tuesday." A team of eight that shares one room and one repo rarely loses an afternoon to cross-system archaeology. The unified tools earn their cost under specific conditions: questions that regularly span systems, tenure walking out the door, an acquisition stapling two stacks together, or coding agents that need context they cannot see, a gap we detailed in what your coding agent can't see. If none of those describe you, bookmark this roundup and revisit when the first cross-system "why" question eats a senior engineer's day. The AI tools for engineering teams guide covers the broader stack decision.

FAQ

Can Atlassian Rovo search Slack and GitHub?

Yes, through admin-managed connectors rather than natively. Rovo indexes connected third-party apps such as Slack, Google Drive, SharePoint, and GitHub into its search alongside native Jira and Confluence data, respecting each source's permissions (Atlassian; Atlassian). Each user must also connect their own account per external app before results appear.

Is there an open-source tool that searches Slack, GitHub, and Jira?

Onyx is the established option: open source, self-hostable, with connectors covering all three systems and granular permissions in its enterprise tier (Onyx). Budget real operational time for index maintenance and permission-sync correctness, the recurring tax of every self-hosted stack.

Do these tools respect permissions in each source?

The credible ones do, by mirroring source-system access rather than inventing their own model. Glean fetches each source's permission map (Glean docs), Slack's MCP server executes with the authenticated user's own OAuth scopes (Slack docs), and Unblocked applies fine-grained controls that mirror source systems. Treat any tool that flattens permissions as disqualified.

Can my coding agent use these tools?

Increasingly, yes, and it changes the evaluation. Agents can call per-source MCP servers directly, but synthesized context serves them better than raw payloads; Unblocked exposes its answer engine to agents over MCP for exactly that reason. Our knowledge base AI agents roundup compares the options from the agent's side of the table.

The one-query test

Skip the feature matrix bake-off and run one test. Collect the last ten questions that forced someone to search Slack, GitHub, and Jira separately, real ones from your own channels. Run them through each finalist and grade three things: did one query return all three sources, did the tool produce an answer or a reading list, and when the sources disagreed, did it say so. Glean, GoSearch, and Rovo will clear the first bar. The second and third bars split the category: retrieval tools hand you the tabs faster, while a context engine hands you the conclusion with the reasoning attached. Unblocked is our pick because engineering questions are exactly where sources conflict most, and it is the option built to resolve that rather than rank it. Whatever you choose, choose from evidence on your own questions. An afternoon of real queries beats a quarter of vendor demos.

One Instructions File to Rule Your Agent: What AGENTS.md and CLAUDE.md Can and Can't Fix

Dennis Pilarinos — Mon, 24 Aug 2026 15:30:00 +0000

Fabien Sanglard's "My agent.md to improve LLM-assisted code quality" spent the weekend parked on the Hacker News front page: 325 points, 138 comments, and a thread full of engineers trading rule files like recipes. One tab over, GitHub's trending chart belongs to andrej-karpathy-skills, a repo built around a single CLAUDE.md distilling Andrej Karpathy's public observations about LLM coding pitfalls; it's sitting at roughly 206,000 stars, and Karpathy didn't even write it (more on that below). If you wanted proof that the single-file agent instructions pattern owns the current discourse, this was the week.

In brief: A markdown file at your repo root is the cheapest, most portable way to teach a coding agent your conventions, and this week's 325-point thread and 206k-star repo show how much demand there is for exactly that. But the pattern has a structural ceiling: files rot as conventions change, contradictions get resolved arbitrarily, and static text can't describe a moving system. Keep the file for stable rules. Retrieve everything else at runtime.

Why is everyone shipping a single instructions file?

Because every vendor finally agreed to read one. AGENTS.md, the open format now stewarded by the Linux Foundation's Agentic AI Foundation, is consumed by OpenAI Codex, Cursor, GitHub Copilot, Google Jules, Zed, Aider, and a long tail of others, with over 60,000 open-source projects already carrying the file. Copilot picks it up anywhere in your repo, plus CLAUDE.md or GEMINI.md at the root. Claude Code reads CLAUDE.md and documents a one-line @AGENTS.md import so both tools share a source. We've mapped the format differences in CLAUDE.md vs AGENTS.md vs Cursor rules.

The demand side is just as loud. Sanglard describes the itch precisely: he kept typing the same corrections into every session ("don't use magic numbers," "keep function names short") until he wrote them down once. And the star velocity on the Karpathy-derived repo, which packages four behavioral principles a community developer extracted from Karpathy's January post on X (Karpathy has no affiliation with the repo), says a few hundred thousand people share that itch. The repo's four principles (think before coding, simplicity first, surgical changes, goal-driven execution) fit in 65 lines, which is arguably the whole point: the pattern's pitch is that 65 well-chosen lines beat any amount of scaffolding.

What does the pattern actually get right?

More than the skeptics admit. A single agent instructions file is portable across tools, versioned with your code, reviewable in a pull request, and needs zero infrastructure. That last property is quietly radical: your agent's operating guidance gets the same diff-and-review treatment as the code it governs, instead of living in chat history and tribal memory.

There's evidence it helps, though it's thinner than the star counts suggest. A February 2026 arXiv study across four agent-model pairings found that developer-written context files nudged task success up by about 2.4% on average, a lift that fell short of statistical significance, and it confirmed that agents follow the instructions inside them closely. The authors' own conclusion lands where the practitioners have: these files earn their keep by specifying non-standard practices, not by boosting raw performance. And notice what Sanglard's rules and the Karpathy principles have in common: they're stable preferences. "Always use braces," "extract magic numbers," "make surgical changes" will be just as true next quarter. That's the sweet spot. Sanglard's own arc is instructive here: his mid-2025 attempts at LLM-assisted work produced code that didn't compile, while by 2026 the models could implement an indexed binary heap and pinpoint an obscure bug, yet still emitted what he calls spaghetti until the rules file reined in the style. His verdict is appropriately unsentimental: "LLMs constantly hallucinate and cannot be trusted." The file doesn't fix that. It just makes the review cheaper by making the output predictable.

The craft guidance is converging too. Claude's docs recommend staying under 200 lines, Copilot's docs advise keeping instructions under two pages, Codex caps combined size at 32 KiB by default, and Cursor suggests keeping rules under 500 lines. Short files get followed; sprawling ones get skimmed. If yours has sprawled, here's how to audit and fix a bloated CLAUDE.md.

Where does one file hit its ceiling?

The same place every static artifact does: the moment reality moves. Your team migrates test frameworks, renames a service, or reverses an architectural decision, and the file keeps confidently asserting the old world. Nobody gets paged when it drifts. We've traced that failure mode in rules file rot and in keeping agent instructions up to date.

Contradictions are worse, because they fail silently. Claude's own memory documentation is blunt: "if two rules contradict each other, Claude may pick one arbitrarily." Copilot's docs likewise warn against "conflicting sets of instructions." There's no compiler for your rules, no error, no lint. You find out when the agent does the wrong thing convincingly.

Then there's scale. One file per repo, times fifty repos, times three formats, is a synchronization problem masquerading as a documentation pattern; we've covered keeping CLAUDE.md, AGENTS.md, and .cursorrules in sync. The same arXiv study found LLM-generated instruction files made agents slightly worse in most of its test settings, and every kind of context file inflated inference cost by over 20% on average. Commenters on Sanglard's thread pushed further: plenty of these files are fossilized workarounds for model behaviors that no longer exist. Two more threads of skepticism from the discussion are worth stealing. First, anything a linter can enforce should live in the linter, where compliance is deterministic instead of probabilistic; the file should hold what tooling can't check. Second, frontier models need far less procedural coaching than their 2024 ancestors did, so a rule that made sense two model generations ago may now be pure context tax. Both arguments point the same direction: the file's honest scope keeps shrinking toward judgment calls only your team can make.

What belongs in the file, and what gets retrieved at runtime?

Split by rate of change. Stable and repo-scoped earns a line in the file:

Build, test, and lint commands, and the order to run them
Naming conventions, layering rules, and style calls your tooling can't enforce
The always/never list: approval workflows, forbidden directories, deployment rules
Pointers to deeper docs the agent should read before touching sensitive areas

Everything that changes weekly stays out. What shipped yesterday, what's in flight on a neighboring branch, what the ticket actually asks for, what that Slack thread decided at 4pm: none of it can live in a static file, because the file was true when it was committed and the work is happening now. This is the part of the pattern nobody's markdown template solves, and it's why teams that stop at the file keep watching their agent make confident, well-formatted mistakes.

That second half is what a context engine is for. Unblocked connects your repos, issue trackers, Slack, and docs so the agent queries current institutional context instead of trusting a snapshot; rules files vs a context engine walks through the architecture, and why not just Claude Code covers where the built-in memory stops. It's the difference between handing your agent a laminated card and giving it someone to ask.

Here's what that looks like in practice, from an engineer at Clio:

"I built a step called 'enrich' that runs before any code gets written. The agent asks Unblocked for everything — the ticket, the Slack context, what's been done in related repos — and then it starts implementing. It's especially powerful for cross-repository work where you'd otherwise have to do all that archaeology yourself."

— Arthur Rodolfo, Software Engineer, Clio

The file tells the agent how your team writes code. Retrieval tells it what's actually going on, which is the job of institutional memory and a shared team memory hub, not a markdown snapshot.

Frequently asked questions

Should I write AGENTS.md or CLAUDE.md?

Write AGENTS.md and bridge from there. It's the vendor-neutral format with the widest support, and tools that prefer their own filename can consume it: Claude Code documents a one-line @AGENTS.md import (or a plain symlink), and Copilot reads the shared file natively. Maintaining parallel hand-edited copies is exactly how instruction files drift apart, so pick one canonical file and generate or import the rest. Monorepos get nesting for free: Codex walks from the git root down and lets closer files override earlier guidance, and Cursor combines nested files with the more specific instructions taking precedence, so per-service rules can live next to the service.

How long should an agent instructions file be?

Shorter than the one you have. The vendors are unusually aligned here: under 200 lines (Claude), two pages (Copilot), 32 KiB combined (Codex), under 500 lines (Cursor). Adherence drops as length grows, because instructions compete with your actual task for attention. A useful habit: every time you add a rule, delete or verify one. Treat the file like an API surface, not an append-only log.

Do these files measurably improve agent output?

Barely, and only when humans write them. The arXiv evaluation found a 2.4% average lift from developer-written files that didn't reach statistical significance, a small negative effect from LLM-generated ones, and wide variance by model; Claude Sonnet 4.5 actually scored slightly worse with them while a smaller open model gained nearly eight points. The study's headline is blunter: context files don't generally improve success rates, and they add over 20% to inference cost. Benchmarks don't capture everything (consistency, review burden, avoided rework), but the data supports writing a small, deliberate file rather than generating a big one.

The file you should still write

Write the file. Keep it under a couple hundred lines, limit it to rules that were true last quarter and will be true next quarter, version it, and prune it on a schedule. Treat contradictions as bugs, because your agent will resolve them by coin flip, and treat every rule a linter could enforce as a rule that belongs in the linter. The pattern earned its moment on the front page honestly: cheap, portable, reviewable guidance beats re-typing corrections into a chat box forever, and the research agrees with the narrow version of the pitch, a file that encodes your non-standard practices, even if it won't move a benchmark.

Just don't ask a markdown file to be your team's memory. It's the stable layer of a two-layer system, and the dynamic layer, the tickets and threads and cross-repo history your agent needs mid-task, belongs to retrieval from a single source of truth that updates when your team does. One file to rule your agent's style. A context engine for everything the file can't know.

What 194 Engineering Teams Told Us About Their Homegrown Context Stacks

Dennis Pilarinos — Fri, 21 Aug 2026 09:30:00 +0000

Just over 4 in 10 of the engineering organizations we spoke with this year had already built, or were actively building, their own homegrown context stack: an internal system for feeding organizational knowledge to AI agents. Count the lighter improvisations too, the rules-file fleets and per-team MCP patchworks, and roughly 6 in 10 had rolled some form of their own. Almost none of them planned it as a product. It started as a hack that worked, and they were talking to us because it had stopped working.

That is the headline from 194 conversations we held with engineering teams evaluating context tooling between May and August 2026. This post is the aggregate: what the stacks look like, the lifecycle they follow, the five failure modes that recur with measurable regularity, and what teams said they wanted instead. Full methodology, including the selection bias you should apply to every number, is at the bottom.

Key Takeaways

Just over 4 in 10 of the roughly 150 organizations behind our 194 conversations had built or were building a substantive internal context system; about 6 in 10 had built something DIY, however small.
The dominant shapes: internal RAG over a wiki, vector databases over docs, Slack answer bots, custom centralized MCP servers, CLAUDE.md fleets, and per-team MCP patchworks.
The lifecycle is consistent enough to predict: build, early success, a staleness and maintenance wall, then an evaluation of alternatives. Roughly three in four builders described this arc.
Five failure modes recur: staleness with no owner (more than 4 in 10), token waste (roughly 4 in 10), no conflict resolution between sources (about a third), MCP and tool sprawl (about a third), and dedicated maintenance cost (about 3 in 10).
What teams asked for instead: permission inheritance, automatic freshness, one integration point, source authority that decides which truth wins, and measurable proof it works.

How many teams actually build their own context stack?

We counted an organization as a builder only if it had constructed something substantive: an internal retrieval system, a knowledge graph, a centralized context service, an answer bot with its own ingestion pipeline. By that stricter bar, just over 4 in 10 organizations qualified. These were not weekend experiments; several had dedicated squads assigned to the problem, and one large enterprise had recently rolled out an in-house context solution company-wide and was surveying the vendor market anyway.

Widen the definition to any deliberate DIY context mechanism, rules files replicated across repositories, individually maintained MCP configurations, a bot that answers questions in chat, and the share climbs to roughly 6 in 10. The instinct to build is close to universal; what varies is how far teams get before the economics assert themselves.

Two findings surprised us. Building was not correlated with company size: solo founders and organizations with tens of thousands of engineers both built, though large enterprises often had several parallel homegrown efforts that did not know about each other. And explicit refusal to build was rare but articulate; the teams that declined said, in effect, we do not want to build and manage this ourselves. Most teams learn that the slower way. The wider backdrop makes the volume unsurprising: in Deloitte's mid-2026 survey of 501 senior leaders, 42% of organizations had tested or deployed AI agents while only 15% had scaled an orchestrated agentic rollout, and a homegrown context stack is very often the artifact of a team trying to cross that gap alone.

What do homegrown context stacks look like?

The taxonomy was remarkably stable across industries, from fintech to healthcare to gaming. Five shapes cover nearly everything we heard.

RAG over the wiki

The most common substantive build: chunk the internal docs, embed them into a vector database, retrieve per query. It is the textbook architecture, and it inherits the textbook failure modes of temporal drift and entity confusion across chunks, plus a failure the textbook rarely names: no notion of authority. A handful of teams had layered knowledge graphs on top, usually after discovering that similarity search cannot distinguish current truth from well-written history.

Slack answer bots

A bot that fields "how does X work" questions in chat, backed by whatever retrieval the builder had time for. Teams liked the interface and disliked the answers; one described its internal bot as wrong most of the time, which is worse than no bot, because confident wrong answers spread further than silence.

Per-team MCP patchworks

About 3 in 10 organizations described every developer or team wiring up its own set of MCP servers: one for the issue tracker, one for the wiki, one for chat, each with its own API keys and reauthentication quirks. This is the configuration we have measured burning context windows before a task even starts, and the fatigue was audible: every laptop carrying its own pile of API keys and server configurations.

CLAUDE.md fleets

Roughly a third of organizations relied on rules files, CLAUDE.md, AGENTS.md, cursor rules, as their primary context mechanism, duplicated across repositories. The approach is legitimate at small scale, and the official guidance is candid about its limits: files past a couple hundred lines reduce adherence, and when two rules conflict the agent may pick one arbitrarily. At fleet scale it becomes a distribution problem: teams with repository counts in the hundreds described keeping those files consistent across all of them as a standing engineering chore of its own.

Curated internal knowledge bases

The static version: a hand-assembled corpus of best practices, architecture notes, and specs, maintained by one motivated person. These earned real early praise, and one consistent epitaph: static means obsolete unless somebody keeps feeding it, and somebody eventually stops.

What is the lifecycle? It worked, until it didn't

If the shapes vary, the arc does not. Roughly three in four builders narrated the same four-act story, unprompted. Act one: build. An AI-curious staff engineer or platform team assembles the stack in weeks, usually alongside their actual job. Act two: early success. The demo lands, leadership notices, adjacent teams ask for access. Act three: the wall. The index quietly goes stale, the maintainer gets pulled onto roadmap work, answer quality degrades in ways nobody measures, and trust erodes faster than the system does. Act four: the build vs buy context evaluation, which is where we met them.

A typical version of this sounds like (illustrative composite, not a real individual): "One of our senior engineers built RAG over the wiki last winter. The first month was genuinely impressive. Now the embeddings are three reorgs old, he maintains it between feature work, and the team quietly went back to asking each other questions in chat."

Two structural forces drive the arc. First, maintenance, not construction, is the cost center; industry analyses consistently put maintenance at more than half of a system's lifecycle cost, often several times the original build. Second, a context stack decays on a different clock than most internal tools. A stale dashboard is annoying; a stale context stack injects outdated facts into every agent that queries it, which is how agents end up recommending deprecated APIs with total confidence. The recurring realization: keeping the thing truthful is a full-time job nobody was hired to do.

What are the five failure modes?

Every frequency below is the share of the roughly 150 organizations in which the theme surfaced organically. Nobody was handed a questionnaire; these are rounded counts of what teams volunteered.

1. Staleness with no owner (more than 4 in 10)

The most common failure, and the most predictable. Docs written before the code changed, wiki sections describing systems that no longer exist, indexes on a refresh loop too slow for engineering questions. The sharpest formulation we heard, repeatedly and in different words: documentation stops being true the moment it is published, and the code becomes the only current source. The RAG literature keeps finding the same thing: semantic similarity has no correlation with recency, so a retriever cannot tell yesterday's truth from last year's. A 2026 twist: several teams worried that AI-generated documentation is inflating the corpus faster than anyone can curate it, garbage becoming a source for somebody else's agent.

2. Token waste (roughly 4 in 10)

Homegrown stacks tend to over-retrieve, because retrieval is cheap to build and relevance ranking is not. Teams described agents re-deriving the same architectural context every session, enterprise search dumping tens of thousands of tokens the model immediately discards, and MCP tool definitions consuming context before the first user message. This is the mechanical waste we've broken down in why AI agents burn tokens, and it compounds with scale: one leader at a 1,000-plus developer organization did the multiplication mid-call and did not like the product.

3. No conflict resolution between sources (about a third)

Covered in depth below, because it deserves it.

4. MCP and tool sprawl (about a third)

Every source got its own server, every server its own keys, and nobody owns the aggregate. Teams described collision-prone shared secrets, agents operating on human credentials with no identity of their own, and onboarding checklists that grew a new integration step per quarter. The MCP standard itself is healthy, an open protocol with broad ecosystem support, which is precisely why unmanaged proliferation is the default outcome: connecting one more source is always locally rational.

5. Dedicated maintenance cost (about 3 in 10)

The quiet one. Teams counted the headcount only after the fact: the part-time curator, the platform squad diverted from roadmap, five teams building five incompatible versions of the same thing. The bluntest summary we heard, paraphrased: an internal system like this needs permanent engineering headcount behind it, or it fails. Organizations that had done the accounting talked about homegrown context the way they talk about running their own email: possible, and mostly a way to spend senior engineers on an undifferentiated problem.

Why does "which truth wins" defeat DIY stacks?

About a third of all conversations landed, unprompted, on the same question: when two sources disagree, which one does the system believe? The wiki says the v1 endpoint retires in Q3; the chat thread moved it to Q1; the code shows it already gone. Two patterns coexist in the codebase and the agent needs to know which one is the standard, not which one is more common.

This is the problem that separates retrieval from resolution, and it is where homegrown stacks structurally give up. Similarity search returns all versions of the truth, ranked by phrasing rather than authority. Generation makes it worse: when a knowledge base contains contradictions, the model tends to fabricate a resolution rather than acknowledge uncertainty. Teams had felt this directly: two engineers getting different answers to the same question, an authoritative-sounding source sending the model down a direction that wasted a day, human opinions in chat outranking the code because they were more recent and more confident.

What makes this fatal for DIY specifically is that resolution requires signals no single team can cheaply assemble: recency with decay, code as ground truth for current behavior, and a model of who actually knows what, built from years of review and authorship activity. A few teams asked to designate subject-matter experts by hand, a reasonable patch that becomes its own stale registry within a quarter. We've compared which tools genuinely attempt conflict resolution; the short version is that almost everything in the category, homegrown or commercial, ranks results and calls it a day.

What did teams want instead?

The asks were consistent enough to read as a requirements document for the category. Ranked by rough frequency across our conversations:

Permission inheritance (close to half): answers must respect the asker's existing access, private channels, restricted spaces, contractor boundaries, without a parallel ACL system to maintain.
Automatic freshness (about a third): the stack should notice change and re-index itself; any design requiring a human to feed it was treated as disqualified on sight.
One integration point (about a third): a single connection that replaces the patchwork, the ask behind every team memory hub evaluation we see. Teams that already owned enterprise search kept asking why it was not enough; we've answered that at length, and so had many of them, empirically.
Conflict resolution with authority (about a third): not more results, a decision, with the losing source shown.
Measurable proof (about a third): benchmarks, evals, before-and-after token numbers; a business case a CFO will read. Skepticism here is earned, given that 84% of developers use or plan to use AI tools while only 29% trust what they produce.
Verifiability (about 3 in 10): citations back to sources, an audit trail, a way for a human to check the answer's work.

Notice what is absent: nobody asked for a bigger context window or a smarter model. The research agrees that the constraint is curation, not capacity: Zylos Research's January 2026 long-context benchmark found models degrade well before their claimed limits and attributed roughly 65% of 2025 enterprise AI failures to context drift, and the wanted list above is a specification for the machinery that does the curating. It maps closely to the upper levels of our context maturity framework: teams were describing, in their own vocabulary, the jump from ad hoc context to a governed, self-maintaining layer.

Where does Unblocked fit?

This is a research piece, so the pitch stays short. The findings above are, transparently, why Unblocked is built the way it is: a context engine that agents reach through one MCP server, with continuous ingestion for freshness, permission inheritance from source systems, and conflict resolution that weighs code, recency, and expertise before anything reaches a context window. It is the managed version of the thing 4 in 10 of these teams started building, minus the parts that made them stop, and unlike memory layers you bolt on and maintain yourself, nobody on your team owns the feeding schedule.

One customer, from our approved public quotes rather than these conversations, describes the day-to-day: "My biggest use of Unblocked MCP has been AI governance — searching across Slack, fourteen Notion docs, S3, trying to understand where data lives and where the gaps are. There is no other way to humanly accomplish this task. It's an absolute godsend for getting context out of sources that don't talk to each other." — Gustavo Alvarez, Software Engineer, Sixfold

Methodology

The numbers in this post come from 194 conversations held between May and August 2026 with engineering teams evaluating context tooling, representing roughly 150 distinct organizations after deduplicating repeat conversations. Organizations ranged from solo technical founders to enterprises with tens of thousands of engineers, across fintech, healthcare, security, gaming, travel, industrial, and public-sector software.

Frequencies are rounded counts of themes that surfaced organically in conversation, not answers to a fixed questionnaire, so every figure is a floor: a team with a staleness problem that never mentioned it is not counted. All figures are deliberately rounded because false precision would overstate what conversation data can support.

The selection bias matters and we want to be honest about it: every one of these teams booked a call with a context-tooling vendor. They are, by construction, predisposed to believe context is a problem worth solving, and builders hitting a wall are exactly the teams most likely to take such a call. This sample says a lot about what happens to teams that build homegrown context stacks, and nothing statistically defensible about what share of all engineering teams build one. Treat the failure-mode frequencies as well-grounded within this population and the headline build rate as an upper bound on the general one.

To protect confidentiality, no company names, verbatim quotes, or identifying details from these conversations appear here; all patterns are aggregated, and the one marked composite is an illustrative construction, not a real individual.

FAQ

Is it ever right to build your own context stack?

Yes, in narrow cases: hard data-sovereignty constraints commercial tools cannot yet meet, genuinely unusual source systems, or context infrastructure that is itself your product. Even then, the honest budget is not the build, it is the permanent staffing to keep the stack fresh, permission-correct, and conflict-aware. If the build vs buy context math only works with maintenance rounded to zero, it does not work.

How much does a homegrown context stack really cost to maintain?

Teams in our conversations rarely knew until they audited it, which is itself the finding. The visible cost is the part-time curator; the invisible costs are the diverted platform squad, duplicate builds across teams, and over-retrieval token waste at fleet scale. General software economics put maintenance at more than half of lifecycle cost, and context stacks skew worse because their core asset, organizational truth, decays continuously.

What should we measure before deciding to replace ours?

Three things, over two weeks: answer accuracy on questions you already know the answers to, staleness lag between a real change and the stack reflecting it, and tokens consumed per completed task with and without the stack in the loop. Teams that ran even informal versions of this evaluation made faster and calmer decisions than teams arguing from anecdote. A structured starting point: our AI readiness assessment.

If you're at the build-vs-buy fork

The 194 conversations behind this post suggest the fork is usually mislabeled. The real choice is not build versus buy; it is who maintains the truth. Building the retrieval pipeline is the tractable, weekend-sized part, which is why so many teams have done it. Deciding which truth wins, noticing staleness before your agents repeat it, and honoring permissions across every source is the permanent part, and it is the same problem at every company. If your homegrown context stack is in act two of the lifecycle, enjoy it, measure it, and set a calendar reminder for act three. If you are already at the wall, you are in numerically excellent company: so was roughly a third of everyone we talked to this year.

Tools That Resolve Conflicting Information Between Docs, Code, and Slack

Dennis Pilarinos — Thu, 20 Aug 2026 09:00:00 +0000

If you need a tool that resolves conflicting information between your docs, your code, and your Slack history, Unblocked is the pick, because it is the only tool in this roundup whose core job is reconciling code, pull requests, Slack threads, and docs into a single conflict-resolved answer, weighted by recency and authority signals instead of similarity scores. That claim deserves immediate qualification, though: almost nothing in this category actually adjudicates between contradictory sources. Most tools retrieve. Some aggregate. A couple ask humans to settle disputes ahead of time. Genuine machine-side adjudication is rare, and pretending otherwise would make this a useless page. So here is the honest landscape, including where each tool's model of truth comes from and where it stops.

Bottom line: aggregation puts three contradictory sources in front of you or your agent and lets you guess. Resolution decides which source to believe, says why, and shows the losing source anyway. Only one tool in this roundup treats that second step as the product; the rest either rank results, stay inside one source of truth, or delegate the adjudication to humans.

Why do docs, code, and Slack disagree in the first place?

Because each one captures a different moment in a decision's life. A doc records intent at the time of writing. Code records what actually shipped, including the compromises nobody wrote down. Slack records the moment the plan changed, usually in a thread with eleven participants and no follow-up edit to the doc. Nothing back-propagates. The Confluence page that says "we retire the v1 endpoint in Q3" stays confident long after the thread that pushed it to Q1, which is how agents end up recommending deprecated APIs with complete conviction.

The problem is compounding. Writing a document now costs nothing, so document volume is climbing while average document authority falls. When three sources disagree, an engineer applies judgment: who wrote this, when, did it ship, did anyone senior push back? An agent treats every retrieved chunk as equally true unless something upstream decides otherwise.

Why does retrieval alone make conflicts worse?

Similarity search has a structural bias toward the wrong answer. Call it the superseded-policy problem: the old policy doc is a polished, keyword-dense statement of exactly the thing you asked about, so it embeds beautifully and ranks first. The correction lives in a rambling Slack thread that mentions the policy once, obliquely, in a reply. Semantic similarity ranks the stale source above the current one almost by design, because clean prose about the topic beats messy prose about the change.

For a human skimming ten results, that is survivable. For an agent, it is fatal, because agents suffer from satisfaction of search: the first plausible hit becomes the truth they act on. A retrieval layer that returns contradictory chunks without adjudication launders stale information into confident output. This is the core reason enterprise search and a context engine are different products: one optimizes for finding, the other for deciding.

What are the tools?

Unblocked: synthesis with conflict resolution built in

Unblocked is a context engine that connects GitHub, GitLab, Slack, Microsoft Teams, Confluence, Jira, Linear, SharePoint, Sentry, Datadog, and more, and, per its documentation, "reconciles information across sources, including sources that contradict each other," answering with citations rather than a results list. Truth is decided by layered signals: code as ground truth for current behavior, recency with decay, and an expert graph built from PR and review activity that weights a statement by who made it. Agents reach the same engine through one MCP server, so the reconciliation happens before anything lands in a context window. It is the only entry here where adjudication is the headline feature, not a side effect.

Glean: broad aggregation, retrieval-ranked

Glean is the heavyweight aggregator. Its workplace search product indexes 275+ app connectors, enforces source permissions in real time, and ranks results using a knowledge graph of people, projects, teams, and processes that personalizes relevance to the asker. That is a serious retrieval system. What its public documentation does not describe is adjudication: when Confluence and Slack disagree, Glean returns both, ranked by relevance, and the reader decides. For general enterprise search that is a defensible design. For engineering truth questions, it is the gap we've written about before: ranking is not deciding.

Atlassian Rovo: Atlassian sources first

Rovo is Atlassian's play, built on its Teamwork Graph connecting teams, work, and goals. Its search combines results from Atlassian apps like Jira and Confluence with connected third-party apps such as Google Drive and Slack, and it respects source permissions. The product page emphasizes agents that automate workflows across that graph. Its docs do not describe how contradictions between sources get settled. If your engineering truth lives mostly in Jira and Confluence, Rovo's home-field coverage is real; if the correction usually lands in a PR review or a code discussion, you are outside its center of gravity.

Sourcegraph: code is the only witness

Sourcegraph takes the cleanest position by refusing the question. Its platform covers code search across every repo, branch, and code host, plus Deep Search, an AI agent that answers natural-language questions about the codebase. Sources of truth never conflict because there is exactly one: the code. That makes it a sharp answer to "what does the system do right now" and structurally silent on "what did we decide" or "why." The code can faithfully implement a decision that was reversed in a design review last week. Code-truth is necessary; it just isn't sufficient.

Guru and Notion AI: humans resolve, the tool serves

The curated-wiki model deserves fair treatment because it does resolve conflicts, just with people. Guru positions itself as a governed knowledge layer: content routes to designated experts for verification, the system flags duplicates and conflicting versions, and stale cards lose their verified status until a human re-blesses them. Notion AI runs enterprise search across Notion, Slack, Google Drive, and GitHub, with a "Verify any page" badge that surfaces in search results and AI citations. Both are honest architectures: adjudication happens at write time, by humans, on a schedule. The limit is throughput. Verification cadences work for policies and runbooks; they cannot keep pace with engineering reality that changes per merge, which is why team memory hubs drift unless curation is someone's actual job.

DIY: freshness heuristics over MCP

The build-it path: wire MCP servers for each source, stamp retrieved chunks with metadata like last-modified dates and deprecation flags, and prompt the agent to prefer fresh sources. More on why this is half a solution below.

Tool	What it aggregates	Resolves conflicts?	How truth is decided
Unblocked	Code, PRs, Slack, Teams, Confluence, Jira, Linear, docs, incidents	Yes, machine-side	Recency, expert-graph authority, review status, what shipped
Glean	275+ enterprise app connectors	No, ranks results	Knowledge-graph relevance, personalized to the asker
Atlassian Rovo	Jira, Confluence, third-party apps like Google Drive and Slack	No, ranks results	Teamwork Graph relevance within permissions
Sourcegraph	Code repositories, branches, code hosts	Sidesteps it	Code is the only source consulted
Guru	Curated cards plus connected knowledge	Flags conflicts, humans resolve	Expert verification; system detects stale and conflicting content
Notion AI	Notion, Slack, Google Drive, GitHub	Yes, by humans	Page verification badges, manual curation
DIY (MCP + heuristics)	Whatever you wire up	Partially	Freshness metadata; authority is left to the agent

How does conflict resolution actually work?

Four signals, applied roughly the way a senior engineer applies them. Recency, with decay: a Slack message from last week outweighs one from last year, but time alone settles nothing. Authority: who said it, derived from who actually builds and reviews that area of the system, not from org charts. Review status: a merged PR carries more weight than a proposal; an approved design doc more than a draft. And what shipped: when a doc and the code disagree about current behavior, the code wins, while the doc gets reframed as intent. Unblocked applies these in combination and, when a conflict cannot be cleanly resolved, surfaces both sides with a weighting rather than silently discarding the loser. That is what makes the output decision-grade rather than merely relevant.

Here is how one customer describes it in practice: "Unblocked is the first MCP queried for everything we look up. It's not just checking the code — the code could be wrong. It pulls the Confluence docs, the feature planning documents, the Slack conversations. We can't use the Slack MCP for legal reasons, so Unblocked is the only way we can access that context. For an engineering manager trying to understand a platform fast, that's the difference." — Sam Younger, Engineering Manager, UserTesting

Note the first clause: the code could be wrong. That is the whole argument against single-source truth, stated by someone living with it.

Can you build this yourself?

Partially, and the honest split matters. The freshness half is buildable. MCP gives you a standard way to connect agents to Slack, Confluence, and your repos, and nothing stops you from stamping every retrieved chunk with last-modified dates and deprecation flags so the agent can prefer newer sources. Teams do this, and it beats raw similarity search.

The authority half is the hard part, because recency is not authority. The newest message on a topic might be a wrong guess from someone who joined last month; the correction that matters might come from the engineer who has owned the service for two years. Deriving that weighting means building an expertise graph from commit and review history, with time decay and defenses against noisy contributors. Unblocked open-sourced a simplified version if you want to see the shape of the problem. Most teams instead pin truth manually in rules files, which rot on their own schedule and quietly degrade agent sessions as they drift from reality.

FAQ

What's the difference between aggregation and conflict resolution?

Aggregation collects sources into one search surface and ranks them; the reader reconciles contradictions. Conflict resolution compares the retrieved sources against each other and applies recency, authority, and shipped-state signals to decide which claim stands, before the answer is composed. Most "all your knowledge in one place" tools do the first and market adjacent to the second.

Can ChatGPT or Claude with connectors resolve conflicting sources?

Not reliably. Connectors hand the model raw results from each source, and the model adjudicates with whatever is in its context window: no expert graph, no review-status signal, no decay model. It will often pick the most confidently worded chunk, which favors polished stale docs over messy current threads.

Do knowledge graphs resolve conflicts automatically?

No. A knowledge graph relates entities, which improves retrieval and disambiguation, and both Glean and Atlassian build on one. Relating a doc to a thread is not the same as ruling on which is correct; that ruling requires an explicit adjudication layer on top of the graph.

How do agents know when a doc is stale?

On their own, they don't; a five-year-old page and yesterday's page arrive as identical text. Staleness has to be computed upstream, from timestamps at minimum, and ideally from whether later PRs, decisions, or conversations superseded the content.

Which truth wins in your stack today?

Run the test on your own system: pick a question your team has actually relitigated, something where the doc, the code, and the Slack thread genuinely diverge, and ask it through whatever your agents currently use. If you get three sources and a shrug, you have aggregation. If you get one answer with reasons and citations, including the source that lost, you have resolution. Unblocked is built for the second outcome; that is the difference this entire category turns on.

Why Wouldn't Claude Code Handle Your Org Context Itself?

Dennis Pilarinos — Wed, 19 Aug 2026 10:00:00 +0000

The scene repeats in almost every evaluation we sit in on. Three weeks into a Claude Code rollout, the pilot team is happy, and someone proposes adding a context engine. The CTO looks up from the deck and asks, near-verbatim: "Why wouldn't Claude solve this problem? Why would we need a third-party solution?"

It's the right question, and it deserves a straight answer rather than a vendor dodge. So here it is. Claude Code is genuinely closing context gaps: CLAUDE.md, auto memory, subagents with their own memory, skills, MCP. For a solo developer on one repository, the built-ins are often enough, and we'll say so explicitly below. What Claude Code structurally won't become is the org-wide, cross-tool, permission-aware synthesis layer, because that's infrastructure, not an agent feature. An agent reads context. Something still has to decide what's true across 50 repositories, Slack, Jira, and Confluence, for every agent and every engineer, with permissions enforced. Whether Claude Code needs a context tool comes down to whether that job exists at your scale. Let's take it apart honestly.

What can Claude Code already do about context?

More than most third-party pitches admit. Per the living Claude Code memory docs, CLAUDE.md files now carry persistent instructions at four scopes: an org-wide managed policy file IT can deploy via MDM, user-level preferences, project files shared through version control, and gitignored local overrides. A .claude/rules/ directory splits instructions into topic files, and rules can be path-scoped so they only load when Claude touches matching files. Auto memory lets Claude write its own notes per repository, loading the first 200 lines or 25KB of its MEMORY.md index into every session, with topic files read on demand. Skills package procedures that load only when invoked. Subagents can maintain their own persistent memory. And MCP connects the agent to Jira, Sentry, Postgres, or anything else speaking the protocol. If your mental model is one flat CLAUDE.md fighting for context window space, it's a year out of date. Any honest case for a context tool has to start from this baseline, not a strawman.

Key Takeaways

Claude Code's built-ins (CLAUDE.md, auto memory, rules, skills, MCP) handle per-user, per-repo context well; a solo dev on one repo often needs nothing else.
The built-ins stop at team truth: auto memory is machine-local, rules files are hand-maintained per repo, and the docs warn that Claude may pick between contradictory rules arbitrarily.
The organizational context layer is vendor-neutral infrastructure; Pragmatic Engineer's 2026 survey found 70% of engineers run 2-4 AI tools at once, and every one of them needs the same answers.
A context engine adds what no single agent will ship: cross-source synthesis, conflict resolution, and permission enforcement across all your systems and all your agents.

Where do the built-ins stop?

At the boundary between one engineer's setup and the organization's truth. Auto memory is explicitly per-machine: the docs state files "are not shared across machines or cloud environments," so the lesson Claude learned debugging your teammate's flaky ingestion job never reaches your session. CLAUDE.md is per-repo and hand-maintained; across 50 repositories that's 50 files that rot independently and need syncing against AGENTS.md and .cursorrules besides. There's no conflict resolution: the docs warn that when two rules contradict each other, "Claude may pick one arbitrarily." And there's no cross-source permission model. Each MCP server is its own credential with its own access rules; nothing checks whether the engineer driving the agent should see what a connector returns from another system. That's the Claude Code organizational context problem in one sentence: every mechanism is scoped to a user, a machine, or a repo, while the truth you need is scoped to the org. The agent re-derives that truth from scratch every session, at inference time, and gets it differently each run. Rules files can't close that gap by getting longer.

Won't Anthropic just build this?

They'll keep building, and the built-ins will keep improving; betting against that would be foolish. But look at what they ship: managed CLAUDE.md, subagent memory, an /init that reads your Cursor and Copilot rules, an /import that carries over a whole agent config. Every feature makes Claude Code better at consuming context. None of them makes Claude Code the arbiter of organizational truth, because that layer is vendor-neutral infrastructure and your org isn't single-vendor. Pragmatic Engineer's March 2026 tooling survey of 900+ engineers found 70% use two to four AI tools simultaneously, and 15% use five or more. JetBrains' January 2026 data shows Copilot, Cursor, and Claude Code splitting workplace usage 29/18/18. Your team runs Claude Code and Cursor and CI review agents today, and will run something else in eighteen months. The layer that knows what's true has to outlive any one agent choice, the way your identity provider outlives any one SaaS app. Anthropic optimizing that layer for Claude alone would make it worse at its actual job. That's why team memory belongs in a hub, not an agent.

What does a context engine actually add?

This is where Unblocked sits: institutional context for coding agents, built as infrastructure rather than as a feature of any one of them. A context engine ingests your repos, Slack, Jira, Confluence, support knowledge base, and docs continuously, resolves aliases and contradictions at ingestion time, and serves synthesized, cited, permission-enforced answers to any agent that asks, over a single MCP connection. The agent stops being the integration layer; the organizational knowledge layer does the assembly before a token hits your context window. One customer put it better than we can:

"You cannot make coding agents work without domain and functional context. We connected and trained Unblocked on our Code repos, Atlassian tools, Internal docs, Product Documentation, KB from Support and Slack history. When an agent asks a question, it gets the full picture — not just the code analysis, but also why decisions were made and what the constraints are. Other tools like Copilot know only the code. That's limited value. Unblocked is a game changer for Coding Agents."

— Raphael Bres, CTO, Tradeshift

Note what he connected: six source families, exactly the surface no per-repo file reaches. And note the phrase "when an agent asks," singular mechanism, plural agents: the same engine answers Claude Code, Cursor, and whatever runs in CI, identically, with each requester seeing only what its human is entitled to see. That's what it means to give Claude Code organizational context instead of asking it to reconstruct some approximation per session.

When are the built-ins genuinely enough?

Honestly: often. If you're a solo developer, or a small team living in one repository with decisions that fit in a couple hundred lines of CLAUDE.md, you don't need us. Keep a tight project CLAUDE.md, let auto memory accumulate what it learns, add a well-chosen MCP server or CLI tool for the one external system you touch, and revisit when something breaks. Even dedicated memory MCP servers are overkill at that scale. The trouble starts on predictable thresholds: multiple repos with shared conventions, decisions living in Slack threads and Jira comments instead of the repo, engineers whose agents answer differently because their private memories diverged, or a compliance team asking who can retrieve what. A useful tell: count how often an agent's answer gets corrected in review with information that existed somewhere but not in the repo. Once that's weekly, the gap is organizational, not personal. Below those thresholds, saying Claude Code needs a context tool would be selling you something. Above them, the built-ins aren't failing; they were never scoped for the job, and no amount of CLAUDE.md gardening rescopes them.

FAQ

Is CLAUDE.md enough organizational context for Claude Code?

For one repo and one team, usually yes. It stops scaling when conventions span repositories, when the reasoning behind decisions lives in Slack and Jira rather than in files anyone maintains, and when contradictions accumulate that nothing resolves. A checked-in file records what someone remembered to write down; institutional memory is mostly the things nobody did.

Can MCP servers give Claude Code organizational context on their own?

They give it access, which is different. A Slack MCP returns Slack messages; a Jira MCP returns tickets. Your agent still does the cross-source assembly at inference time, on your token bill, guessing at project nicknames it has never seen and not knowing which of two conflicting answers is current. Connectors are the transport for organizational context, not the source of it. The synthesis has to happen somewhere, and an agent's context window is the most expensive possible place.

Does a context engine replace CLAUDE.md or auto memory?

No. Keep CLAUDE.md for repo-specific instructions and auto memory for personal working notes; they're good at that, and the docs keep making them better. When people ask whether Claude Code needs a context tool, they usually picture a replacement. It's a foundation: the shared, permission-aware layer the per-repo files silently assume, the thing that knows what the org actually decided, across every repo and every tool, for every agent and engineer.

The one-question test

When the question comes up in your own eval meeting, you don't need our framing or Anthropic's roadmap. Ask one thing: when two sources disagree about how your systems work, what decides which one the agent believes? If the answer is "the engineer notices and fixes it," you're describing the per-repo world, and Claude Code's built-ins will carry you for a while. If the answer needs to hold across 50 repos, four tools, and 200 engineers with different access rights, you've just specified infrastructure: ingestion, synthesis, conflict resolution, permission enforcement, and citations so a human can audit the answer. That spec doesn't shrink because the agent got smarter. And the agent can't grant it to itself, any more than an app can be its own identity provider. So the CTO's question has a clean answer after all. Anthropic will keep making the agent better at reading context, and you should use every bit of it. Someone still has to decide what that context says, and make your organization legible to every agent you'll ever run.

Is Glean Good Enough for Engineering Questions? An Honest Assessment

Dennis Pilarinos — Tue, 18 Aug 2026 09:30:00 +0000

Your company already pays for Glean, the rollout went fine, and now engineering is asking for budget for a separate knowledge tool. Someone on the eval committee asks the question this post exists to answer: is Glean good enough for engineering, or does the team actually need something built for it?

The verdict: for general enterprise search across a whole company, Glean is genuinely good and often enough. For engineering-specific questions, meaning codebase behavior, architecture decisions, and why the code is the way it is, Glean hits structural limits that no amount of configuration fixes. Those limits aren't bugs or missing connectors. They come from what enterprise search fundamentally is: a retrieval system over documents, applied to a domain where the answer is rarely inside any single document.

The short version: keep Glean for company-wide search, where it earns its seat. Treat engineering knowledge as a separate problem, because the properties that make a tool great at finding documents are not the properties that make it good at explaining a codebase.

What is Glean actually good at?

Quite a lot, and pretending otherwise would make the rest of this assessment worthless. Glean connects most of the enterprise stack through native connectors, push APIs for custom or self-hosted systems, and partner-built integrations (Glean docs). Its permission story is real engineering: connectors fetch each source's permission map so results only show a user what they can already see in the source application (Glean docs). That is harder than it sounds, and many homegrown search projects die on exactly that rock.

Its AI Answers feature returns permission-aware responses with citations, and Glean documents that identical queries produce deterministic results (Glean docs). For the HR policy lookup, the sales enablement doc, the security questionnaire answer buried in Drive, Glean is a legitimately strong product with a mature compliance posture. If your evaluation is about knowledge workers broadly, you can stop reading and keep it.

Where does it break for engineering teams?

The problems start when the question is about a living system rather than a stored document. A sales deck from March is still true in August; the code from March is three refactors gone. That single difference in the underlying material drives four limits that show up repeatedly when teams try to use Glean for engineering knowledge, and none of them is fixable with more connectors or better prompt hygiene.

How code-aware is the index?

Glean's GitHub connector indexes repositories, source files, commits, READMEs, issues with comments, and pull requests with reviews and diffs (Glean docs). That sounds comprehensive, but note what it is: code stored as text documents. Glean itself describes its assistant as retrieving indexed content and generating responses from it, drawing on company knowledge, web knowledge, and the LLM's training (Glean docs). Retrieval over text chunks is a reasonable model for prose. Code is not prose. Understanding it requires structure: what calls what, which service owns which behavior, how a function changed across releases. A keyword-relevant chunk of a 4,000-line file is not an answer to "how does billing retry work."

Can the index keep up with daily code change?

Credit where due: Glean's GitHub freshness is decent, with incremental crawls every 10 minutes and webhook-based updates (Glean docs). But freshness varies by connector, with full crawls ranging from 6 hours to 28 days, and missed deletion events wait for the next full crawl (Glean docs). Initial deployment takes two to three days of crawling for a small org, 10 to 14 for a large one, plus another 2 to 14 days of ML training before Glean says you should let users in at all (Glean docs). And one operational gotcha: until each engineer individually completes a GitHub OAuth step, no GitHub content appears in their results at all (Glean docs). Teams discover that one ticket at a time.

Do you get an answer or a reading list?

Enterprise search returns ranked documents; the synthesis burden stays with the engineer. Glean's AI Answers narrow this gap for questions whose answer lives inside one or two retrievable documents. Engineering questions rarely do. "Why do we run two payment providers?" is answered by a 2023 PR review thread, a Slack argument, an ADR that was half-updated, and a Jira ticket that contradicts the ADR. Ten relevant hits with citations is still homework. Worse, when sources conflict, ranking is not resolution; we wrote about why in how tools handle conflicting context and in context engine vs enterprise search.

Where did the "why" go?

Glean's retrieval is also personalized: results are shaped by what each user has access to and interacts with, so answers can differ across users (Glean docs). For document search that is a feature. For engineering truth it is a liability, because "why is the auth service structured this way" has one correct answer regardless of who asks. The why lives in the connective tissue between artifacts, the thing search engines index as separate documents and never join. This is the same gap that hobbles coding agents, which we covered in what your coding agent can't see.

Is Glean's AI enough for codebase Q&A?

For orientation questions, sometimes. "Where is the deployment runbook" or "who owns the notifications service" are retrieval problems, and Glean handles retrieval well. The harder class of question is the one that sends an engineer spelunking through git blame: what does this actually do in production, and is the doc describing it still true? The gap appears at the trust boundary. Stack Overflow's survey data shows 84% of developers using or planning to use AI tools while only 29% trust the output's accuracy, down 11 points from 2024, largely because verifying plausible-but-wrong answers costs as much as doing the work yourself (Stack Overflow, 2026). A RAG answer assembled from whichever chunks ranked highest, personalized per user, over sources that may disagree with each other, is exactly the kind of output senior engineers double-check. Once every answer needs verification against the codebase, the tool has become a suggestion box. Glean for engineering ends up trusted for finding things and distrusted for explaining them, which is a rational response to its architecture, not a rollout failure.

When is Glean genuinely the right choice?

An honest evaluation names the cases where the answer is "keep Glean and stop there." There are several:

Your pain is company-wide findability, not engineering comprehension. If engineers mostly ask "where is the doc," not "why is the code like this," Glean covers it.
Engineering is a small share of the org. A 40-person engineering team inside a 3,000-person company may not justify a second platform until agent adoption forces the issue.
Your codebase knowledge is unusually well-documented. Teams with disciplined, current ADRs feel this gap less, though in our experience they are rare, and homegrown context stacks built to compensate have their own carrying costs.
You need one tool for legal, sales, support, and engineering. No engineering-native platform tries to be that, and Glean is one of the better answers to it.
Procurement reality. If a second vendor review will take two quarters, deploying Glean's GitHub connector today beats a better tool you can't buy yet, and nothing about doing so forecloses adding an engineering platform later.

If two or more of those describe you, the honest read of "is Glean good enough" is yes, for now. Revisit when your engineers or their agents start asking questions the index can't answer.

What do engineering-first alternatives do differently?

The alternative category isn't "better search." It's a context engine: a system that ingests code, PRs, Slack, tickets, and docs, then reasons across them to produce one synthesized, cited answer instead of a ranked list. Unblocked, the engineering-native context engine we build, connects GitHub, GitLab, Slack, Teams, Confluence, Jira, Linear, and more, and explicitly reconciles sources that contradict each other before answering (Unblocked docs). It serves that answer wherever the question happens: IDE and coding agents over MCP, pull requests, Slack, CLI, web. The same institutional-memory layer that answers engineers also feeds agents, which is why teams pair it with tools like Claude Code; see giving Claude Code institutional memory.

Here's how one customer describes the difference in practice: "Unblocked is game-changing for information availability. Most AI tools are siloed. This one connects all of our documentation across the disparate systems to give answers we trust." — James Ford, Principal Engineer for Developer Experience, Compare the Market

For head-to-head detail, see Unblocked vs Glean, the three-way Unblocked vs Glean vs Augment, and the broader field in Glean alternatives.

FAQ

Can Glean search code?

Yes. Its GitHub connector indexes source files, commits, issues, and PRs with reviews and diffs, across common code and text file types, though wikis and GitHub Pages content aren't indexed by default (Glean docs). Searching code as text is the easy half; the hard half is answering questions about behavior and history, which retrieval alone doesn't do.

Is Glean good enough for a small engineering team?

Often, yes. If the team's questions are mostly findability and the org already runs Glean, the marginal pain may not justify a second tool yet. The tipping points are AI agent adoption and codebase archaeology becoming a daily activity.

Does replacing Glean make sense, or do teams run both?

Most engineering teams we see run both: Glean as company-wide search, an engineering knowledge platform for codebase Q&A and agent context. They solve different problems, so this is complement, not rip-and-replace. Our engineering knowledge platform roundup covers how the categories split.

What should we test during a Glean-for-engineering trial?

Ask questions whose answers span systems: "why did we pick this queue," "what broke last time we touched checkout," "which of these two docs is current." Score whether you got a defended answer or a list of links. Our AI tools for engineering teams guide includes more evaluation prompts.

How to decide in one afternoon

Skip the six-week bake-off. Collect the last ten real questions engineers asked in Slack that took a senior person to answer. Run all ten through Glean and through an engineering-native platform. Grade each response on three axes: did it synthesize one answer or return links, did it cite sources you could check, and did it explain why the system is the way it is rather than just where something lives. Glean will win the pure findability questions, and that result is worth respecting. If the why-questions come back as reading lists, you have your answer on whether Glean for engineering is enough, and it took an afternoon instead of a quarter. Whichever way it lands, you'll have decided on evidence from your own codebase rather than anyone's pitch deck, ours included.