Why Do I Have To Keep Re-Explaining My Work to AI?

For many engineers, the following scenario is frustratingly common when working with LLMs.

You start a new session to tackle a problem similar to the one you worked through with the same tool only yesterday. After a few non-starter outputs, it becomes clear that the context that feels so fresh in your head never made it into this new chat.

So you describe the problem again. You upload the same reference files, identify the current revision, restate the constraints and governing standards, and explain the decisions and lessons that got you here. Only after reconstructing the context you thought was already there can you get to the actual work.

For one engineer, that is a frustrating waste of time. Compounded across an organization, those delays start to show up in program cycle time. Furthermore, when program history and context live with experienced engineers, repeatedly asking them to reconstruct it turns them into a bottleneck and pulls them away from higher-value tasks. As AI moves from isolated experiments into everyday engineering work, that cost only grows.

You keep re-explaining your work because a standard LLM session does not arrive with your team's working context. A better prompt will not fix that, and neither will a memory setting. It takes a context engineering system: one that records knowledge, ties it to the work where it was created, decides when it is relevant, and traceably carries it into the next task.

In this article, I'll explain the mechanism behind why this happens, and how to approach building a system that makes AI part of your engineering process instead of a blank conversation every time.

Why every new session starts fresh

Standard AI tools do not automatically retain context across sessions because the LLM under the hood is stateless. In plain language, the model doesn’t automatically carry your working context from one session to the next.

Each time you ask an LLM a question or assign it a task, it responds using the context available for that request: your prompt, any conversation history the application includes, and information its tools can retrieve. That context shapes the response, but it does not retrain or permanently change the model during the interaction. If the application doesn’t save and provide that context again, the experience effectively resets. In a future session, the model behaves as if that context had never been provided.

That is why what looks like memory usually comes from the application around the model. The application may resend or summarize an earlier conversation, store selected details, or retrieve files. But the model can only use what is made available for the current request.

Frontier LLM providers have released features to address this limitation:

• Projects allow users to curate context for a defined scope, consolidating manual effort upfront as context is leveraged in subsequent sessions. 
• Memory, which is less a retention of every interaction, but more of a summarization of your behavior, preferences, and the tools you use to better personalize outputs. It holds context about you, not about what you are working on. 

These features still have limitations. Memory improvements to retain interaction context are happening, but likely won’t be comprehensive due to the noise generated across sessions relative to a target topic. Memory retrieval doesn’t provide a citation back to a source you can verify.

Furthermore, neither Projects nor Memory creates knowledge that was never recorded. These models are designed inherently by the biggest players to be general; applicable to the widest possible market and not tailored to any particular application. Organizations looking to best leverage these tools must provide explicit context, knowledge, and detailed prompting for relevant outputs.

The system that carries context forward

A system that retains context over time and surfaces decisions when they are relevant is the future of context engineering. The goal is not simply to make manual setup faster, but to reduce how often engineers need to do it.

Such a system has five jobs:

1. Record the knowledge
2. Connect it to the work
3. Make it searchable
4. Decide when it matters
5. Bring it into the task at the right moment

1. Record the knowledge while the work is happening

The first step is actually recording the data. For most engineering teams, a lot of knowledge is poorly documented, spread across different tools, or simply locked in the heads of their subject matter experts.

In one product development team we work with, the manager was also the main product expert. Reviewing and advising a new team consumed effectively all of his role and left him with no projects of his own. About half of that review burden, he estimated, was repeating information he had already given and explaining why earlier decisions had been made. Documented records showed that a change happened, but not why, so he was the only place that reasoning existed and thus became the retrieval system.

For AI to reason based on historical engineering decisions, teams must capture more than the final change. A reusable record should include the issue, the decision, why it was made, what it affected, proposed solutions, and supporting evidence. It is critical to write effective, descriptive documentation that an LLM can ingest without having a direct line to the engineer who wrote it. If we cannot get the information out of people’s heads and into a digitized format, LLMs cannot take advantage of it. That is non-negotiable.

2. Connect each record to its engineering context

Knowing that a tolerance issue occurred is useful. Knowing which design and revision it affected, where it was found, what impact it had, and how it was resolved is far richer. Those relationships allow a system to retrieve knowledge based on its engineering context, not just the words it contains.

Imagine an engineer asking what production issues to watch for on the design in front of them. A relevant tolerance issue exists as a row in a standalone project spreadsheet. Search might miss it unless the engineer names the spreadsheet or uses similar terms recorded in the row.

If that issue is instead stored in a system that links it to the affected design file, the design itself becomes a path to the record. The system can bring issues from similar designs into its answer as relevant context, even if the engineer did not know it existed or think to ask about it. That is the value of preserving the relationships around a design record: they help the system understand where the knowledge belongs and when it matters.

3. Make the knowledge ingestible and retrievable

Once records are connected to their engineering context, the system has to make their contents searchable. For a defined scope, that may mean curating files in a project. At an organizational level, it requires an ingestion engine that can process and index records from different tools without losing the relationships between them.

Since engineering data is incredibly complex, this is more difficult than indexing ordinary text. In one of our early AutoReview trials on a multi-page drawing, results were noisy and incomplete despite the file containing the relevant views, notes, dimensions, and symbols. The team iterated on deeper automatic segmentation and classification of data present during pre-processing of the file before the review stage kicks off. AutoReview’s output contained more relevant findings after these adjustments.

Information can be present without being usable. CAD geometry, drawings, and other engineering data must be represented and indexed in forms that retrieval engines and LLMs can interpret.

‍Read more: Is my engineering data ready for AI?

4. Add intelligence about when information is relevant

Once knowledge has been indexed, the system needs an intelligence layer that understands when to use and surface it. Engineering teams often assume they can throw a ton of context at an AI tool and it will find whatever it needs. As the body of indexed data increases, retrieval precision starts to decrease.

Without curation and a process for deciding when information is relevant, the system can miss a useful lesson that does not resemble the current request or return a long list of technically related but unhelpful results. Every retrieved decision should come with a traceable source so the engineer can judge whether it applies to the current requirements, design, or tradeoff.

5. Bring the right context into tasks at the right moment

The last piece, and one I think many AI companies are not thinking about enough, is proactively surfacing lessons, decisions, and data points based on the context of an engineer’s work. Engineers should not need to know exactly what exists or what to search for before the system can help them.

Imagine reviewing a new part iteration and seeing relevant issues from reviews of similar designs surfaced automatically. Instead of rediscovering those issues, the engineer begins with lessons from earlier programs already in view.

This is the standard context engineering systems should work toward (and what we’re building at CoLab). As engineers add new records to the same connected system, today’s work becomes context for tomorrow’s. Over time, the system can put relevant knowledge in front of engineers when it matters, augmenting their judgment rather than replacing it.

Curated knowledge is the real investment

The critical piece that connects the entire system is curated knowledge. If the reasoning stays in people’s heads, or is captured in records an LLM cannot understand, no model can reuse it. A larger context window does not record a decision, preserve its engineering relationships, decide when it matters, or show the source. It only gives you more room to supply that work yourself.

The five-part context engineering system I outlined above is one way to solve the blank-page AI problem. You can build this system yourself. But taken together (in-workflow capture, descriptive records, geometry-aware processing, ingestion, retrieval, relevance logic, citations, and delivery) it is a serious undertaking. If engineers still have to rebuild that context at the start of every session, you haven’t solved context retention but rather moved the work into the prompt.

‍Read more: Should a capable engineering organization just build its own AI?

That is why leaders should evaluate purpose-built systems, not just models. CoLab is built around the knowledge engineering teams already create in their work: files, feedback, standards, checklists, and decisions. Today, AutoReview can search customer-uploaded standards for each check and cite them in its feedback. When an engineer gives Operator a task, it can search connected CoLab data, synthesize a response, and link the engineer back to its sources. Those are request-driven ways to reuse context. Proactively surfacing relevant lessons before an engineer knows to ask is the next standard we’re building towards.

So, why do I have to keep re-explaining my work to AI?

Because a new task has only the context its surrounding system carries in.

To solve this problem, stop treating the perfect prompt or the largest context window as the answer. Decide how your organization will get high-quality knowledge out of people’s heads and into a system that can reuse it. That is what lets AI build on work your team has already done instead of asking your best engineers to explain it again.

‍Subscribe to AI Office Hours for more practical answers from the team shaping AI strategy for companies like Schaeffler, Bombardier, and GE Appliances.