What Building an AI Agent Taught Me About Knowledge Graphs
I was deep in configuration hell.
My AI agent had a memory problem. Not the kind where it forgets what I said five minutes ago, the kind where it has too much information and cannot find the right piece at the right time. Flat text files, vector embeddings, keyword indexes. I tried them all. With smaller language models, none of them worked reliably.
The agent could retrieve similar text, but it could not retrieve context. It would find a document that mentioned the right term but attached to the wrong situation. It would surface a skill that was technically relevant but at the wrong level of abstraction. A clinical decision support system that worked this way would be dangerous, pulling up a treatment protocol for the right disease but the wrong stage, or the right drug but the wrong patient population.
So I architectured something different.
The Hierarchical Memory Architecture
The system has four layers, each connected to the next:
Layer 1 — Core Survival Kit. Critical instructions the agent cannot act without. These are few in number and never change. Alongside them: an indexed map of every skill the agent possesses, like a library catalogue.
Layer 2 — Navigational Skills. These contain no data. They are pure structure, skills that teach the agent how to approach problems systematically. How to break a task down. How to escalate when stuck. How to cross-reference before acting. They are the agent's epistemic foundation.
Layer 3 — Secondary Skills. Higher-order functions that carry domain knowledge. Clinical guidelines. Research workflows. Financial management. These skills point to each other and to the layer below.
Layer 4 — Long-Horizon Skills. Deep knowledge domains that the agent only reaches when the task demands it. Rarely used but essential when needed.
The agent enters at Layer 1, its identity. From there, it traverses edges based on the task. A simple expense log stays in Layer 2-3. A research question about guideline harmonization descends all the way to Layer 4.
The Colleague Who Named It
I was explaining this to a fellow medical doctor specialised in Health Informatics. When he said something that stopped me: "You've built a knowledge graph."
I had heard the term. I had not studied it. But when I looked at what the literature said, the mapping was immediate. Knowledge graphs represent entities as nodes and their relationships as edges. They support traversal from general to specific. They encode the real world not as isolated facts but as connected structures. Exactly what I had built through practical necessity, but in a much better way.
What the Survey Says
A 2026 survey by Sherafatmandjoo, Akbari, and Rahmati maps five domains where knowledge graphs are transforming clinical AI:
1. Clinical Decision Support Systems. KGs augment rule-based and ML-driven engines with structured biomedical knowledge. Recommendations become knowledge-grounded, not just data-driven.
2. Disease and Treatment Outcome Prediction. By integrating genomics, comorbidities, and treatments as a connected graph, prediction models can traverse relational paths invisible in tabular data.
3. Health Recommender Systems. The same logic that powers product recommendations works for exercise, diet, and screening, constrained by medical validity encoded in the graph.
4. Precision Medicine. The most natural fit. Patient profiles as subgraphs overlaid on population-level biomedical knowledge.
5. Medical Question Answering. KG-augmented QA grounds answers in verified relationships rather than parametric memory, reducing hallucination.
What struck me most was the survey's observation that graph construction (how KGs are built) and graph application (how they are used) remain poorly connected. The same gap exists in AI agent design: the memory architecture and the task architecture often evolve independently.
Why This Matters for Health Informatics
Healthcare data is inherently relational. A diagnosis connects to symptoms, which connect to treatments, which connect to outcomes. Traditional machine learning flattens these relationships into feature vectors. Knowledge graphs preserve the connective tissue.
For anyone building clinical AI systems in Sri Lanka or similar settings, the implication is practical. Knowledge graphs are not an academic luxury. They are an architectural choice that determines whether your system can explain itself, whether it can integrate heterogeneous data sources, and whether it can reason across domains.
KGs encode what you know, how things connect, and where the gaps are. In a setting where the cost of a wrong clinical recommendation is measured in patient outcomes, that traceability is not a nice-to-have — it is a requirement.
Where This Leaves Me
I am still early in understanding knowledge graphs. I arrived here through a practical problem (building an agent memory system that works with smaller models) and found an entire field waiting. The survey by Sherafatmandjoo et al. validated what I discovered through engineering and gave me a vocabulary for it.
If you work in health informatics and have not explored knowledge graphs, I would encourage you to start. Not because they are the latest AI trend — but because they solve a problem you are almost certainly facing: how to make your systems reason rather than just retrieve.