Project State

What Agentic Trader can do today, what is still experimental, and which V1 boundaries should not move.

What Agentic Trader can do today

Agentic Trader is already more than a prototype. Today it can:

run strict local paper cycles through the existing Python runtime
build and persist market context, decision features, review snapshots, and runtime artifacts
expose runtime, provider, broker, research, and supervisor status through CLI, Rich, Ink, observer API, and Web GUI surfaces
keep local paper as the default broker backend while making real-money activation explicit, manually approved, audited, and kill-switch protected
show readiness gates for model/provider health, runtime mode, and Alpaca paper preparation
package QA evidence through smoke runs and evidence bundles

The docs should explain that product reality in plain operator language, then link to implementation details where they help.

The current hardening track is focused on:

making runtime, provider, and model health easier to inspect
improving onboarding and setup quality
keeping web surfaces thin and contract-aligned
making docs useful for operators, not only contributors
expanding research-sidecar evidence ingestion without giving it broker or execution authority

Ungated live trading is still blocked; V1 active trading must pass the supported broker, approval, audit, risk, and kill-switch gates.
Turkey-specific symbols, KAP/CBRT evidence, TRY/FX accounting, and the Turkey broker/data route are V2 scope.
CrewAI research flow is a runtime-controlled research sidecar, not the main trading runtime or a broker/policy owner.
SEC EDGAR submissions metadata is opt-in and metadata-first; full filing text, transcripts, macro series, KAP, and richer vendor ingestion are still future provider work.
Web GUI and docs are local shells around runtime contracts, not alternate trading engines.

The Python runtime remains the source of truth.
webgui/ delegates to existing runtime contracts instead of replacing them.
docs/ explains product behavior and contributor boundaries; it is not a runtime.
Paper trading remains the default execution posture.
Fallback paths must stay explicit and inspectable.

The target behavior is to let the application supervise Ollama through the same status and log surfaces already used for runtime diagnostics.

That means:

The longer-term onboarding target is a guided setup flow for macOS, Linux, and Windows that can:

This docs site is now expected to cover more than setup. It should explain: