The roadmap describes what we propose to build. This document explains why we build it the way we do — the reasoning behind architectural decisions, the landscape of available tools, the security model that protects the fund, and why this is careful, phased work rather than a quick installation.
AI-assisted trading and investment research is no longer experimental. As of April 2026, three categories of tools are available to any fund manager:
Anthropic released Claude Routines on April 14, 2026. A routine is a saved Claude session — a prompt, connected repositories, and MCP connectors — that runs autonomously on cloud infrastructure. Routines can trigger on a schedule (hourly, daily, weekly), via API call, or in response to GitHub events.
This is a real product with real capabilities. A fund could set up a Routine today that runs every morning and summarizes overnight market news, triggers when a TradingView alert fires and logs the signal, or scans merged code changes weekly and flags drift.
What Routines cannot do: coordinate multiple agents with different roles. A Routine is a single session — one agent, one prompt, one execution. No persistent memory across runs. No awareness of other Routines. No risk enforcement across sessions, no portfolio-level awareness, no team dashboard.
A Routine is a capable individual contributor. What we are building is a department.
The open-source community has produced substantial trading skill libraries for Claude. The most mature repository offers 40+ pre-built investment skills:
| Category | Skills | Examples |
|---|---|---|
| Market analysis | 11 | Sector rotation, breadth analysis, macro regime detection |
| Stock screening | 8 | CANSLIM, VCP patterns, dividend growth, pair trades |
| Strategy & risk | 12 | Backtesting, scenario analysis, bubble detection, position sizing |
| Research pipeline | 6 | Edge candidate generation, hypothesis testing, signal aggregation |
| Self-improvement | 3 | Automated skill scoring, daily improvement loops, idea mining |
These skills are well-engineered. Most require only a free-tier financial data API (250 requests/day).
What skill libraries cannot do: reason about your fund. They are generic — designed for individual retail investors running one analysis at a time. No concept of Viska Crypto vs Viska Macro, no awareness of your portfolio, no connection to your broker research corpus, no compliance awareness for sub-threshold AIFM limits. They produce analysis for “a stock.” We produce intelligence for your fund.
Fully autonomous trading frameworks exist. One major open-source platform supports stock, crypto, and derivatives execution across multiple brokers with a three-layer pipeline: signal generation, LLM-based decision making, and automated order execution.
We do not build this. Here is why:
This is not a hypothetical risk. This is what happens when trading infrastructure is assembled from unvetted components without security architecture.
We build a coordinated intelligence department where every component has a defined role, enforced boundaries, and auditable behaviour.
| Stock Tool | Gáldr Build |
|---|---|
| One session with a prompt | 4–16 agents with distinct roles and defined scope boundaries |
| Each session starts fresh | Persistent knowledge graph — the system remembers what it learned |
| No awareness of other sessions | Agents coordinate: the analyst's thesis feeds the risk manager's evaluation feeds the operator's decision |
| Generic analysis | Tailored to Viska's two funds, portfolio composition, and operational cadence |
| Runs when triggered | Structured sessions: pre-market, midday, end-of-session, plus alert-driven |
Before the team sits down in the morning, the system has already been working for hours:
Nothing in this cadence is possible with a single Routine or a library of generic skills. It requires agents that know their roles, remember their context, and operate within enforced boundaries.
We are not building everything from scratch. The ecosystem has strong components — we evaluate them rigorously and adopt what passes our six-criteria framework:
| Component | Source | Why We Adopt It |
|---|---|---|
| FRED MCP | Federal Reserve | 800,000+ macro data series. Official source. No ToS concerns. |
| QuantOracle | MCP ecosystem | 63 deterministic quantitative tools. Production-grade. |
| Alpaca | Official API | Paper + live trading. 70+ tools. Official, maintained, ToS-compliant. |
| Ollama | Local inference | Gemma 4 on own hardware. No API costs for synthesis tasks. |
| TradingView Webhooks | Official | Alert-driven signal intake. Supported, no scraping. |
| QuantStats | Open source | Performance tearsheets for weekly reporting. |
| Select backtesting tools | Open source (evaluated) | Walk-forward testing, multi-timeframe screening. 8 of 30 available tools — the rest filtered out. |
What we do not adopt: browser automation tools (ToS violation, fragile), unvetted community packages (supply chain risk), autonomous execution frameworks (judgment error risk), full tool suites without filtering (token waste).
| Component | Why It Must Be Custom |
|---|---|
| Agent coordination layer | No stock tool coordinates 4–16 agents with role boundaries. This is the orchestration that makes the same AI model perform 6x better (Stanford/Tsinghua, March 2026). |
| Risk enforcement | Schema-enforced. Unsigned trades cannot proceed. A hard gate in the architecture, not a suggestion in a prompt. |
| Viska Portal | Every page designed for the fund's workflows. Not a generic dashboard. |
| Knowledge graph | Persistent, queryable memory across all sessions. The system improves because it remembers. |
| Fund-specific context | Viska Crypto and Viska Macro have different instruments, risk profiles, and reporting needs. Generic tools cannot distinguish them. |
| Compliance monitoring | Sub-threshold AIFM under Act 45/2020 has specific limits. No open-source tool monitors Icelandic regulatory thresholds. |
| Credential isolation | API keys never enter the AI reasoning layer. Runtime injection via sandbox. The AI uses credentials but cannot see, extract, or leak them. |
| LP communications pipeline | Formatted to your standards, grounded in your performance data, written in your voice. |
Security is not a feature we add at the end. It is the foundation on which everything else is built.
| Threat | Real-World Example | Our Mitigation |
|---|---|---|
| Supply chain attack | February 2026: 1,184 malicious skills distributed wallet-stealing malware. 14,285 downloads before detection. | Every dependency evaluated against six criteria. Package versions pinned to specific commits. No community marketplace — skills authored and reviewed internally. |
| Credential exposure | 21,000 AI agent instances found publicly accessible with unprotected API keys, wallet access, and chat logs. | Credential isolation: keys exist only in a runtime sandbox. The AI layer never sees credential values. |
| Scope violation | Generic assistants prompted to exceed intended function — a research agent asked to execute trades. | Mechanical scope enforcement. Each agent has a defined domain. The research agent literally cannot call the trading API. |
| Autonomous execution risk | Autonomous trading bots executing without human review. LLM interpretation introduces judgment errors that compound. | Human approval is permanent and schema-enforced. Every order requires explicit approval. This is a design principle, not a Phase 1 safeguard. |
| Data poisoning | AI systems ingesting unvalidated data — fake news, manipulated sentiment, spoofed market data. | Sourced data only. Broker research from known providers. Central bank data from official feeds. Market data from regulated broker. |
| Dashboard credential leak | Web dashboards embedding API keys in frontend JavaScript, exposing them via browser developer tools. | Read-only frontend. A server-side proxy handles all authenticated requests. The browser sees rendered data only. |
This is worth explaining because it is the question most CIOs ask: “How can AI trade on our behalf without seeing our API keys?”
The agent says “place this order.” The sandbox injects the API key into the outbound request. The agent never sees the key value. If the agent's conversation were leaked, exfiltrated, or logged — there are no credentials in it.
Each phase builds on the previous. Skipping phases creates an intelligence system that has no foundation to stand on.
What we build: The research corpus. Every subsequent agent depends on this — the trading analyst needs macro context, the risk manager needs economic data, the LP communications need sourced intelligence.
Why it takes a month: Broker research corpus must be ingested, indexed, and made queryable (400,000+ words). Central bank pipelines need validation against official sources. FRED integration needs configuration for Viska's relevant series. Daily intelligence brief needs calibration with the team.
End of Month 1: A queryable research corpus. A daily intelligence brief delivered every morning. Central bank data on autopilot. Macro data accessible from any workspace.
What we build: Three autonomous surveillance agents running 24/7 — crypto, macro sentiment, geopolitical risk. Alert pipeline with L1/L2/L3 hierarchy.
Why it depends on Month 1: Surveillance agents need the research corpus as context. “BTC down 5%” is noise. “BTC down 5% ahead of FOMC meeting with hawkish expectations” is intelligence. The alert hierarchy needs Month 1's baseline of “normal.”
End of Month 2: Three agents watching markets around the clock. Anomaly detection. Sentiment scoring. Geopolitical risk monitoring. Prioritised alert pipeline.
What we build: Four-agent trading operation. Paper trading on Alpaca. Risk enforcement. 7-page dashboard.
Why it depends on Months 1–2: The Trading Operator synthesises surveillance output (Month 2) and research intelligence (Month 1). The Technical Analyst uses FRED data and QuantOracle for quantitative confirmation. The dashboard displays data that automation pipelines produce — building it first would show empty pages.
Paper trading begins in Month 3 and runs through Month 5. This is a hard gate: no live capital until the record demonstrates:
| Metric | Threshold |
|---|---|
| Minimum paper trading days | 90 |
| Risk framework compliance | 100% (no bypassed gates) |
| System uptime | >95% during market hours |
| Order accuracy | 100% (every order matches approved parameters) |
| Decision audit trail | Complete (every trade traceable from thesis to execution) |
During paper trading, the system operates exactly as it would with live capital. The team reviews trades, calibrates risk parameters, and identifies failure modes — all without financial exposure.
End of Month 3: An operational trading system in paper mode. A 7-page dashboard. Slack integration. The system is running — it just isn't touching real capital yet.
What we build: Automated LP letter generation, thought leadership content (2–3 pieces per week), meeting intelligence for fundraising.
Why it depends on Months 1–3: LP letters require performance data from the trading system and macro context from the research corpus. Thought leadership needs the team's investment thesis as input — this emerges from trading sessions, not from a prompt.
End of Month 4: First drafts of LP letters. 2–3 thought leadership pieces per week. Pre-meeting research briefs and post-meeting follow-up drafts.
What we build: Overnight scenario analysis lab. Proprietary signal generator on Viska infrastructure.
Why it depends on Months 1–4: Scenario modelling requires 4 months of operational data to calibrate. Signal generation requires the backtesting framework and macro data. Signals are backtested, walk-forward tested, and validated before deployment.
End of Month 5: Overnight scenario reports with probability assessments and portfolio impact projections. Proprietary signals from Viska's own framework.
What we build: Distribution partner surveillance, complete documentation, team training, and full ownership transfer.
| Deliverable | Detail |
|---|---|
| All source code | On Viska's GitHub organisation. Every repository, every commit, full history. |
| Knowledge base | On Viska's database instance. All ingested research, decision logs, agent memory. |
| AI subscription | On mimir@viskasjodir.is. No dependency on Gáldr accounts. |
| Dashboard & portal | On Viska's domain. DNS transfer, SSL certificates, hosting configuration. |
| Automation pipelines | On Viska's automation instance. Self-hosted, auditable, full ownership. |
| Documentation | Architecture guide, operational runbook, agent configuration reference, troubleshooting guide. |
| Team training | Daily operations, agent management, pipeline monitoring, portal administration, system expansion. |
| Support period | Post-handoff support window during the team's transition to independent operation. |
After Month 6, Viska operates the system independently. Nothing is locked in — no proprietary platform, no SaaS dependency, no vendor that must remain involved. The intelligence department belongs to the fund.
Why does orchestration matter more than the AI model itself?
Stanford and Tsinghua research (March 2026) demonstrated that the same AI model delivers a 6x performance difference depending on how it is orchestrated. The model is a commodity — the same Claude, GPT, or Gemini is available to every fund. What determines performance is the harness: how agents are structured, what context they receive, how they coordinate, what boundaries they operate within.
One company removed 80% of its available tools and saw better results. An agent with 43 tools spends most of its reasoning capacity deciding which tool to use, not using it well. Our agents have focused, curated toolsets:
| Agent | Tools | Why These |
|---|---|---|
| Trading Operator | Alpaca, FRED, Ollama | Market data, macro context, local synthesis. Does NOT need screening tools — that's the analyst's job. |
| Technical Analyst | Alpaca, FRED, QuantOracle, SQLite | Data access and quantitative tools. Does NOT need order execution — different agent, different permissions. |
| Risk Manager | Alpaca, QuantOracle, SQLite | Portfolio awareness and quantitative validation. Does NOT need research corpus — risk uses numbers, not narratives. |
| Execution Agent | Alpaca, SQLite | Order submission and logging. Narrowest toolset because most consequential action: moving capital. |
AI models are replaced every few months. Claude 3 → 3.5 → 4 → 4.5 — each generation more capable. Any investment in a specific model's quirks depreciates rapidly.
The orchestration layer — how agents are structured, what data flows between them, how risk is enforced — transfers across model generations. When a better model ships, we swap it in and the entire system improves. The harness compounds; the model depreciates.
Speed without governance produces faster mistakes. Every component has governance before optimisation:
The February 2026 supply-chain attack affected a platform that optimised for capability before governance. 21,000 instances with no authentication. 1,184 malicious skills. When the attack hit, there was no audit trail to determine which accounts were compromised, no scope boundaries to limit damage, no credential isolation to protect wallets.
We build governance into the foundation so that when — not if — something unexpected happens, the blast radius is contained and the audit trail is complete.
What the team can do at each milestone. Once introduced, capabilities persist through all subsequent months.
| Capability | M1 | M2 | M3 | M4 | M5 | M6 |
|---|---|---|---|---|---|---|
| Query research corpus | + | · | · | · | · | · |
| Daily intelligence brief | + | · | · | · | · | · |
| Central bank data pipeline | + | · | · | · | · | · |
| Workspace access | + | · | · | · | · | · |
| 24/7 crypto surveillance | + | · | · | · | · | |
| Macro sentiment monitoring | + | · | · | · | · | |
| Geopolitical risk alerts | + | · | · | · | · | |
| NLP sentiment scoring | + | · | · | · | · | |
| Paper trading (4 agents) | + | · | · | · | ||
| Risk enforcement (8 rules) | + | · | · | · | ||
| 7-page trading dashboard | + | · | · | · | ||
| TradingView signal intake | + | · | · | · | ||
| 63 quantitative analysis tools | + | · | · | · | ||
| Automated LP letter drafts | + | · | · | |||
| Thought leadership (2–3/wk) | + | · | · | |||
| Meeting intelligence | + | · | · | |||
| Overnight scenario modelling | + | · | ||||
| Proprietary signal generation | + | · | ||||
| Distribution partner surveillance | + | |||||
| Full codebase ownership | + | |||||
| Team training & documentation | + |
+ = introduced that month. · = persists from previous month.