Agent Workflow and Memory Policy

Agent workflow and memory policy

Language: English · 简体中文

The most important LWC capability is not a command. It is the Agent's ability to recognize the right moment to recall, verify, write back, or deliberately skip memory work.

The automatic decision loop

classify -> recall once -> inspect current evidence -> solve
         -> capture at verified milestones -> validate -> finish

This loop keeps LWC proactive without turning every small task into knowledge maintenance.

Trigger matrix

Situation	Agent action
New substantive session	Resolve the project once, load bounded context, and run one task search.
Context compaction or resume	Restore enabled strong tags and only task-relevant memory.
Research, debugging, or design	Recall prior evidence and decisions before repeating the investigation.
Structural code question	Check CodeGraph once and use it if ready.
Document relationship question	Check the document graph once and use it if ready.
Non-Markdown input	Explain and configure one optional converter only when conversion is needed.
Verified milestone	Update one existing Page or create one distinct retrievable Page.
Contradiction or stale claim	Inspect cited evidence, then revise, qualify, or retract the claim.
Task end after Wiki changes	Lint the changed scope and run fixed retrieval acceptance.

When to skip LWC

Skip memory work for:

• spelling or formatting changes;
• a one-line literal edit;
• a self-contained translation with no project context;
• a fact with no plausible future reuse;
• routine test output or progress updates.

If a task is substantive but no durable result has been verified yet, use LWC for recall and leave write-back for the milestone.

Session start

The Agent should bootstrap the current working root once and require one unambiguous project boundary. It then performs bounded recall:

lwc --scope all context --limit 25
lwc --scope all search "task terms" --limit 20

Do not repeatedly rerun bootstrap or broad recall in the same working root. Widen retrieval by one query, kind, scope, or granularity at a time after a miss.

Readiness and consent

Lifecycle Hooks can report:

• whether the project Wiki exists;
• document graph configuration and projection readiness;
• CodeGraph runtime and project-index readiness;
• optional Markdown conversion configuration;
• Agent integration checks;
• enabled strong-tag context.

Detection is not consent. Automatic activation may read bounded authorized memory, but it may not:

• initialize a missing project Wiki unless invocation or project policy authorizes it;
• enable a document graph;
• build a CodeGraph project index;
• install or select a converter;
• write durable memory without a verified milestone and the required scope authority.

When graph capabilities are missing and relevant, ask once in plain text:

1. Enable the document graph and CodeGraph (recommended)
2. Enable the document graph only
3. Enable CodeGraph only
4. Later

Choosing “Later” changes nothing and must not block the primary task.

Recall policy

Start with a budget, not with the whole Wiki:

• context --limit 25;
• one search --limit 20;
• one to five full Pages;
• cited Sources only when exact evidence or freshness matters.

Strong-tag autoload is also bounded by tag priority, Page count, character budget, and Page boundaries. Hooks report omissions instead of truncating a selected Page in the middle.

Write-back policy

Write back only after verification. Strong triggers include:

• a user-accepted decision;
• a root cause proven by code or runtime evidence;
• a corrected stale claim;
• a reusable recovery procedure;
• a source-backed synthesis;
• a stable preference or project rule.

Update an existing Page when possible. Do not create a new Page solely to mirror the current chat.

Task completion policy

Memory maintenance is complete only when:

1. every persisted claim has current evidence or explicit provenance;
2. dependent writes published atomically when needed;
3. lint reports no issues introduced by the update;
4. fixed original and paraphrased queries retrieve the expected Page in the top five;
5. optional Work reached succeeded and graph verification passed where relevant;
6. no secret, transient detail, or unsupported conclusion was stored.

Failure-resistant behavior

• If project scope is ambiguous, stop project-memory work rather than falling back to global writes.
• If Wiki knowledge conflicts with checked-out code, treat current code as implementation evidence and investigate the difference.
• If a Work is queued or running, watch it instead of treating command exit as completion.
• If a changeset conflicts, preserve live work and rebuild the draft; do not force it.
• If optional maintenance would delay the user's deliverable, finish the deliverable first.

Next: Sources and ingestion