This is how every session used to start. Open the terminal, start a new session, and spend the first ten minutes loading context that had already been loaded a hundred times before: which customers were live, what the open blockers were, what happened on the last call, what my team was working on, what had been delivered last week and what still needed to land. I had become a very expensive cache.
The context you carry
You are not forgetting to prompt well. You have prompt templates, reference files, structured inputs. The system produces excellent work. But between sessions, you carry it all - the state of every open workstream, the stakeholder who went quiet, the blocker that is waiting on a third party, the decision that was made in passing two weeks ago and is now load-bearing.
Every time you open a new session you perform a small act of institutional memory recall. The session is intelligent, and you are the persistence layer holding it together.
What a knowledge graph actually does
A knowledge graph is a network of entities and the relationships between them.
Entities are the things that matter to your work. For me: customers, prospects, workstreams, stakeholders, decisions, open commitments. Each entity has observations attached - structured facts the system needs to act on, not notes for my own reference.
Relations connect them. This customer has this blocker. That blocker is owned by that person. That person sits inside this workstream, which is blocked on this dependency.
The graph lives in a flat file in my project repository. It travels with the codebase. It gets committed with changes. At the start of every session, my supervisor command reads the graph before it touches email or runs anything else, so the session opens already knowing where everything stands.
What makes this different
Most knowledge systems assume you will retrieve and act: you capture something, find it later, and do something with it yourself. The value flows through you.
Here, the agents retrieve and act, and my job is to direct and decide.
The mental load I was carrying - customer context, open loops, stakeholder history, integration blockers, what was committed to whom - now lives in the graph. When the supervisor opens each morning, it reads the graph and surfaces what has changed, what is blocked, what needs a decision from me. The agents know which workstream is in which state without me telling them, and the work that was mine to carry is now distributed across the system.
What this enables that did not exist before
Three things changed when the graph went live.
Onboarding collapsed.
When my second AI Evangelist joined in March, the graph had the full state of every customer, every open action, every active blocker. She did not need six onboarding calls to understand the portfolio. The context was already structured and available. The same was true when I onboarded our founding product designer in May - I delivered her Claude Code setup with a full operating system wired in, because the patterns for doing that already existed in the graph.
Sessions start with a briefing, not a blank.
The supervisor reads the graph, cross-references email, identifies what changed since the last session. I arrive to a summary, not a re-loading exercise. The ten minutes I was spending on context-setting is now spent on the work.
The system became genuinely persistent.
Before the graph, my Claude Code setup was a powerful collection of tools that required constant re-briefing to be useful. After the graph, it became an operating system. Something that has memory of its own, carries state between sessions, and knows what happened without being told.
What I got wrong first
I tried to model everything: every sub-workstream, every meeting, every stakeholder interaction as its own entity. The graph became dense and slow to read, and the supervisor was processing two hundred lines of context it did not need.
The correction was discipline: entities only for things with persistent state, relations only where the connection matters for a decision, and observations only for facts the agents act on - not ambient notes, not useful-to-me context that serves no downstream purpose. Capture everything and the graph drowns; capture only what earns its place and it stays fast enough to read every morning.
The insight this produces
I work in AI adoption. My job is to help banks get past the capability overhang - the gap between what AI can do and what their workflows actually use.
The most common failure mode I see is missing architecture. The banks I see struggling with AI chose capable models, built the right capabilities, and then left the persistence problem unsolved. Context lives in people's heads. State resets between sessions. The institutional knowledge that makes the output trustworthy has to be re-loaded manually every time.
The model is perhaps twenty percent of the value; the architecture around it - the memory, the orchestration, the knowledge that persists - is eighty, and most of the AI investment I see still lands in the twenty.
The question worth asking
If you are building with AI, for yourself or for your organisation, there is a question that surfaces the real problem faster than most:
Where does the knowledge live between sessions? And who is carrying it right now?
If the answer is somewhere in the heads of the people using the system, you have found a design problem - and it is the one worth solving before anything else.
The model does not need to be smarter. It needs somewhere to remember.
I write about AI adoption in banking - and what actually happens when agents go into production. Covecta is the platform I help customers build these workflows on.
%201.png)
