The recent explosion of interest in "context graphs" reveals a troubling pattern in our industry: the rush to rebrand existing concepts without understanding the foundational knowledge beneath them. This isn't about context graphs themselves—which you can read about in my series of articles—but about what their meteoric rise tells us about the state of technical expertise in AI and data engineering.
The Barefoot Expert Problem
More than two years ago, I entered the knowledge graph field as a complete novice. My background was in cryptography, Self-Sovereign Identity, and protocol architecture—not knowledge representation or machine learning. I was honest about my gaps and systematically built expertise through study and practice. Today, I can confidently discuss knowledge representation, agent architectures, and graph-based systems because I invested in understanding the foundational corpus of knowledge.
This journey taught me something crucial: expertise is acquirable. Skills can be learned. Knowledge can be built systematically, layer by layer, through dedicated study and practice. There's no magic involved—just consistent effort, intellectual humility, and a willingness to engage with difficult material.
What I observe now, with growing concern, is a different pattern entirely: instead of acquiring knowledge, people are reinventing concepts without engaging with decades of existing research. Context graphs exemplify this perfectly. They combine two trendy terms—"graphs" (riding the AI hype wave) and "context" (currently everywhere in prompt engineering discussions)—but offer almost no explanation of why they matter, how they work, or how agents actually use decision traces and contextual information.
The phenomenon I've written about as "barefoot experts"—practitioners who wade into complex technical domains without proper preparation—has reached epidemic proportions. These aren't bad people or unintelligent engineers. They're simply operating in an environment that rewards speed over depth, marketing over mastery, and novelty over nuance.
The Enterprise Theater
These frameworks make for impressive presentations to investors. They're shiny enough to generate buzz, vague enough to avoid scrutiny, and perfectly packaged for enterprise consumption. The pitch decks are beautiful. The diagrams are compelling. The promise of "revolutionary" technology is intoxicating.
But beneath the marketing veneer lies a fundamental problem: we're ignoring established engineering knowledge. We're reinventing wheels that were perfected decades ago, often making them square in the process.
The concepts supposedly "invented" by context graphs already exist in multiple mature fields:
Causal inference theory has given us sophisticated frameworks for understanding cause-and-effect relationships in complex systems. Judea Pearl's work on causal graphs, do-calculus, and counterfactual reasoning provides rigorous mathematical foundations for exactly the kinds of problems context graphs claim to solve. These aren't vague aspirational concepts—they're precise, testable, implementable frameworks with decades of refinement.
Temporal causality analysis addresses how causality unfolds over time, handling the complexities of delayed effects, feedback loops, and time-varying relationships. Granger causality, event calculus, and temporal constraint networks all tackle problems that context graph proponents position as novel challenges. The mathematics exists. The implementations exist. The literature exists.
Promise theory, developed by Mark Burgess, provides a robust framework for understanding cooperation and coordination in distributed systems without central control. It's directly applicable to multi-agent architectures, yet rarely mentioned in contemporary AI discussions. Instead, we get hand-wavy descriptions of "context sharing" without the theoretical foundation to make it reliable.
Actor theory gives us formal models for concurrent computation, message passing, and distributed reasoning. Carl Hewitt's work from the 1970s addresses challenges that modern "context graph" systems are supposedly solving for the first time. The irony would be amusing if the consequences weren't so serious.
We pretend these foundational frameworks don't exist—not out of malice, but out of ignorance. We simply don't know they're there because we haven't done the work to learn them. The knowledge is available, well-documented, and often freely accessible. What's missing is the commitment to engage with it.
The Illusion of Innovation
There's a seductive narrative at play: "Traditional approaches are too complex, too academic, too slow. We need something new, something agile, something that works with modern AI systems." This narrative is compelling because it contains a kernel of truth—some academic work does remain disconnected from practical application.
But the solution isn't to abandon foundational knowledge. It's to bridge the gap between theory and practice, to translate academic insights into engineering reality. Instead, we're seeing a wholesale dismissal of prior work, often by people who haven't actually studied it.
Context graphs are presented as if they emerged fully formed from the unique challenges of large language models. But the problems they address—maintaining coherent state across interactions, tracking dependencies between decisions, reasoning about temporal sequences—are not new. They've been studied extensively in knowledge representation, temporal reasoning, plan recognition, and numerous other established fields.
The "innovation" often amounts to taking existing concepts, stripping away the mathematical rigor that makes them reliable, adding a trendy name, and wrapping the result in modern tooling. This isn't progress. It's regression with better marketing.
The Cost of Hype-Driven Development
When you have a hammer, everything looks like a nail. When you don't understand how to use that hammer, you break things. And when those things are critical systems that people depend on, the consequences extend far beyond your organization.
The democratization of AI tools has created a generation of "barefoot data scientists"—people with powerful tools but without the foundational expertise to use them responsibly. Large language models, in particular, have lowered the barrier to entry for building AI-powered systems to the point where almost anyone can create something that appears to work in a demo.
But "appears to work in a demo" and "works reliably in production" are separated by an enormous gulf of complexity. The results of bridging that gulf without proper expertise are predictable and dangerous:
Unreliable categorizers built on LLMs when specialized machine learning models would work better, faster, and more reliably. LLMs are remarkable tools, but they're not the right tool for every classification task. Traditional models—decision trees, random forests, gradient boosting machines, SVMs—often outperform LLMs for structured categorization tasks while being faster, cheaper, and more interpretable. Yet I see organizations replacing proven systems with LLM-based alternatives simply because "AI is the future."
Multi-agent systems designed without understanding actor theory or promise theory. These systems exhibit all the classic distributed systems problems—race conditions, deadlocks, inconsistent state, unbounded message queues—that were solved decades ago in the process calculus and distributed systems literature. The solutions exist, but they require study to apply.
Knowledge graphs constructed without ontological engineering principles. The result is brittle, inconsistent schemas that break as soon as real-world complexity enters the picture. Ontology engineering isn't just academic exercise—it's the accumulated wisdom of what actually works when modeling complex domains.
Temporal reasoning systems that ignore decades of research in causal inference. These systems confuse correlation with causation, fail to handle confounding variables, and produce unreliable predictions because they lack the mathematical foundations to reason correctly about time-varying phenomena.
The pattern repeats across domains: powerful tools in the hands of people who lack the theoretical foundation to use them properly. The tools themselves aren't the problem. The absence of expertise is.
The Real Foundation: Data Strategy
Here's the secret that shouldn't be a secret: 80% of AI strategy is data strategy. It's data management, knowledge management, and knowledge engineering. The most sophisticated model architecture or the most advanced agent framework will fail if the underlying data foundation is weak.
This isn't glamorous work. It doesn't make for exciting conference presentations. It's the unglamorous labor of:
Establishing data governance frameworks
Building robust data pipelines
Creating consistent ontologies
Maintaining data quality
Managing metadata effectively
Ensuring data lineage and provenance
Handling data versioning and evolution
If you want to work with agents, you need to understand much more than prompt engineering:
How agents communicate: Not just the syntax of messages, but the semantics, the protocols, the error handling, the guarantees about message delivery and ordering. This requires understanding message-passing systems, communication protocols, and distributed systems fundamentals.
How multi-agent systems coordinate: The challenges of reaching consensus, avoiding conflicts, maintaining consistency, and achieving cooperation without central control. Promise theory, game theory, and mechanism design all contribute insights here.
What actor theory teaches us: Formal models of concurrent computation, encapsulation of state, asynchronous message passing, and the creation of new actors. These concepts are directly applicable to modern agent systems but rarely referenced in contemporary AI literature.
What promise theory teaches us: How autonomous agents can cooperate reliably without central coordination, how to reason about distributed systems in terms of voluntary commitments rather than imposed obligations, and how to build resilient systems that gracefully handle partial failures.
How to make distributed systems reliable: Techniques from decades of distributed systems research—consensus algorithms, replication strategies, failure detection, recovery mechanisms, state synchronization. These aren't optional extras for production agent systems—they're fundamental requirements.
You can ride the hype wave. You can make money on buzzwords. You can build impressive demos that wow investors and generate press coverage. But without genuine expertise, you risk destroying your organization with systems built on foundations of sand.
The Expertise Gap
The gap between what we need and what we have is widening. Organizations are rushing to deploy AI systems, agent architectures, and knowledge graphs without the engineering expertise to build them properly. The pressure to move fast—to beat competitors, to capture market share, to satisfy impatient stakeholders—creates incentives that actively discourage the patient work of building genuine expertise.
This manifests in several ways:
Shallow implementations that barely work: Systems that function adequately for narrow use cases but break catastrophically when conditions change or scale increases. They work until they don't, and when they fail, nobody understands why or how to fix them.
Cargo cult engineering: Copying patterns and architectures without understanding why they work, leading to systems that superficially resemble robust solutions but lack their essential properties. The form is there, but the substance is missing.
Technical debt accumulation: Quick solutions built on shaky foundations that become increasingly difficult to maintain, extend, or debug. Eventually, the system becomes so fragile that any change risks collapse.
Knowledge silos and single points of failure: When one or two people understand how a critical system actually works, their departure becomes an existential risk. Without proper documentation and knowledge transfer—which require understanding the system well enough to explain it—organizations become dangerously dependent on individuals.
The Path Forward
If your organization is serious about AI and agent systems, you need actual expertise—not just access to tools. This requires investment, commitment, and patience:
Find knowledge engineers or build that expertise internally. This doesn't mean hiring people with "knowledge engineer" on their LinkedIn profile—that title is rare and often means different things to different people. It means finding people with strong foundations in relevant fields: ontology engineering, knowledge representation, semantic web technologies, graph databases, causal inference, or distributed systems. These people exist, but they're often working in academic settings or specialized domains rather than mainstream tech companies.
Study ontologies and knowledge representation. Understand the difference between a taxonomy and an ontology. Learn about description logics, semantic reasoners, and constraint languages. Engage with standards like RDF, OWL, and SHACL not as boring enterprise requirements but as distilled wisdom about what actually works for knowledge representation at scale.
Learn from established fields like causal inference. Judea Pearl's "The Book of Why" provides an accessible introduction. Dive deeper into structural causal models, do-calculus, and identification strategies. Understand how to move from correlation to causation rigorously rather than through intuition.
Understand the mathematics that solves real problems. This doesn't mean becoming a pure mathematician. It means developing sufficient mathematical literacy to read papers, understand proofs, and apply formal methods where appropriate. Category theory, for instance, provides powerful abstractions for reasoning about complex systems, but you need to invest in understanding it.
Engage with knowledge management research. People like Jessica have been writing about knowledge management, knowledge graphs, and their practical application for years. This literature isn't just academic—it's grounded in real-world experience of what works and what doesn't.
The alternative is to keep producing "yet another context graph expert" who tries to solve everything with React and prompt engineering, building unreliable systems on unreliable foundations. These practitioners mean well, but good intentions don't compensate for inadequate knowledge.
The Organizational Challenge
Building this expertise isn't just an individual challenge—it's an organizational one. Companies need to create environments where deep expertise can develop and be valued:
Time for learning: Engineers need protected time to study foundational material, not just sprint from feature to feature. This requires explicit organizational support, not just lip service to "continuous learning."
Mentorship and knowledge transfer: Senior people with deep expertise need incentives to teach junior engineers, write documentation, and build organizational knowledge rather than just delivering features.
Hiring for depth, not just velocity: The interview process should assess understanding of fundamentals, not just ability to quickly solve leetcode problems or implement trendy frameworks.
Valuing maintenance and improvement: Rewarding engineers who improve existing systems, pay down technical debt, and build robust foundations rather than only those who ship new features.
Cross-functional collaboration: Breaking down silos between research and engineering, between data science and software development, between academia and industry.
These cultural and organizational changes are harder than adopting new tools or frameworks. They require sustained commitment from leadership, but they're essential for building genuinely capable organizations.
Choose Engineering Over Hype
We stand at a crossroads. One path leads toward engineering rigor, mathematical foundations, and expertise built on decades of research. This path is harder. It requires patience, study, intellectual humility, and sustained effort. It doesn't generate quick wins or impressive demos as readily.
The other path leads toward buzzword-driven development, reinvented wheels, and systems that look impressive in demos but fail in production. This path is easier in the short term. It aligns with market pressures, generates excitement, and can even be profitable—for a while.
The choice seems obvious when stated this starkly, but in practice, the pressures pushing toward the second path are enormous. Investors want growth. Executives want results. Competitors are moving fast. The market rewards those who ship quickly and iterate rapidly.
But here's the reality: systems built without proper foundations eventually fail. The technical debt compounds. The bugs multiply. The edge cases proliferate. The system becomes unmaintainable. And when it fails, the cost is far higher than if we'd built it properly in the first place.
A Call for Intellectual Honesty
What we need, fundamentally, is intellectual honesty. We need to:
Acknowledge what we don't know: There's no shame in being a beginner or having gaps in knowledge. The shame is in pretending expertise we don't possess.
Respect existing work: Before declaring something "novel" or "revolutionary," we should thoroughly investigate whether the problem has been studied before. Often, it has—and the existing solutions are better than what we could quickly devise.
Invest in understanding: Quick tutorials and blog posts have their place, but deep expertise requires engagement with primary sources, formal treatments, and rigorous material.
Value precision over excitement: Vague, hand-wavy explanations might generate buzz, but precise, mathematical formulations actually solve problems.
Build on solid foundations: Every field of engineering builds on the work that came before. Software and AI engineering should be no different.
The knowledge is there. The frameworks exist. The mathematics works. Causal inference provides rigorous methods for understanding cause and effect. Temporal reasoning gives us tools for handling time-varying phenomena. Promise theory offers models for distributed coordination. Actor theory provides formal semantics for concurrent systems. Knowledge representation research has produced robust approaches to modeling complex domains.
All of this exists, documented, peer-reviewed, and waiting to be applied. We don't need to reinvent it. We need to learn it, understand it, and apply it thoughtfully to modern problems.
The Way Forward
Don't just grab the latest hype term and run with it. Pause. Investigate. Understand the foundations. Ask hard questions:
What problem are we actually trying to solve?
Has this problem been studied before?
What does the existing research tell us?
What are the mathematical foundations?
How do experts in relevant fields approach similar challenges?
What can we learn from systems that have operated at scale for years?
Build real expertise, not just familiarity with the latest tools. Study the fundamentals, even when they seem distant from immediate practical application. Engage with difficult material. Work through the mathematics. Read the papers. Understand the proofs.
Apply good engineering practices. This means:
Writing clear documentation that explains not just what the system does but why it works
Building robust error handling and recovery mechanisms
Creating comprehensive tests that cover edge cases
Planning for maintenance, evolution, and eventual replacement
Thinking about operations, monitoring, and debugging from the start
Considering failure modes and building resilience
The knowledge is there—decades of it, waiting to be learned. Researchers in causality, temporal reasoning, distributed systems, knowledge representation, and related fields have produced an enormous corpus of valuable work. Much of it is freely available. What's missing isn't access—it's commitment.
The question is whether we're willing to do the work. Are we willing to invest the time to build genuine expertise? Are we willing to study foundational material even when it's difficult? Are we willing to value depth over velocity, rigor over rapid iteration, expertise over enthusiasm?
The future of reliable, robust AI systems depends on our answer to these questions. We can continue down the path of hype-driven development, producing an endless stream of "revolutionary" frameworks that rebrand existing concepts without understanding them. Or we can choose the harder path of building genuine expertise, applying rigorous methods, and creating systems that actually work reliably at scale.
The choice is ours. But make no mistake—only one of these paths leads to systems we can trust with important problems. Only one leads to a sustainable engineering practice. Only one honors the decades of research that came before us and builds something lasting for those who come after.
Choose wisely.