Agentic Trader Docs

Memory And Review

How trading memory, review evidence, and contributor notes stay separate and inspectable.

What memory means to an operator

For an operator, memory means the evidence that helps explain a decision:

  • prior runs that were retrieved as similar context
  • market context packs and data-quality flags
  • specialist and manager outputs
  • broker/account state used during review
  • persisted traces, trade context, and review snapshots
  • source attribution, freshness, and missing-evidence notes

Memory is inspection support. It is not hidden permission to trade, and it should not silently mutate broker, risk, or runtime policy.

Review evidence

When a result looks suspicious, review evidence in this order:

  1. provider and market artifacts, including as_of, freshness, completeness, and fallback state
  2. runtime state, supervisor state, and logs
  3. broker/account status, execution outcome, and rejection reason
  4. specialist and manager outputs
  5. persisted review snapshots and UI behavior

Do not jump from "the answer feels wrong" straight to "the prompt must be rewritten". First verify what data, state, and evidence the system actually saw.

Trading memory versus contributor notes

Agentic Trader also has contributor-facing repo memory. That includes:

  • .ai/current-state.instructions.md
  • .ai/tasks.instructions.md
  • .ai/decisions.instructions.md
  • .ai/qa/*
  • docs pages that explain current working assumptions

Those files help maintainers keep the project aligned. They are not the same as the product's trading memory, similar-run retrieval, or review evidence shown to an operator.

When contributor notes should change

Update .ai notes when a change affects:

  • runtime behavior
  • product direction
  • developer workflow
  • frontend or docs architecture
  • QA expectations
  • safety boundaries

Docs responsibility

This docs site is part of the contributor-maintained knowledge base, but it should be written for operators first. Whenever a durable decision changes, the right follow-up is usually:

  • update the implementation
  • update the relevant docs page
  • update .ai/current-state.instructions.md
  • update .ai/decisions.instructions.md
  • update .ai/tasks.instructions.md if work remains

The key wording rule: describe product memory as decision/review evidence, and describe .ai files as contributor notes.

Feedback flow in plain language

The GitHub Pages docs build cannot write to the repository filesystem. Its feedback widget stores a short browser-local draft and prepares a prefilled GitHub issue link for manual submission.

If a future Node-hosted docs instance re-enables server-side feedback, it should keep local auditability explicit and avoid pretending that external forwarding succeeded when it did not.

How was this page?
This GitHub Pages build prepares a browser-local feedback draft and a prefilled GitHub issue. Node-hosted local docs can still wire feedback into runtime logs later.

Stores a draft in this browser and gives you a GitHub issue link to submit when ready.

On this page