Beyond market data: what an AI investing agent needs to know about you

An AI investing agent can read a company’s filings, debate its prospects and produce a persuasive report. That still leaves a personal question unanswered: how does this idea fit the investor whose money would be affected?

The answer depends on facts a market-data service cannot supply. The investor may already hold the company through several funds. They may have a concentration limit, a liquidity commitment, an exclusion or a reason for an earlier decision that remains relevant today. A fresh conversation can omit all of these.

As research frameworks, portfolio services and brokers expose more tools to AI assistants, the useful question becomes which service carries which part of the investor’s context? This article examines that division of responsibility through public documentation. Investboard is the central example of a service for investor-authored rules and decision history; the surrounding projects show why that service needs a wider stack.

Four questions, four responsibilities

“Research this company” and “check whether this change fits my plan” require different inputs. The first needs evidence about a business. The second needs evidence about the investor. Preparing an order introduces a further requirement: permission to act.

1. 01Research

   What does the evidence say about this investment?

   TradingAgents · AI Hedge Fund

2. 02Portfolio

   What does the investor already own?

   Parqet · Ghostfolio

3. 03Mandate & memory

   Which rules and earlier decisions govern this proposal?

   Investboard · TradeMemory

4. 04Execution

   What may reach the broker, and who must approve it?

   Alpaca MCP · Scalable Capital

This separation is an architectural choice. It lets the investor change a research framework without asking that framework to become the permanent home of their strategy. It also makes missing information visible: an assistant with a market-data connection should not imply that it has inspected the investor’s entire portfolio.

What the projects actually expose

The comparison below describes documented surfaces, rather than assigning scores. “Not established” means the cited documentation does not establish the capability for this review. It is not a claim that the entire product lacks it.

Project / role	Context supplied	Action boundary
TradingAgentsResearch framework	Specialist analysts, research debate and a decision workflow. Upstream also documents portfolio-aware runs.	Research-purpose framework. A persistent investor mandate service is not established by its README.
AI Hedge FundResearch / education	Investor-persona analysis, risk management and portfolio-management agents.	The README describes an educational system and says it does not make actual trades.
ParqetPortfolio context	Holdings, valuation, allocation, activities and performance through a remote MCP server.	Separate read and write scopes. Writes create portfolio records and activities; they are not broker orders.
GhostfolioPortfolio context	An experimental MCP server for portfolio reads and importing activities.	Access permissions distinguish restricted views, monetary values and activity imports.
InvestboardInvestor mandate / decision history	Mandate, saved instructions, plan status, checks, instrument theses and journal entries.	The assistant connection cannot place orders or change the mandate. Thesis and journal access require Premium.
TradeMemoryAgent memory / policy proxy	Recorded trades, outcome-weighted recall and a decision audit trail.	Its preview Alpaca proxy documents policy checks on order tools before forwarding them.
Alpaca MCPBroker tools	Account, positions, market data and order-management tools.	Paper trading is the default. Server-side toolsets restrict the tools exposed to the assistant.
Scalable CapitalBroker access / approval	Holdings, allocation, cash, market data, watchlists and order preparation.	Customisable access levels and investor approval before order execution.

TradingAgents

Research framework

Context supplied

Specialist analysts, research debate and a decision workflow. Upstream also documents portfolio-aware runs.

Action boundary

Research-purpose framework. A persistent investor mandate service is not established by its README.

AI Hedge Fund

Research / education

Context supplied

Investor-persona analysis, risk management and portfolio-management agents.

Action boundary

The README describes an educational system and says it does not make actual trades.

Parqet

Portfolio context

Context supplied

Holdings, valuation, allocation, activities and performance through a remote MCP server.

Action boundary

Separate read and write scopes. Writes create portfolio records and activities; they are not broker orders.

Ghostfolio

Portfolio context

Context supplied

An experimental MCP server for portfolio reads and importing activities.

Action boundary

Access permissions distinguish restricted views, monetary values and activity imports.

Investboard

Investor mandate / decision history

Context supplied

Mandate, saved instructions, plan status, checks, instrument theses and journal entries.

Action boundary

The assistant connection cannot place orders or change the mandate. Thesis and journal access require Premium.

TradeMemory

Agent memory / policy proxy

Context supplied

Recorded trades, outcome-weighted recall and a decision audit trail.

Action boundary

Its preview Alpaca proxy documents policy checks on order tools before forwarding them.

Alpaca MCP

Broker tools

Context supplied

Account, positions, market data and order-management tools.

Action boundary

Paper trading is the default. Server-side toolsets restrict the tools exposed to the assistant.

Scalable Capital

Broker access / approval

Context supplied

Holdings, allocation, cash, market data, watchlists and order preparation.

Action boundary

Customisable access levels and investor approval before order execution.

TradingAgents organises analysis through specialist roles and debate. AI Hedge Fund uses a different set of analyst personas. These frameworks help structure a research process. Their role names do not, by themselves, establish how an individual investor’s enduring rules are stored or enforced. See the TradingAgents README and AI Hedge Fund README.

Portfolio services answer another question. Parqet’s MCP documentation describes both reading portfolio information and creating certain records with a separate write permission. Ghostfolio’s experimental MCP surface distinguishes access with and without monetary values. In each case, the permission boundary deserves as much attention as the list of available data.

For Investboard, the documented assistant tools include get_policy, get_status, check_action and record_decision. Additional tools expose check history, a saved instrument thesis and the journal. This gives an assistant a place to retrieve the investor’s prior instructions and preserve the decision they state after a check. Investboard help.

Holdings describe the present. A mandate records intent.

A portfolio snapshot describes a state: positions, weights, cash and transactions. It cannot fully explain why that state exists or which changes the investor has agreed to consider.

A mandate supplies that missing intent. It can record the purpose of the portfolio, acceptable allocation ranges, exclusions, liquidity needs and the procedure for making exceptions. A thesis records why an instrument belongs in the portfolio and what evidence would call that reasoning into question. Decision history preserves how a proposed change was considered.

These records should remain distinct. A concentrated holding might be an intentional exception or an unresolved violation. A prior decision might still govern the next review, or it might have been superseded. An agent should be able to identify the difference instead of reconstructing an investment policy from holdings alone.

A useful investor record explains the rule, the decision and the version that applied at the time.

Investboard’s public AI page describes a portable investing.md export alongside its assistant connection. The export is a readable file the investor chooses to share; it does not establish a live connection. The connected assistant can check an intended change, while order placement and mandate changes remain outside that connection. AI at Investboard.

That distinction matters for portability. A file is easy to carry into another workflow, but it can become stale. A live service can return current records, but depends on access, availability and integration. Neither mechanism automatically proves that every research tool consulted the current mandate.

A check is different from an execution gate

An assistant might retrieve a rule, recognise a conflict and record the result. Those steps create useful evidence. They do not guarantee that a separate broker tool will refuse the proposed order.

An execution gate needs control over the action path. If the assistant can call the broker directly after receiving an unfavourable check, the check is advisory. If every order must pass through a service that validates the same terms before forwarding it, that service can enforce a boundary.

TradeMemory’s preview proxy documents the second arrangement for Alpaca: it sits between the agent and the broker’s MCP server and evaluates order-placement tools against user-owned policy. Its README describes refusals for unsupported or unevaluable orders and reports a limited paper-account exercise. These are maintainer-reported capabilities, not tests conducted for this article.

Alpaca’s MCP server documents server-side tool filtering and paper trading by default. Those controls govern available capabilities and trading environment. They do not, on their own, establish an investor-specific mandate check. Alpaca documentation.

Scalable Capital documents investor approval before execution and configurable agent access. Approval remains an important decision point. Whether the proposal fits a separately stored mandate depends on the surrounding workflow.

The handoff is where the design matters

Consider a fictional investor asking an assistant to investigate adding a company they already own indirectly through funds. Their mandate restricts issuer concentration, and an earlier journal entry explains why they paused a similar proposal.

The research service can examine the company. A portfolio service can supply positions and available exposure information. The mandate service can return the relevant rule and the earlier decision. A broker connection can prepare an order only within the permissions it has been granted.

The workflow is incomplete until those inputs refer to the same proposal. A rule check on a small addition does not cover a larger order prepared later. A check against an old portfolio snapshot may no longer describe the current exposure. An instrument identifier also has to mean the same thing across the services.

For a reviewable handoff, the record should therefore preserve:

• The inputs: instrument identity, portfolio snapshot date and mandate version.
• The proposal: the action and terms that were actually checked.
• The finding: which rule was evaluated, the result and any missing information.
• The decision: what the investor chose, including any stated exception.
• The action record: if execution occurs elsewhere, a separate broker confirmation or order identifier.

This is a proposed record structure, not a claim that the projects in the comparison share one schema. Its purpose is to make the seams inspectable. A polished explanation is less useful if the reader cannot tell which portfolio, which rules and which proposed action it describes.

What should survive a change of assistant?

The durable asset is the investor’s own record: purpose, rules, theses and decisions. Model conversations are useful working material, but should not be the only place that record exists.

When evaluating a setup, ask whether a new assistant can retrieve the current policy, distinguish a superseded decision, identify the date of the portfolio context and acknowledge information it cannot access. Then ask where the investor can review or export those records without reconstructing them from chat history.

This is where Investboard has a clear documented role. Its mandate and journal tools offer context that complements research frameworks and portfolio connections. TradeMemory demonstrates a neighbouring approach built around agent trade memory and a broker policy proxy. The architectural opportunity is to make those responsibilities explicit and keep the investor’s rules legible across tools.

Our follow-up, From TradingAgents analysis to a reviewable investment decision, examines the open-source Investboard connector and publishes fictional scenarios for that comparison. It includes executed offline connector checks and a model-comparison protocol; the model runs and authenticated server checks remain pending.

Sources and scope

This article draws on InvestingStack’s October 2026 research survey and a fresh review of the primary sources below. It compares public documentation; it does not report authenticated tool calls, integration tests or trading results. Product statements describe documented behavior, while the proposed architecture and handoff record are editorial analysis. AI assisted drafting and source review; David Bartas is the named author and responsible editor.

1. TradingAgents — framework README: analyst roles, workflow and research-purpose positioning.
2. AI Hedge Fund — project README: educational purpose and analyst architecture.
3. Parqet — portfolio context through MCP: data access, record creation and scopes.
4. Ghostfolio — experimental MCP server: portfolio access and import permissions.
5. Investboard — assistant help and AI at Investboard: mandate tools, decision records, export and connection boundaries.
6. TradeMemory — memory and preview broker proxy: recall, audit records and documented enforcement path.
7. Alpaca — official MCP server: broker capabilities, tool filtering and paper default.
8. Scalable Capital — Agentic Investing: access levels and order approval.

---