# What 194 Engineering Teams Told Us About Their Homegrown Context Stacks URL: https://getunblocked.com/blog/homegrown-context-stacks/ Published: 2026-08-21T09:30:00Z Author: Dennis Pilarinos Categories: Engineering Insights, Context Engine Original data from 194 conversations with engineering teams: how homegrown context stacks get built, the five ways they fail, and what teams want instead. --- 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. ## 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](https://getunblocked.com/blog/rules-files-vs-context-engine/), 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](https://www.prnewswire.com/news-releases/ai-agents-are-only-the-beginning-deloitte-survey-examines-the-ai-readiness-gap-and-reveals-how-enterprises-can-prepare-for-agentic-success-302848848.html), 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](https://ragaboutit.com/7-rag-failure-modes-crippling-enterprise-deployments-in-2026/) 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](https://getunblocked.com/blog/mcp-tool-overload/), 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](https://code.claude.com/docs/en/memory) 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](https://zylo.com/blog/build-vs-buy-software-pros-and-cons), 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](https://getunblocked.com/blog/ai-agent-deprecated-api/) 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](https://atlan.com/know/rag-accuracy-problems/), 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](https://getunblocked.com/blog/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](https://modelcontextprotocol.io/docs/getting-started/intro), 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](https://atlan.com/know/rag-accuracy-problems/). 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](https://getunblocked.com/blog/conflicting-context-tools/); 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](https://getunblocked.com/blog/team-memory-hubs-ai-agents/) evaluation we see. Teams that already owned enterprise search kept asking why it was not enough; [we've answered that at length](https://getunblocked.com/blog/is-glean-good-enough/), 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](https://stackoverflow.blog/2026/02/18/closing-the-developer-ai-trust-gap/). - 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](https://zylos.ai/research/2026-01-19-llm-context-management/) 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](https://getunblocked.com/context-maturity/): 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](https://getunblocked.com/blog/unblocked-context-engine-for-agents/), 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](https://getunblocked.com/blog/build-context-layer-engineering/), and unlike [memory layers you bolt on and maintain yourself](https://getunblocked.com/blog/memory-mcp-servers-compared/), 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](https://readiness.getunblocked.com/). ## 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.