Graph Engineering Is a Fancy Word for Judgement

There’s been a lot of buzz around graph engineering lately on X.

Really what it is, is just another fancy word for giving your AI the right context so that it can do its job. That’s it. Strip the label off and you’re left with a question every operator has always had to answer: what does this thing need to know in order to be useful?

We’ve been here before. Earlier this year I wrote about the prompt engineering hangover, and the argument was that prompt engineering was the skill of a transitional era. Once agents became goal-oriented and got access to tools, the value moved off instruction quality and onto judgement quality.

Context engineering is the same shape with a new name on it. And in The Model Question I made the case that model choice barely matters, that what separates the teams getting real results is integration and context. Context engineering is that second half finally getting a label.

The What

When you think about context in building agents or workflows or solutions, that is probably the hardest thing to nail down. There are a lot of reasons for it, and the way I like to break it down is the what and then the how.

Start with the what. What context do I need to feed my agent or workflow so that it can do the right job?

That starts with sources. What platform are you using? Is it Granola? Is it Slack? Is it Teams? Is it SharePoint? You start identifying what are the right sources, and then the right information within those sources. Those are two different questions, and the second one is where most of the work actually sits.

For a marketing team this gets concrete fast. The platform exports are a source. The brand guidelines are a source. The QBR deck is a source. So are the meeting notes from the call where the client told you what they actually cared about, which is very often the single most useful artifact in the pile and almost never the one that gets wired up first.

The How

Once you’ve worked through the sources, then it’s the how. What does it look like? How do you share context among your organisation so that you can move fast and make better decisions faster?

Usually I like to use HTML artifacts from Claude to share what that context looks like. MD files are good for agents but pretty bad for the average user. They’re just hard to read. Visually, an HTML artifact that you can share within your organisation will have a much bigger impact than sharing .md files.

That reads like a formatting preference, but the format is what decides whether the context actually circulates. A markdown file sitting in a repo is technically shared and practically invisible to everyone who isn’t already in that repo. Put the same information in something a colleague can open, scroll, and understand in thirty seconds, and it starts getting used, corrected, and improved by people who would never have opened the file.

Agents and humans need the same information in different packaging, and it’s worth building both.

The Easy Reflex

One of the biggest mistakes I see people making with sharing context is that they oftentimes share too much, and too much of not the right stuff.

The reflex is understandable. You have access to everything, so you feed it everything, and you assume the model will sort it out. More context, better output. Except that breaks down in practice, and anyone who has watched an agent confidently build on a stale doc knows exactly why.

The skill that matters is being able to distil the exact information you need to do your job and to give the right context to the agent. Feeding it every single signal and source you have is the easy reflex. The harder part is having the judgement to understand what is worth feeding to the AI and what is noise.

I’ve written about a version of this before. In The Foundation Stays Manual, I explained why I still do the monthly CSV data entry for my finance agent by hand, even though it’s the easiest and most repetitive step in the whole stack. The data is the foundation. If hallucinations slip in there, none of the downstream insights matter. Context is that same principle one level up. Bad context fails quietly. It produces confident, well-formatted, wrong work.

Only good judgement and experience can help you do that. You can train that skill as well.

What to Do With This

Separate the what from the how, and do them in that order. List your sources before you decide on a format. Most teams jump straight to tooling and end up with a beautifully wired pipeline pointed at the wrong information.

Ask the second question about every source. Whether it’s relevant is the first question. What inside it is relevant is the second, and that’s the one that gets skipped. A shared drive is a source. Four documents in that shared drive are the context.

Pick the format for the reader, not the machine. If the audience is an agent, markdown is fine. If the audience is your team, build the artifact they’ll actually open.

Practice cutting. Before you hand over a source, make yourself name what in it the agent actually needs. If you can’t, you haven’t done the thinking yet, and the agent won’t do it for you.

That last one is the whole thing, really. It’s also the least satisfying, because it looks less like building and more like sitting with a pile of information and deciding what matters, which is the same unglamorous work that separated good operators from average ones long before any of this.

So before you go build the next agent, the question is simpler than the buzzword makes it sound. What are you feeding it, and how much of that does it actually need?

I think that’s one of the most underrated skills to have for optimising how we share context within an organisation.