ALTA: a local multi-agent research desk where every trade thesis must survive review

The problem ALTA is built around: a thesis that has to survive disagreement

Most retail-facing agent projects collapse into a single loop: fetch prices, ask a model, print a ticker. ALTA takes the opposite position. Its README states the idea plainly: "a thesis must survive disagreement, costs and time before it deserves capital." That sentence is the whole design brief, and it explains why the project ships four specialist Scouts, independent reviewers, and a strategy desk rather than one prompt.

The audience follows from that. For a researcher, the product is the disagreement itself: which source was cited, which reviewer objected, what the verdict was. For a developer, the split between agent judgment, scheduling, data contracts and execution is the part worth reading. For an operator, the console is a single place to see what ran, what is still uncertain and what has permission to act.

It is not a chatbot that recommends a ticker, and the README says so directly. That framing is also a warning: if you want a system that hands you a position, ALTA is deliberately worse at that than a spreadsheet.

Scouts, reviewers and a strategy desk: how the research trail is produced

The architecture visible in the README is a pipeline with handoffs, not a swarm. Four specialist Scouts pursue leads: changes, anomalies and unanswered questions. Their output is not a recommendation but a record. Independent reviewers then challenge the evidence, and a strategy desk compares instruments and costs, asking which instrument best expresses the opportunity.

The stated principle is "Start with the opportunity. Choose the instrument that best expresses it." That ordering matters. Instrument selection happens after the thesis is tested, not before, which is the reverse of how most ticker-driven tools work.

Every handoff leaves what the README calls an inspectable record, and the console screenshots are described as showing who investigated, which model ran and what it produced. Persistent records connect monitoring, exits, forward outcomes and later research. The repository layout supports this: alta-runtime/, alta-src/, alta-dashboard/ and a vendor/ directory containing a pinned OpenAI Codex harness, with package.json exposing a write-hooks-schema script that runs cargo against vendor/openai-codex/codex-rs/Cargo.toml.

One design constraint is worth flagging as a trade-off. The README notes that Agent artifacts retain their authored language. Model output is not normalized into English, so a multilingual agent set produces a multilingual audit trail. That preserves fidelity and makes review harder for a single-language operator.

Running ALTA locally: requirements and the first console session

The README lists macOS or Linux, Node.js 22+ with npm, Python 3.12, uv, Docker or OrbStack and sufficient disk space. Initial setup needs internet, and building the pinned custom harness also needs its Rust toolchain. Windows is not mentioned.

The documented entry point is a single npm script. The README gives this example:

git clone https://github.com/kyky2347/ALTA.git
cd ALTA
npm run dashboard

According to the README, that command installs locked frontend dependencies when needed, builds the console and opens an authenticated loopback page. The console then walks through five steps: connect research and data credentials, assign models under Agents then Agent models, start managed research services, inspect a Scout record, and stop.

Model assignment has a hard rule: opposing review roles must differ. The README does not explain what happens if you try to assign the same model to both sides of a review, so treat that as unverified.

Configuration is external. The .env.example file states that credentials should be injected through the environment or kept as optional RTF files under ~/.config/alta/credentials/llm/, and that they must never be stored inside the project tree. It also defines ALTA_CREDENTIALS_DIR to point at a different absolute external root. Provider keys listed there are OPENAI_API_KEY, DEEPSEEK_API_KEY, XAI_API_KEY and MOONSHOT_API_KEY.

export ALTA_CREDENTIALS_DIR=/absolute/path/outside/the/repo
export OPENAI_API_KEY=...
export ALTA_ENVIRONMENT=replay
export ALTA_AUTONOMOUS_ENABLED=0

The same file sets ALTA_SERVICE_HOST to 127.0.0.1 and ALTA_SERVICE_PORT to 8876, and notes that PostgreSQL and Redis passwords are generated into ignored mode-0600 secret files rather than placed in the environment file. First-run overrides for ports and memory include ALTA_POSTGRES_PORT=55432 and ALTA_REDIS_PORT=56379.

Two execution modes, and why Shadow is where a first run belongs

ALTA separates research from action with a boundary the README calls explicit. Execution has two modes: Shadow and Broker API. Shadow is internal simulation. Broker orders require a verified, explicitly selected account and separate authorization.

Saving a key never grants trading permission. The README states that model access, data entitlements and broker account permissions are separate requirements, and that six connectors exist while live-account acceptance is not established. That last clause is the most important sentence in the repository for anyone evaluating it seriously: the broker path is implemented but not validated against live accounts.

The console screenshots carry the same caveat. The execution setup capture is described as showing an unauthorized configuration, not a connected broker.

There is also an operational detail that trips people up. The stop step drains research and stops the managed database and cache, and the README notes this does not liquidate broker holdings. Stopping ALTA is not a kill switch for positions.

A quieter point from the same section: a healthy service may be waiting for its next cycle, and a Wait decision can be the correct result. If you expect constant activity as a sign of life, you will misread the system.

Where ALTA is the wrong tool

The README is unusually direct about scope: experimental research software, not investment advice, not a production OMS and not evidence of profitable Alpha. That covers three separate failure modes.

First, it is not an order management system. There is no claim of production-grade order lifecycle handling, and the stop step explicitly leaves broker holdings untouched.

Second, the broker boundary is unproven against live accounts. Six connectors exist, but the README states live-account acceptance is not established. Anyone routing real capital through it is ahead of the documentation.

Third, the local stack is heavy for what a casual user might want. Node.js 22+, Python 3.12 managed under .alta by uv, Docker or OrbStack, a Rust toolchain for the pinned harness, and a PostgreSQL plus Redis pair with configurable memory and CPU limits. If you only want a model to summarize filings, this is a large amount of machinery for that job.

The research scope is also narrower than the topic list suggests. The repository topics mention quantitative finance, but the README frames the output as a research trail and an explicit decision, not a backtested strategy library. There is no documented performance claim, and the README says the project is not evidence of profitable Alpha.

How ALTA differs from a backtesting framework or an agent framework

The nearest comparison is a backtesting framework such as vectorbt or Backtrader. The difference is what each treats as the unit of work. A backtester takes a strategy as input and produces a return series; the correctness question is whether the simulation matches reality. ALTA takes an opportunity as input and produces a documented decision plus forward outcomes; the question is whether the thesis survived review.

ALTA does have a simulation mode, and .env.example sets ALTA_ENVIRONMENT=replay by default, but the README does not describe replay as a historical backtest engine and does not document slippage or fill modelling. Treat it as a simulation boundary, not a research backtester.

The other comparison is a general agent framework such as LangGraph or CrewAI. Those give you orchestration primitives and leave the domain to you. ALTA ships the domain: four Scouts, reviewer roles with a separation rule, a strategy desk, a console and a broker boundary. The cost is that the orchestration is opinionated. If your research process does not look like investigation, challenge, instrument selection, you will be fighting the shape of the system rather than using it.

Maintenance, upgrade cost and the Apache-2.0 licence

The last push to the default branch was on 2026-09-13, four days before this writing, and the repository is not archived. The most recent release listed is v0.25.0, dated 2026-08-27 and titled Initial Public Research Release. A project whose first public release is numbered 0.25.0 has a long private history and a young public one; expect the public documentation to lag the code.

Upgrade cost is dominated by the pinned harness. The vendor/ directory holds a custom OpenAI Codex build, and package.json includes a write-hooks-schema script that runs cargo against vendor/openai-codex/codex-rs/Cargo.toml. Rebuilding that requires the Rust toolchain, so upgrades are not a pure dependency bump. The package manager is pinned too: packageManager is pnpm@10.33.0 with a recorded integrity hash, and engines requires Node >=22 and pnpm >=10.33.0.

Apache-2.0 is permissive: it allows commercial use, modification and redistribution, and it includes an explicit patent grant. It also requires that you preserve copyright and attribution notices and state significant changes. The repository ships NOTICE and ATTRIBUTION.md files, which is consistent with that. None of this is legal advice; if you plan to redistribute a modified ALTA, read LICENSE and NOTICE yourself.

One licence-adjacent caution: the README and the badge point to docs/research-scope.md for the research-only scope. That is a project statement of intent, not a licence restriction, and the two should not be confused.

Editorial conclusion

ALTA suits researchers and developers who want agent disagreement, source quality and execution authority to be inspectable rather than asserted, and who can run a local Node 22 plus Python 3.12 stack. It is the wrong tool for anyone wanting a working order management system or a signal service: the README states live-account acceptance is not established, and Shadow is where a first run belongs. Before trusting anything, verify the reviewer separation rule in Agents, Agent models, read docs/audits/broker-routing-2026-09-13.md, and confirm which credentials the console actually stored under ALTA_CREDENTIALS_DIR.

Frequently asked questions

Official sources

1. Issues
2. kyky2347/ALTA on GitHub
3. License: Apache-2.0
4. README
5. Releases