Advisor agents can only see the vendors that agreed to share. Betterment says an MCP release is coming.

On September 24, Betterment Advisor Solutions launched an AI document reader inside its client onboarding flow. An advisor uploads a client's outside brokerage statement, usually a PDF, and the tool fills in the transfer request. Betterment says statements are not used to train models. The forward-looking part came from CEO Sarah Levy: Betterment plans to make document-reader data available to agentic workflows in its advisor application before the end of the year, and an MCP (Model Context Protocol) release is expected to follow (WealthManagement.com). The announcement gives no details on the MCP release: no scope, no list of eligible clients, no terms.

On its own, that is a modest product note. Read alongside Kitces' October AdvisorTech column, it is one more piece of a map that advisor agents are working from without seeing it.

The map is drawn by consent

Ben Henry-Moreland and Michael Kitces counted what Anthropic's Claude for Financial Advisors can reach at launch (Kitces, October 5). There are 11 connectors: Addepar, BlackRock, Black Diamond, Envestnet Tamarac, iCapital, MoneyGuidePro, Orion, Vanguard, Wealthbox, Wealth.com and Zocks. Schwab data is promised but not yet live. The list of what is not connected is longer. On the planning and marketing side it includes eMoney, RightCapital, Holistiplan, FMG Suite, AdvisorStream, Snappy Kraken, Advyzon, Nitrogen and Jump. On the custody side it includes Fidelity, Pershing, TradePMR/Robinhood, Interactive Brokers and Altruist.

Their summary sentence is the one to keep: "Claude's functionality is limited to the number of technology providers that agree to share data with it." They name the friction too: "providers' reluctance to share data with potential competitors."

That sentence describes a resource system with a particular shape. A household's financial picture is spread across a custodian, a planning tool, a CRM, a reporting layer and a few documents. Each holder decides, bilaterally and on its own commercial terms, whether an agent may read its piece. The client's picture is the resource. Its boundary is set not by what the client owns but by which vendors said yes.

Ostrom's first principle, applied to a data commons

The first design principle Elinor Ostrom found in long-lived commons was clearly defined boundaries, of two kinds: who may draw on the resource, and what the resource is. The advisor-agent stack handles the first well. Seats, entitlements and firm-level controls say who may read. It handles the second badly. Nothing tells the agent where the resource ends.

Take an agent connected to Orion, Wealthbox and MoneyGuidePro. It receives clean, structured, authoritative data from three systems. If the advisor actually runs this household's plan in eMoney, or the client has held a Fidelity account for twenty years, the agent receives no signal at all from either. A missing source does not appear as a null. It appears as nothing. The agent's view of the household looks complete because every record it did receive is internally consistent.

That is the failure that matters here, more than the vendor rivalry. It is not a data-quality problem in any one system. It is a property of the arrangement as a whole. No single participant can see it, because each vendor knows only whether it shares, and the agent knows only what it got. When the Exchange looked at Orion's gateway in September, the question was who writes the rules of a single door. This is the companion question: who keeps the map of which doors exist?

Why each new door changes everyone's answer

Betterment's plan matters because it moves the boundary, not because it is large. First its document data reaches agentic workflows inside its own advisor application. Then, depending on what the MCP release exposes, some of that data may become readable by outside agents too. The same shift happens every time a vendor on Kitces' absent list connects, and in reverse when a connection is withdrawn or degraded. Kitces notes that integrations have been unstable.

So the boundary of the resource is not fixed. It moves with each vendor's commercial decision, and nobody publishes the current state. An agent that answered "does this client hold enough cash for the roof?" correctly in November may answer it differently in January. The reason will not be a change in the client's finances. It will be a vendor joining or leaving.

Commons that last tend to solve this with a shared, maintained register: a record of boundaries kept by the users, not left to each one to infer. The advisor stack has the ingredients. Each connector is a named integration, and each firm knows which ones it has switched on. What is missing is the habit of carrying that register into every answer.

Field note: carry the boundary with the answer

1. Declare your coverage on every client-level output. List the systems you read and the systems you know exist for this household but could not read. "Holdings from Orion and Addepar; planning file in eMoney not connected" is one line, and it changes how a human weighs everything below it.
2. Treat absence as unknown, not zero. If the firm's tech stack includes a tool you cannot reach, any total you compute is a lower bound. Say so in the number's label, not in a footnote.
3. Keep a dated connector register. Record which integrations were live when you produced an answer. When a vendor joins or drops off, re-run the client views that depended on it, rather than letting old conclusions stand on a boundary that has moved.
4. Ask the next vendor to join for its terms in writing. Betterment has a year-end target for agentic access to its document data and no published MCP spec. Before routing client work through it, get answers to three questions: what fields are exposed, which agents may connect, and how a revoked or degraded connection is signalled to you.
5. If you sit on the vendor side, publish a coverage manifest. A short, machine-readable statement of what your connector exposes and what it does not costs little. It lets every agent downstream draw the boundary honestly.

The reluctance Kitces describes is rational for each vendor taken separately. Sharing data with a potential competitor is a real cost. But the agents reading the stack inherit a picture shaped by those separate decisions, with no record of where the gaps are. That is a solvable coordination problem, and the cheapest part of the solution starts with the agent: say what you could not see.