TELOA BLOG

Project memory: retaining decisions without making them permanent

Project conversations automatically yield supported decisions and experience. Later related work receives background and applicable memory according to settings, reducing repeated explanation while preserving room for correction and change.

As a project grows, users are less willing to explain the background at every start. If a pilot was agreed yesterday, they expect the employee to work from that decision when another discussion begins today. Saved chat is one step short of that continuity: the system needs to preserve useful content from discussion and prepare it when related work begins.

Compressing chat can turn tentative ideas into rules. Keeping only the final sentence can make its reasons inaccessible to later participants. Project memory has to handle both certainty and change.

A decision needs more than a conclusion; it needs a basis for confirmation. Teloa connects it to its source and keeps ambiguous views, conflicts, and candidates open for further judgment.

From discussion to automatic use in later work

Suppose a new service introduction is being prepared. The user first says “perhaps we should emphasize scale,” then examines implementation conditions and finally states: “Confirmed: the first version covers only the pilot scope.”

The first statement suggests a direction. The last establishes the current requirement. Treating both as lasting rules would preserve competing goals. Extracting only the final keywords could lose the provisional scope and the reason for it.

Community already connects automatic extraction to project work. With the project’s relevant accumulation setting enabled and long-term memory permitted for the conversation, the background process reads user messages and verifiable work evidence after a relevant turn completes normally. It extracts rules, decisions, or experience and automatically saves eligible content, without requiring a separate request to remember every point. The evidence determines how each proposal is handled:

  • Decisions or requirements with explicit supporting evidence that meet the current accumulation rules can be saved automatically as project content.
  • Unverified interpretations and same-topic conflicts remain candidates for the owner to assess against the original message.

When work continues in a conversation associated with the project, the system automatically prepares the goal, existing brief, active rules, and required material. Permitted optional memory, including project and role experience, is selected by relevance, scope, and the current input budget. Users do not need to find each old memory and paste it into a new message; “Used this round” lets them inspect what was actually included.

The change is practical: an agreed requirement to limit the first version to the pilot scope can become a ready basis for later writing, rather than a historical message the owner has to find again. This automatically organizes supported entries; it does not rewrite the entire project brief or send every employee the full history unconditionally.

Keeping the reason helps explain an exception

“The first version covers only the pilot scope” may reflect material intended only for pilot customers. When the audience changes, the decision may no longer apply. An absolute rule could keep later assistants avoiding content that now belongs in the document.

Sources let people revisit the context and identify the version and scope the decision concerned. Project experience therefore needs more than a short, tidy summary. It needs enough relationships to explain what the decision means.

“Which material was used in this turn?” and “Is that material’s judgment reliable?” are also separate questions. Fixed versions and dispatch records can establish the first; the second still requires reading the material. Project experience retains these different kinds of evidence, so a confirmed technical fact about use is not mistaken for a business conclusion.

Preserving these distinctions suits a long project better than asking a model to supply a certain answer for every ambiguity. People can address candidates and conflicts directly, instead of discovering changed context only after an error reaches a report.

Project memory consequently has a responsibility beyond summarization. A summary explains material; a decision record also needs a basis for governing later work. Without confirmation, a candidate is more appropriate than a fabricated conclusion. When conditions change, revision matters more than mechanical consistency.

A changed decision needs more than an appended sentence

When an old requirement no longer applies, adding “use a different approach from now on” may leave the original experience entering future inputs through an old summary, an assistant reply, or a shared copy.

Current corrections and withdrawals preserve revisions and constrain later reading. When a source is withdrawn or is no longer valid, related automatic entries and shared content follow its status; having already been copied does not keep them valid. History remains available for people to read. Whether the model can obtain it again is decided separately.

This is more involved than deleting a sentence from memory, but it addresses the actual dependencies. Users need to change the basis for future work while retaining an explanation of why earlier work followed the old requirement.

Pausing automatic accumulation and turning off a conversation’s long-term memory have different effects. Pausing stops new experience from being formed while existing valid memory remains readable. Turning long-term memory off disables that conversation’s long-term reads and writes; the project goal, rules, selected material, and current messages still supply necessary background. Users can control accumulation and use without abandoning the current work.

Sharing between projects needs a specific revision

When experience is adopted across projects, a fixed revision gives the recipient a definite basis. The source can continue changing while the recipient compares and explicitly adopts an update. Work in progress does not silently change because another project was edited. Current sharing is limited to the owner's own projects.

This follows the same principle as correction within a project: history explains the past, and current valid requirements organize future work. They need a connection and separate maintenance.

Mature project memory does not give every discussion a definite answer. It carries established decisions forward, leaves unresolved matters open, and supports an accurate change of direction when new facts arrive.

Original
1.0×

Double-tap or pinch to zoom. Drag to explore.

Keep reading

All articles
Engineering

Knowledge, memory, and skills: maintaining working capability

All three can be text, but their reasons for changing and maintenance responsibilities differ. Teloa retains facts, experience, and methods separately, then combines them for execution.

Engineering

From the library to this turn: how working context is formed

Projects prepare known background, retrieval adds specific evidence, and suitable content enters the turn. Together they reduce material transfer and keep analysis connected to both its goal and its sources.