Context That Dreams: Context Engineering 2.0 [Testμ 2026]

The Context Layer Problem

Organisational information arrives from everywhere: Teams, Zoom, Outlook, Jira, Confluence, shared drives. The context layer exists so that every AI solution in the estate can borrow from one common store rather than each building its own.

Typically that store is chunks and embeddings, or a knowledge graph, holding the relationships between something said on Teams and something written in Confluence or Slack.

His example of the payoff is one most engineers have now felt. Ask a coding assistant to build a login page and it already knows, from a Confluence document it was never pointed at, which design system your team uses.

Retrieval, Memory, and Grounding

Context engineering as practised today is retrieval plus augmentation. An agent issues a query, context is pulled from the knowledge store, and the model reasons over what came back to compose an answer.

At the core engineering level, that transaction is forgotten the moment it completes. Memory is a second layer bolted on top, and once memory grows large enough it gets summarised so a session can continue.

Then comes the constraint the rest of the talk is built on. If the context does not contain something, retrieval returns nothing.

Jaydeep was clear that this is grounding working as intended rather than a defect. If the context never says who the prime minister of India is, the system should decline to answer even though the model knows.

The cost of that discipline is what interests him. The same rule that prevents invention also blocks any conclusion that lives across two documents rather than inside one.

Context Engineering 2.0

Having described a well-built context layer, Jaydeep put a question to it: is it a brain? His answer was no, because a brain talks back, correlating two pieces of information to produce a third.

The analogy he used to make it concrete is entirely human. A friend tells you over coffee that she is done with her job and wants a change, and the conversation ends there.

Days later another friend mentions two open roles on his team and no good candidates. That conversation also ends. Ten days after that, in the shower, your brain connects them and concludes the two should meet.

That connection is not hallucination, because the brain stayed inside the two facts it already held. In code he calls the equivalent process dreaming, and the library he wrote exposes it as a method that starts exactly that traversal.

He paused the argument to disclaim the obvious reading. This is not a claim about AGI or consciousness, and what runs in code is a simulation. As he put it, you can model a kidney in software, but the laptop still will not urinate.

Framed against the older model, version 1.0 is a filing cabinet holding structured knowledge you can retrieve at any time, which he was careful to say is both good and necessary. Version 2.0 asks whether those files can produce new files, and whether the collection can keep growing on its own.

The Flaky Test That Wasn’t

The example from his own team at Piramal is the one that should land hardest with a testing audience, because each individual signal looked unremarkable.

• A developer says in standup that the login test is flaky and has been marked to skip.
• Two days later, support Slack reports that complaints doubled this week, with users getting logged out on Fridays.
• Deployment notes in Confluence record that a session timeout conflict change went live on Monday.

Read together, the test was never flaky. It was the first alarm for a session bug, and nobody had the three facts in front of them at once.

Jaydeep’s position is that a context layer already holding all three should derive that conclusion and surface it unprompted, then keep the derived conclusion as context for every AI system downstream.

Six Building Blocks of a Knowledge Graph

To show how a graph gets built, Jaydeep took a plain sentence: Priya Sharma leads the insights API team, and the insights API depends on the events pipeline.

Discard the prose and three things remain worth keeping. Priya, the insights API, and the events platform each become a node, joined by edges reading leads and depends on.

Shown only that diagram, he pointed out, a reader reconstructs the original sentence unaided. The six components that make it work:

• Node - a thing worth remembering. In the flaky test example, the login test, the session timeout change, and Priya are all nodes.
• Edge - a claim connecting two nodes, such as leads or depends on.
• Type - the category sitting under a node, such as person or system, so that adding a new statement reuses an existing type instead of minting a duplicate.
• Summary - a one-line description of the node drawn from its neighbours, such as a login test flaky since Monday and skipped in CI.
• Provenance - the record of where the belief behind a node came from, which is what makes any derived claim traceable later.
• Schema - the accumulated set of types, growing as new kinds of information arrive.

Adding a second sentence shows the mechanism. The insights API already exists as a node, so nothing is duplicated, and only the events platform is added with its own provenance pointing at that sentence.

A third sentence about a platform upgrade slipping introduces a node of a different type again, in that case a risk.

Multi-Hop Retrieval

The payoff arrives with a question none of those three sentences answers: who do I talk to about the launch?

Under pure grounding the answer is nothing, because no document contains it. The graph resolves it in two hops instead.

The launch is a milestone that depends on the events platform, which is the first hop. Priya is the person who leads that platform, which is the second, and Priya is therefore the answer.

Nothing was invented at any point. The answer was assembled from relationships already recorded, which is the distinction the whole approach rests on.

The Nodeex Pipeline

Jaydeep wrote the six components into an open library called Nodeex, installable through npm and usable as a studio where you connect sources and build your own graph.

Once sources are connected, the pipeline runs in six stages:

• Acquire - pulls documents and information from the connected sources, whether that is Jira, a GitHub organisation, or anything else.
• Distill - parses those chunks into readable text.
• Extract - an LLM identifies what is worth remembering, because doing it by hand across that volume is not viable.
• Resolve - deduplication, where an entity that already exists in the graph is recognised rather than recreated.
• Schema - an LLM defines the types the new material belongs to.
• Human review - the nodes and edges are shown for inspection before anything is committed to the graph.

He kept that final stage deliberately manual. His view is that committing to the graph should not be left to a model, at least not yet.

The finished graph is queryable through a playground and exposed through APIs, so other systems such as a coding assistant can draw on it directly.

Ideas Across Eight Lenses

Retrieval is only half of what the graph does. Each node continuously examines its neighbours, looking for relationships that would justify a new idea.

That examination runs through eight lenses: contradiction, dependency, recurrence, transfer, timing, trajectory, gap, and collision.

A critic layer then scores each candidate from 0 to 10 on whether it makes sense within the graph, and surviving ideas are emitted as events other systems can subscribe to.

The loop runs continuously rather than on request, which is what makes the derived context arrive unprompted instead of only when somebody thinks to ask.

Demo: A Personal Second Brain

The demo was an application built on the same graph, capturing conversations from work and personal life and assembling them into a personal second brain. Jaydeep had roughly a hundred conversations recorded over four months.

Ideas surface on their own as the graph consolidates. Opening one shows which parts of the brain were analysed to produce it, which is provenance doing exactly the job it was designed for.

One example he showed came from two unconnected conversations weeks apart, one about someone’s daughter looking for an internship and another about a team needing interns.

Rejecting an idea feeds back into how that class of idea gets generated, and any idea can be opened up and traversed further through conversation.

He also demonstrated sharing a single region of a graph with another user, at which point that fragment attaches itself into the recipient’s own brain and works out where it belongs.

Orphan nodes were visible in the interface, still searching for somewhere to attach. His team built their context layer a few months ago and are now working toward something that processes information rather than only storing it.

Q & A Session

The session closed with audience questions from the chat.

• Will context engineering stay a craft or get automated away?

  Jaydeep: The pipeline has to be automated, because organisational information is not static. It arrives daily, and even a passing exchange with a colleague is context. What stays a craft is how you do it, and the space between context and intelligence is where someone will build something nobody has thought of yet.

• What guardrails stop context that dreams from becoming context that hallucinates?

  Jaydeep: While writing the library it did drift outside the boundary of the context layer. The guardrail is that a large part of any generated idea must come from available nodes, so the system has freedom to derive but no freedom by design to leave the graph. He was candid that it can still hallucinate, since creative ideas sit close to that line, which is why rejecting an idea feeds back into how the eight lenses generate the next one.

• How close are autonomous context cleaners that sanitise, deduplicate, and rank before the LLM?

  Jaydeep: Fairly close. Deduplication and sanitisation already run inside the pipeline, and a context layer gets built in stages: sanitise first, deduplicate second, then rerank as new context arrives. When new information lands, the whole structure recalibrates automatically. He still keeps human review in place by design rather than delegating that judgement to a model.

• Who should access a concept derived from a public document and a private meeting?

  Jaydeep: A personal second brain stays private to its owner, with masking applied before anything is published outward. In an organisational knowledge layer, the authorisation and authentication layer sits above the graph and controls who sees which source. He considers this largely solved, citing early HR chatbots that surfaced colleagues’ salaries as the lesson that taught the industry to build proper role-based access.

His closing framing was that a context layer should not act only as a memory store. It should also propose, surfacing concepts the organisation has not articulated yet while staying inside what it already knows.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.