MemoryGraph는 자동 저장소가 아니다

It seems like attaching memory to the AI ​​agent will solve the problem. But with a development harness, you have to start the other way. MemoryGraph's core value lies not in what it stores, but in what it does not store.

In Part 1, we applied Ctx2Skill's context-to-skill structure from the perspective of the Repo Skill Memory of the development harness. In this article, we will cover how much of that memory should be stored in MemoryGraph.

The conclusion is conservative. MemoryGraph is not a raw trace store. It's not even a place to automatically push failure logs. Only compact rules that have passed replay or human approval should be included in MemoryGraph.

Key takeaways

• MemoryGraph is not a source of truth but a recall acceleration layer.
• The source of truth is code, test, CI, contract, and production behavior.
• Leaving raw traces, imported evidence, and failure logs intact in long-term memory can contaminate subsequent executions.
• Rules resulting from failure must first remain as memory candidates and be promoted after replay or human approval.
• The memory fact must have coverage, exclusion scope, verification basis, and lifecycle metadata.

Where to put MemoryGraph

Separating the knowledge layers of the development harness clarifies roles.

MemoryGraph does not replace a source of truth. It is more like an index that helps agents quickly get to the right source of truth.

The most dangerous mistake: mistaking raw traces for memories

The raw trace has many useful clues. At the same time, there is a lot of noise.

• Command failed due to environmental issues
• One-time failure of flaky test
• Search begins with incorrect assumptions
• plan abandoned midway
• Access denied by user
• Incomplete log imported from external runtime

If we put this information into long-term memory, the agent will follow the wrong rule in the next execution.

1bad memory:2In this project, e2e tests fail frequently, so they are omitted from closeout.3 4Good candidate:5In a recent run, e2e failed due to missing browser binaries.6failure_class is environment_blocker and is not subject to memory promotion for code changes.7Before retrying, check browser dependency availability first.

Good candidates don't hide their failures. However, before elevating a failure to a general rule, it separates the cause from the scope of application.

Promotion Pipeline

MemoryGraph write is the final step. Before that, there must be a candidate and a gate.

It's best to keep the policy for this pipeline simple:

Minimal structure of memory candidate

The candidate must be a verifiable operational knowledge candidate, not just a single sentence.

1{2  "schema": "awtl.memory_candidate.v2",3  "candidate_id": "memcand-demo-a",4  "failure_class": "agent_failure",5  "failure_type": "contract_mismatch",6  "source_action_ids": ["action-12"],7  "root_cause_summary": "Public response shape changed without updating contract evidence.",8  "proposed_memory": "If the public response schema changes, the contract artifact and verifier evidence are updated together.",9  "scope": {10    "applies_to": ["public_api", "contract_change"],11    "does_not_apply_to": ["internal_refactor", "test_only_change"]12  },13  "evidence_refs": ["judge:contract-verifier", "artifact:contract-output"],14  "verification_probe_candidate": "public-contract-regression",15  "promotion_status": "candidate",16  "requires_human_review": true17}

There are four things that should not be left out of this structure.

Divide the failure class first

Not all failures are eligible for memory promotion.

Without this separation, memory becomes corrupted quickly. If you see a job failing due to a network failure and save a rule saying “you can skip this verification,” the next run will be more risky.

A fact lifecycle is needed

Even a memory that was once correct can become incorrect over time. Therefore, the MemoryGraph fact must have lifecycle metadata.

1{2  "origin": "awtl",3  "origin_candidate_id": "memcand-demo-a",4  "validated_by": "replay",5  "valid_for": ["contract_change", "public_api"],6  "not_valid_for": ["internal_refactor"],7  "last_validated_at": "example-timestamp",8  "verification_contract_version": "v1",9  "status": "active"10}

The operational state must have at least the following flow:

The memory put into the prompt should also be small.

Even if you only put verified facts into MemoryGraph, if you inject them all in every execution, they will become noise again. You should only write small recalls that are relevant to the current task.

Good recall looks like this.

1Relevant project memory2- When changing the public API request/response schema, contract artifact and verifier evidence are updated together.3- Scope of application: public_api, contract_change4- Exclusion range: internal_refactor, test_only_change5- Verification: Run the contract verifier before closeout.

Bad recall means pasting the entire project memory as is. Agents may not be able to reliably determine importance and coverage on their own.

Practical Checklist

When designing a promotion policy, check the following items:

1MemoryGraph promotion checklist2 3[ ] Do not use MemoryGraph as a raw trace storage.4[ ] Only read-only recall is performed before the start of the phase.5[ ] projectMemoryContext contains only small and relevant content.6[ ] Memory overlapping with rules, developer instructions, and hard rules is removed.7[ ] Separate MemoryGraph query failure and workflow failure.8[ ] MemoryGraph write is performed only when there is an explicit flag.9[ ] Auto promotion only allows verified-only.10[ ] Block candidates without replay evidence or human approval.11[ ] Imported-only candidates are not promoted to long-term memory.12[ ] Promotion decisions are left on the replay scorecard.13[ ] Design fact lifecycle and stale detection.

finish

Designing the MemoryGraph to be a “place to store a lot” can make the agent more dangerous, not smarter. This is because AI tends to follow memory like a work rule rather than a simple reference.

So the principles must be conservative.

1Read-only recall is widely permitted.2Promotion is allowed narrowly.3Write is allowed only when verified.

In the next part, we will cover AWTL, which is the raw material for this structure. Let's take a look at how we can turn the failure log into a hint for the next run and operate it with a failed turn case and replay scorecard.

Operational example: Criteria for rejecting memory candidates

MemoryGraph Promotion is not a game where you save a lot. For example, let's say one run logs "A specific command failed in Windows PowerShell." This should not be stored in memory as is. This may be a temporary environmental issue, or the path and username may be mixed up. Instead, change to compact rule only when it is repeated three or more times and the cause is confirmed to be a repo convention.

A failure case is to include the raw trace entirely because it is searchable. Next, the agent can use temporary instructions or error phrases in the trace as rules. MemoryGraph must have facts, conditions, reuse scope, and expiration criteria. That way, long-term memory improves the quality of your work and doesn't become a source of noise that keeps replaying old logs.