Published: 2026-09-09

Two context approaches that look right and stall: the curated-context trap and the MCP plateau

Chapters / key moments (click to jump — plays here on the page)

The line that reframes the problem: for years, you were the context engine. You built it by going to work, asking questions, having PRs rejected, sitting in meetings, and being on call the night production went down. Every new agent session starts without any of that. And the two obvious fixes both plateau — one rots, and the other gets defeated by a documented retrieval bias. The framing worth keeping is that access to information is not understanding: an agent can produce code that compiles perfectly and still take production down, because it never saw the rollout procedure.

Source video

"Your agents lack context: Here's how to fix "You're absolutely right!"" by AI Engineer — Watch on YouTube →

Gotchas & Caveats

The speaker sells a commercial context product and says so; the talk is largely an argument for that category. The two named anti-patterns and the satisfaction-of-search bias are the transferable parts and stand independently of the product.
Client scale is asserted (hundreds of enterprise and mid-market customers, with some large names mentioned) rather than evidenced. Treat the diagnosis as experienced practitioner observation, not measurement.
The six requirements describe what a mature context layer would do; the talk does not show any of them being measured, and building all six is a substantial project rather than a configuration change.
Follows directly from LinkedIn's playbooks talk at the same event, and the speaker references it. Read them together — one is an in-house build of roughly what the other sells.

Key Takeaways

The curated-context trap. Put markdown files describing your project in a folder, let the agent grep them, and results improve — briefly. Then you have to distribute it, so it goes in a repo. And that repo rots like every other doc you have ever written. The unanswerable question underneath: who in your organisation is the omniscient person with the taste to curate this for everyone?
The MCP plateau, and the bias that causes it. MCP servers are genuinely good, but two things go wrong. Depending on how you wrote the server and tool descriptions, your agent may simply never call it when it should. And when it does, satisfaction of search bias kicks in: the agent finds the first plausible answer and proceeds. The example is precise — there is a Slack message from last night saying do A instead of B, and the agent will never find it because it hit an architecture decision record first.
Bad context compounds, and it compounds earliest. The shift-left argument applied to context: a defect is cheapest to find early, and so is missing context. Left uncorrected it becomes doom loops (correct, correct, correct — wasted search tokens and rework), then a review tax on AI code reviewers that lack business logic, then outright blockers for background agents you hoped to leave alone.
What an agent cannot see is everything below the waterline. Compiling code is not the bar; knowing you were supposed to turn off a feature flag first is.
Six things a context layer has to do, per the talk: unify system context across sources; know who you are and where you sit in the organisation, and use that to focus retrieval; resolve conflicts between an old architecture diagram and last night's Slack thread; respect permissions and governance so a restricted project does not leak into an answer; support both deep research and fast targeted retrieval; and deliver context token-efficiently for machine-to-machine use.
Permissions are a context problem, not just a security one. If someone who should not know about a confidential project asks a question, the answer must not contain it — which means the retrieval layer needs to be permission-aware, not just the UI.

What you can actually set up from this

Extracted from the video's own transcript — the specifics the original summary left out.

Reproducible steps

Recognise the curated-context trap
Putting markdown files in a folder or repo and letting the agent grep them works at first, but you then have to distribute it, it rots like other docs, and someone has to have the taste to curate it for the whole organisation.
Recognise the MCP plateau
An MCP server may never be called, depending on how its tool descriptions are written, and agents show satisfaction-of-search bias: they stop at the first piece of information that looks right, so last night's Slack decision loses to an older architecture record. His summary: access to information is not understanding.
What a context engine needs
He lists six characteristics: unified system context across tools, targeted retrieval for quick lookups, conflict resolution between sources, personalised relevance (who you are and where you work), token optimisation, and permission enforcement so restricted information doesn't leak.
Try his open-source tools
A 'social comment network' tool that uses deterministic code over your GitHub to map who works on what and who reviews whom (an optional OpenAI or Anthropic API key adds team labelling); a repo-rules agent that finds every rules file in a repo and flags duplicates and severities so you can index them; and a workshop on a relational context engine with six stacked pull requests, because RAG alone can't answer questions like 'which open PRs touching authentication did I work on last week' without queries over a schema.

Gotchas

This is a vendor talk (Unblocked). His test of the same prompt and model with and without a context engine reported about 10.8 million tokens versus about 21 million, and 'about 50% fewer tokens, faster triage and better answers'; those numbers are the vendor's.
The QR-code links for the tools and the readiness quiz were shown on slides; the page doesn't list their addresses.
He cites a talk earlier the same day for the advice to give the model a map and let it discover the territory.