System thesis
Case study
Agentic Alpha Engine
Local-first agentic market-intelligence workbench with ingestion, storage fabric, planner agents, verification, and structured Fusion reports.
Primary evidence: Terminal demo, UI demo, UI screenshot
At a glance
- Orchestration
- Planner, tool calls, workflow state, verification
- Storage fabric
- Postgres, Redis, Qdrant, MinIO, OpenSearch
- Inference
- Ollama/local model experimentation
Repo assetsTerminal demo, UI demo, UI screenshot
Report shapeStructured Fusion reports
Responsible useEngineering demo, not financial advice
System problem
Why this system exists.
Research workflows need ingestion boundaries, storage, retrieval, planning, verification, state, and report contracts before any conclusion is trusted.
Implementation surface
What was built.
- API and worker entry points.
- Agent orchestration and verification.
- Storage/retrieval adapters.
- Public non-advice framing.
Architecture
A system map for the project.
Public market/macro data -> ingestion adapters -> normalization -> vector/object/search stores -> agent planner -> tool calls -> verification -> structured report/API/UI.
A local-first agentic system with separate ingestion, memory, planning, verification, and Fusion report surfaces.
Signal Ingestion
market signalsmacro contextpublic research
Storage Fabric
PostgresRedisQdrantMinIOOpenSearch
Agent Core
plannertool callsstate graphOllama
Verification
rulescitationsFusion reportAPI/UI
How it works
Input, transformation, model or agent logic, and reviewable output.
Signal ingestion
Public market and macro signals move through explicit ingestion adapters so source boundaries are inspectable.
Normalization and memory
Evidence lands in relational, vector, object, cache, and search layers for different retrieval needs.
Agent planner
The planner coordinates tool use, state, retrieval, and synthesis instead of relying on one free-form prompt.
Verification and Fusion report
Structured outputs are constrained by verification rules before being promoted to report/API/UI surfaces.
Evidence
Screenshots, responses, diagrams, tests, and model tables from the source repos.
Artifacts are included only where the public repo has enough context to show them safely.
AlphaQuant UI demo
Terminal setup demo
Workbench screenshot
Engineering Decisions
Use finance as an architecture testbed
The domain forces evidence, retrieval, time sensitivity, and report discipline without implying trading automation.
Separate memory responsibilities
Postgres, Redis, Qdrant, MinIO, and OpenSearch make state and retrieval responsibilities explicit.
Keep it local-first
Docker and Ollama keep the stack inspectable and reproducible on a developer machine.
Validation / reliability
How the system is made reviewable.
- Python source and scripts compile.
- Runtime paths depend on local service availability.
- README limits financial interpretation.
- FastAPI API and worker entry points.
- Docker Compose local research stack.
- Separated state, storage, and retrieval services.
Limits / responsible use
Research/engineering demo only. Not financial advice, investment advice, or live trading.
- Planner, tools, memory, verification, and reports are separated so failure points can be inspected.
- Storage layers have distinct responsibilities instead of being presented as interchangeable infrastructure.
- Finance-like examples are framed as architecture evidence, not trading automation or investment advice.
Repository
Open the source repo and inspect the implementation boundary.
All public examples are synthetic, sanitized, historical, or research/demo implementations. No PHI, PII, employer-confidential data, proprietary claims data, private keys, production credentials, or sensitive datasets are included.