LangAlpha: a persistent-workspace agent harness for financial research

The problem: one-shot prompts do not match how research actually works

The README makes the argument directly: every AI finance tool treats investing as one-shot, ask a question, get an answer, move on. LangAlpha's counter-claim is that real investing is Bayesian, meaning a thesis is stated, new data arrives, and conviction gets updated over weeks. The project frames itself as a vibe investing agent harness, borrowing the term from vibe coding. The intended user is someone doing recurring research on a theme (the README's own examples are Q2 rebalance, data center demand deep dive, and energy sector rotation) rather than someone who wants a single quote or a one-off summary. That framing sets the scope: this is a workbench for sustained analysis, not a market data API with a chat wrapper.

Workspaces, agent.md, and how the persistence actually works

The mechanism is a workspace per research goal. According to the README, the agent interviews you about goals and style, produces a first deliverable, and saves everything to the workspace filesystem. Each workspace maps to a dedicated sandbox with structured directories and a notes file called agent.md that compounds research across sessions and threads. Two other stores sit alongside it: a long-term memory store at .agents/user/memory/ and .agents/workspace/memory/ for durable preferences and cross-sandbox knowledge, and a user-managed memo store at .agents/user/memo/ where you upload PDFs and markdown notes for the agent to read on demand. The design choice worth noting is that memory is split by scope rather than kept in one blob. User preferences and workspace-specific findings do not overwrite each other, which matters when you run several research goals in parallel and want a preference set once to apply everywhere. The trade-off is that you now have three places to inspect when the agent behaves as if it remembers something you did not intend.

Programmatic tool calling and why raw data does not enter the context window

LangAlpha's stated approach to data volume is programmatic tool calling, abbreviated PTC in the README and reflected in the source path src/ptc_agent/. Instead of pouring raw financial data into the LLM context window, the agent writes and executes Python to process data from MCP servers. The README claims this enables multi-step analysis while reducing token waste. The companion feature is progressive tool discovery: MCP tools load as summaries in context, with full documentation dumped into the workspace, so the agent reads the full spec only when it decides to use a tool. Skills can also bind JSON tools and expose them only when the skill activates. If you have used an agent that loads every tool schema up front, the difference is concrete: the context budget goes to analysis rather than to documentation the agent may never read. The cost is an extra discovery step per tool, and a failure mode where the agent picks the wrong tool because it only saw a summary.

Getting it running: Python 3.13, PostgreSQL, Redis, and the FastAPI backend

The repository targets Python 3.13 or newer, per the badge in the README. The backend lives under src/server/ and is FastAPI, the agent core under src/ptc_agent/, the web UI under web/ (React 19, Vite, Tailwind), and the terminal client under libs/ptc-cli/. The architecture diagram in the README shows PostgreSQL with a dual pool: one pool for app data (users, workspaces, threads, turns, BYOK keys, automations) and one for the LangGraph checkpointer holding agent state and checkpoints. Redis handles three jobs: an SSE event buffer sized at 150K events for reconnect replay, an API cache for market data using stale-while-revalidate, and steering. That means a working deployment needs PostgreSQL and Redis reachable before the API is useful, and the checkpointer pool is not optional if you want resumable agent state. The README also lists a self-hosted desktop build, tagged desktop-oss-v0.2.3, alongside the regular desktop-v0.2.3 release, which suggests two packaging paths rather than one. The README does not give a single copy-paste install command in the material available here, so treat the directory layout as the map and expect to read docs/api/README.md for the HTTP surface.

Skills, subagents, and the parts that assume long-running sessions

Skills are pre-built workflows for DCF models, initiating coverage reports, earnings analysis, morning notes, and document generation, activatable by slash command or auto-detection. The agent swarm feature runs parallel async subagents with isolated context windows, preloaded toolsets and skills, mid-execution steering, checkpoint-based resume, and live progress monitoring. Live steering lets you send follow-up messages while a subagent is still working. Underneath sits a middleware stack handling skill loading, plan mode, multimodal input, auto-compaction, and context management. The honest reading of this list is that LangAlpha is built for sessions measured in minutes to hours, not seconds. Auto-compaction and checkpoint resume exist because context and process lifetime are the binding constraints. If your use case finishes inside one prompt, none of this machinery pays for itself, and the operational surface (PostgreSQL, Redis, sandboxes) is pure overhead.

Where it is the wrong tool, and what the README does not settle

The clearest mismatch is latency-sensitive or single-fact queries. If you want the current price of an index, the architecture is disproportionate: an API router, a chat handler, a background task manager, a checkpointer, and an SSE buffer stand between you and a number. A second limitation is that the project is young in release terms. The releases listed are v2026.09.07 and desktop-v0.2.3, both dated within a day of each other, and the desktop line is still at 0.2.x. That is a signal about API stability, not quality, but it means you should expect churn in config keys and endpoints. Third, the README's security section claims encryption at rest via pgcrypto, credential leak detection and redaction, sandboxed execution, and per-workspace secret storage. Those are claims about the code, not guarantees about your deployment; sandbox isolation depends on the runtime you provide, and the README does not enumerate which runtimes are supported in the material available. Finally, the automations feature includes price-triggered tasks that fire on a real-time price condition. Anything that can place or size a trade based on an agent's output deserves a human approval step, and the README only mentions human-in-the-loop approval for the secretary agent, not for every automation path.

The alternative: a general coding agent with your own data scripts

The obvious comparison is a general coding agent harness pointed at a directory of your own Python scripts and data files. That approach gives you the same persistent-filesystem pattern, and the README effectively concedes the lineage by citing Claude Code and OpenCode as the inspiration. The difference is what comes bundled. LangAlpha ships the finance-specific layer: a multi-tier provider hierarchy with native tools for quick lookups and MCP servers for bulk processing and charting, skills for DCF and earnings workflows, a TradingView charting workbench with agent-drawn annotations, a per-turn source-provenance panel, and channel integrations for Slack, Discord, Feishu, and Telegram. A general agent plus your own scripts means you build the data plumbing, the provenance tracking, and the scheduling yourself, and you own the maintenance. LangAlpha means you inherit its opinions about how research is structured, including the workspace layout and the agent.md convention, and you accept its release cadence. Neither is strictly better; the deciding question is whether the finance-specific scaffolding matches how your team already works.

Licence, upgrade cost, and what to check before you commit

LangAlpha is Apache-2.0. That permits commercial use and modification, and it includes a patent grant, but it also means you must preserve the licence and attribution notices in distributed copies. This is not legal advice; if you plan to redistribute a modified version or embed it in a product, have counsel read the NOTICE handling and the plugin directory at plugins/ to see whether third-party integrations carry separate terms. On upgrade cost, the dual-pool PostgreSQL design is the item to watch. Schema changes to app data and to the LangGraph checkpointer move independently, and a release that bumps the checkpointer format can invalidate in-flight agent state. Pin your PostgreSQL image and take a dump before upgrading across a release boundary. The Redis event buffer is transient, so losing it costs you reconnect replay for active sessions, not durable data. For evaluation, the cheapest path is the self-hosted desktop build tagged desktop-oss-v0.2.3, which avoids standing up the full server stack before you know whether the workspace model fits your workflow.

Editorial conclusion

Adopt LangAlpha if your research is iterative and you want the agent to keep files, threads, and a notes file between sessions rather than re-deriving context from scratch each time. Do not adopt it if you need a single-turn market data lookup, or if you cannot run PostgreSQL and Redis alongside the FastAPI backend, since the architecture assumes both. Before committing, verify three things in your own environment: that the finance MCP servers you rely on load through progressive tool discovery without blowing the context budget, that sandbox execution works under your container runtime, and that the Apache-2.0 licence and the repository's plugin directory cover the integrations you plan to ship.

Official sources

1. ginlix-ai/LangAlpha on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases