Cortex · Blueprint
In August 2026 three Robinhood engineers wrote up the architecture behind Cortex, the investing assistant inside their app. It is one of the few detailed accounts of a production agent that touches real money. This is what the record actually says, what the filed legal agreement adds to it, and what we built from both.
Part 01 — The subject
Cortex is Robinhood's AI investing assistant, announced March 2025 and gated behind Robinhood Gold at $5 a month. It ships in four surfaces: Digests, which explain why a ticker moved; Portfolio Digests, which do the same for your own holdings; Trade Builder, which turns a market opinion into an options structure; and the Assistant, a conversational layer that reads positions across accounts, builds watchlists, sets alerts, moves cash, and pre-fills orders.
Coverage is narrower than the surfaces suggest. Robinhood's own support page for Digests says they run on the most popular public stocks on the platform, publicly traded instruments only — and that they go unavailable entirely for a security undergoing a stock split, merger, spinoff or reverse split. The product would rather say nothing than summarise a moving target.
The distinguishing feature is not the model. It is the grounding. A general assistant can reason about investing but cannot see your cost basis, your buying power, or your tax lots, and cannot act on any of it. Cortex does both, inside a regulated product, for people risking real money.
Most published agent architectures come from demos, internal tools, or products where a wrong answer costs nothing. This one comes from a regulated broker with a million users and a filed customer agreement. If you are building anything where a mistake has consequences, it is worth more than a dozen tutorials, because every design decision in it had to survive compliance review.
Part 02 — The rewrite
Version one was the shape everyone was building in 2025: a router fanning each request out to roughly ten specialist agents — account, research, orders — each with its own prompt, model calls and API clients. At the time that was how you kept answers accurate. Narrow the scope per agent, and each one is easier to get right.
It went live in Q1 2026 to paying subscribers with real brokerage accounts behind it. By the team's own account, it did its job.
What broke was maintainability first. Ten specialists meant ten prompts and ten toolsets to update every time the product moved. Then the boundaries started leaking: holdings and recent trades belonged to the account agent, but the research agent needed them too, for a question as ordinary as market news about my top three holdings.
The deeper problem was structural. The router grouped its calls once, upfront. It could never look at what came back and decide to keep digging — and a question like find me liquid covered calls to sell has no single API behind it. It needs a system that reads a chain, notices the wings are illiquid, and goes further. No amount of tuning teaches an upfront router to do that.
The loop stays dumb so the model can be smart.
Robinhood Cortex engineering team · 25 August 2026
The replacement is one model, one prompt, rich tools, and a loop with nothing clever in it. The bet: every layer of scaffolding sits between the model and the user, so when models improve, the improvement has to survive the trip. Remove the layers and you inherit each gain for free.
It is the clearest published argument against the multi-agent default, made by a team that had shipped the multi-agent version and then paid to remove it. If you are deciding whether to add a router, a planner or a supervisor to your own agent, this is the counter-case — and it comes with the failure modes named, which is rarer than the conclusion.
The practical test it suggests: for every layer you are about to build, ask what happens to it when the model gets a generation better. If the answer is "it still sits in the way", that is a cost you will pay every quarter.
Part 03 — The mechanics
Message, tool calls, full tool outputs and answer are persisted exactly as produced and replayed on the next turn. Per-call injections ride the wire and never touch what is stored. This sounds expensive and mostly is not: prompt caching reuses compute for any byte-identical prefix, and the verbatim rule exists to keep that prefix byte-identical. In production it reaches tens of thousands of input tokens per turn with 98% served from cache at the median.
It buys a second thing that is easy to miss. The answer might show six option strikes; the persisted chain holds the entire grid. Data the user never saw is already in context, so the follow-up question costs zero tool calls and two inferences collapse into one.
Core is roughly 25,000 tokens of identity, principles, compliance and forty examples — and the team's own note is that the next move is cutting, not adding. Skills sit in that prompt as a catalog of names only; activating one appends the full playbook as a message, so the cached prefix never shifts. Tax lots shipped first. Steering examples are small patches retrieved by similarity, used to repair answers quickly after events like a stock split, and deleted once core or skills cover the case properly. Most turns retrieve none.
Two summary calls make it instantly personal; dozens of fine-grained ones reach near-parity with the app. Everything is declared in one protocol file, so the whole agent-facing API fits on a screen and mocks cleanly, and every tool is gated by client version so the model is never offered a widget the installed app cannot draw. Numerical work goes through an in-memory DuckDB and a SQL tool rather than the model's head. Widgets are modelled as tools too, because a tool call is the one structured side-channel the inference API offers.
Input screening runs concurrently with the model's first step on a faster model, so it normally costs no latency at all; if it trips, the stream is cancelled. Output screening cannot overlap — every answer block waits on it, and the user feels every millisecond. The asymmetry is the design: a false negative on the way in is recoverable because the output gate stands behind it, and a false negative on the way out has already been seen.
These four are portable. None of them depend on being a broker.
Linear history is a cost decision disguised as a data-structure decision — if your agent rewrites or summarises its own history mid-conversation, you are paying full price for every token after the rewrite. The skills pattern is how you add depth without paying for it on every turn. Widgets-as-tools removes an entire category of parsing bugs. And asymmetric guardrails is the one most teams get backwards: they put the expensive check on the way in, where it delays every request, instead of on the way out, where it actually protects someone.
Part 04 — The limits
Most write-ups of Cortex stop at the feature list. The Cortex Assistant Agreement, served from Robinhood's own CDN and stamped with a control number dating it to 16 June 2026, is where the product's actual shape lives — and it is far narrower than the marketing implies.
This is the most reusable document in the whole set, and the least read. It is a regulated broker's own list of what it decided an AI could safely be allowed to do in a brokerage account — written by people who had to defend each line.
Three of them are worth copying outright regardless of your domain. Read and write are separate capabilities: Cortex can analyse an options chain in full and cannot trade it, and that separation is cheap to implement and expensive to retrofit. A gap is an answer: a tool that reports it does not cover an instrument is worth more than one that returns a confident guess. And go quiet while the ground moves: the corporate-action blackout is a product deliberately withholding output during the exact window when its inputs are least trustworthy, which is a harder discipline than it sounds and almost nobody builds it.
Part 05 — What we built
Reading an architecture and building it are different things, and the second finds the details the first glosses over. So the published design is implemented here as working TypeScript, with a mock brokerage account behind it — fixed positions, fixed prices, no real money.
The load-bearing constraint is implemented rather than described. Action tools draft a ticket and stop. There is no confirm tool, the HTTP confirm endpoint is the only path to the broker, and the test suite asserts that absence — so if someone adds one later, the tests go red.
Three uses, depending on what you came for.
As a starting point: swap the mock adapter for a real one and the same 21 tools run against anything. The protocol, the loop and the caching discipline are domain-agnostic.
As a reference: the parts of the published architecture that were described in a paragraph are here as code you can read — what "widgets are tools" actually means at the type level, or how a rolling cache breakpoint is applied without mutating stored history.
As a test bed: the mock broker is deterministic, so you can measure a prompt change without a live account, a market, or a bill.
Part 06 — The eval set
The engineering post is explicit that the rewrite was only possible because the team could compare the old and new systems at scale before shipping. So there is an eval set here, and it grades the way the guidance for agents says to: on the end state and the trajectory, not on what the model said about them.
A case asserts which tools ran, whether a ticket exists and carries the right fields, and whether cash and positions moved. Two invariants hold across the whole set: no turn may move money, because no case confirms a ticket; and no case may be vacuous — a self-test runs an agent that does nothing against all 44 and requires every one to fail. That check has already caught three cases whose assertions were all negative and which an inert agent would have passed.
The falsifiability check is the transferable idea. Run a do-nothing agent against your eval set; every case that passes is measuring nothing and quietly inflating your score. It costs ten lines and it will find something.
The second is the honesty device: each case records why it exists, so when a case stops being true you delete it instead of maintaining it forever.
Part 07 — Status
Worth being exact about, because "it's built" and "it works" are different claims.
Setting one environment variable closes all three. The provider layer accepts either a first-party Anthropic key or an OpenRouter one — OpenRouter exposes an Anthropic Messages-API endpoint rather than an OpenAI-shaped shim, so the SDK, the request shape and, critically, cache_control all survive the switch. Two Anthropic-only fields do not, and that is declared in code rather than discovered at runtime.
Part 08 — The record
Nothing here was leaked, reverse-engineered, or inferred from an app teardown. Every figure traces to a document Robinhood published, filed, posted, or serves from a host it controls — ten exhibits across six domains, laid out in full on the blueprint.
The shortest of them settles the ownership question on its own. Five days after the launch event, on his own account, the founder and CEO listed it as the second of three products announced that week:
Robinhood Cortex, our AI investment tool
Vlad Tenev · 31 March 2025
What the exhibits do not show is worth stating too. Robinhood has never named the third-party AI providers behind Cortex — the agreement discloses that they exist and names none. There are no published latency targets, no serving topology, and no model identity. Anything beyond those ten documents is marked as derived, and the latencies in the trace panels are illustrative and labelled as such.
If you cite any of this, cite the exhibit rather than this article. And if you write something similar about another company, separate what was published from what you concluded — the marks that do that are the reason the rest is worth reading.
Part 09 — What this is not
This is a documentation project and a reference implementation. It has no relationship with Robinhood Markets, Inc. or any of its subsidiaries, is not endorsed or reviewed by them, and provides no access whatsoever to Robinhood accounts, products or services. Robinhood, Cortex, Legend and Gold are marks of their owner, used here to identify the systems described.
Nothing in it is investment advice. It describes software architecture; it recommends no security, strategy or platform, and it is not research. Connecting an agent to a real brokerage account is a regulated activity in most jurisdictions — the confirmation gate exists for reasons that are legal as well as technical.