Modern engineering systems generate information everywhere.
Repositories contain code and documentation. GitHub records issues, pull requests, reviews, releases, and deployment history. Cloud platforms expose runtime behavior through logs, metrics, traces, and incidents. Engineers accumulate workflow knowledge through repeated execution.
The earlier notes in this research thread argued for repo-centric workflows, structured evidence, local agent drivers, and repositories as operational execution surfaces. This note narrows the next boundary: if those surfaces all produce useful evidence, where should durable knowledge live?
As AI-assisted workflows become more common, a new challenge emerges:
Where should knowledge live?
The temptation is to create another layer.
Another database. Another context store. Another agent memory. Another configuration system.
Most of the time, this increases complexity instead of reducing it.
Reliable engineering systems evolve differently. Operational truth should remain where it can be validated.
Truth Has Owners
Each engineering layer already has a job.
Runtime behavior belongs to runtime systems.
Implementation behavior belongs to repositories.
Workflow history belongs to GitHub.
Credentials and execution authority belong to trusted execution environments.
Human intent belongs to humans.
The role of automation is not to create new sources of truth. Its role is to connect existing ones.
That distinction matters because AI can produce more interpretations than an engineering system can safely absorb. If every interpretation becomes a new durable surface, the organization gets more context but less certainty.
The healthier model is narrower:
observe the owning source
connect it to related evidence
act within the trusted boundary
promote only the lessons that deserve to survive
Execution Produces Evidence
Every execution produces evidence.
A deployment succeeds. A workflow fails. A pull request receives review feedback. An incident reveals an operational gap.
The immediate result may be temporary, but the lesson can become durable.
This is the feedback loop that matters for AI-assisted engineering. The useful output of an agent session is not only the patch, answer, or command result. It is the evidence that shows whether the operating model became clearer.
Did the repository explain the workflow well enough?
Did GitHub preserve the review and release trail?
Did runtime systems expose the operational result?
Did the trusted environment enforce the right execution boundary?
Did a human make the judgment that should stay human?
Those questions keep automation grounded in sources that can be checked later.
Memory Is Promotion
Engineering memory emerges through promotion.
A repeated observation becomes documentation.
A recurring workflow becomes automation.
A useful pattern becomes a reusable guide.
A validated lesson becomes part of the operating model.
The challenge is not capturing everything. The challenge is deciding what deserves to survive.
Most execution details should remain temporary. Logs, command output, chat transcripts, intermediate guesses, failed branches, and exploratory notes are useful while work is active, but they are not automatically durable knowledge.
Durable memory needs a better test:
Will this help the next human, agent, workflow, or incident response
make a better decision from the owning source?
If the answer is yes, promote the lesson to the smallest appropriate layer: a repository doc, script, test, workflow, issue, pull request, release note, incident record, operational runbook, skill, or public research note.
If the answer is no, let it remain execution residue.
Do Not Invent New Wells
This leads to a simple principle:
Do not invent new wells.
Extend existing engineering layers only when the new capability has a clear owner, a clear boundary, and no better existing home.
That principle does not reject memory. It rejects unowned memory.
A context store is useful when it is attached to a clear workflow and can point back to the source it summarizes. A generated repo context file is useful when it is derived from repo-owned evidence and can be regenerated. An agent skill is useful when it captures a repeatable workflow with clear triggers and safety rules. A runbook is useful when operations owns it and runtime evidence can validate it.
The weak version is different: a pile of copied snippets, summaries, and inferred policy that slowly becomes easier to consult than the system of record.
That creates drift.
The new layer starts as convenience. Then it becomes authority. Then the owning source stops improving.
The Operating Model
Reliable systems are not built from accumulating more context.
They are built from preserving truth in the right place and continuously refining the paths between those truths.
AI expands the solution space.
Humans shape operational reality.
Repositories preserve implementation truth.
Runtime systems expose operational truth.
Engineering memory emerges from the feedback loops connecting them.
The operating model is therefore not a larger memory system. It is a promotion system:
execution evidence
-> human judgment
-> owning source
-> validated reuse
-> stronger next execution
That is the practical boundary for automation. Use AI to connect the evidence faster, inspect more surfaces, and suggest better repairs. Keep operational truth where it can be validated. Promote memory only when it has an owner, a boundary, and a reason to outlive the session.