Robinhood Cortex: The Loop Stays Dumb So the Model Can Be Smart

Cortex is Robinhood's in-app assistant: portfolio questions, market research, app actions, grounded in live account data. The grounding is the point: the best assistants on the market can reason about investing, but they can't see your positions, your cost basis, your buying power - and they can't act on any of it. Cortex can do both. The goal: get the busy work out of investing.

We rolled out the first version of the Cortex Assistant in early 2026, and it did its job: real users, real money, real compliance constraints. But our bar kept moving. Models were improving every quarter, and the agentic tools we used at work all day (Claude Code, ChatGPT) - thin loops over a strong model - showed how much of that improvement a simple harness passes straight through to the user. Our architecture wasn't shaped to ride that curve. After some debate and a few internal prototypes, we rewrote the agentic loop into the shape the best agents have converged on: a minimal loop with tools.

We built the first version as an orchestra of specialists, the standard architecture of the time, and for good reason. A router fanned each request out to ~10 agents (account, research, orders) each with its own prompt, model calls, and API clients.

At the time of building this version a narrow scope per agent was how you kept answers accurate. The trade-off showed up as the product grew. Ten specialists meant ten prompts and ten toolsets to update every time the product moved. The boundaries started to blur: holdings and recent trades belonged to the account agent, but the research agent needed them too for questions like "market news about my top 3 holdings".

We rebuilt on the architecture the strongest agents today have converged on: one model, one prompt, rich tools. In reality tools like Claude Code have way more complexity, but the foundation is simple. The loop stays dumb so the model can be smart. Every layer of scaffolding we didn't build is a layer that can't dilute the model, and when models improve, Cortex improves with them. That's the bet.

Let's walk through a real use case together:

"Find me liquid covered calls to sell. How much can I earn?"

No single API answers it, the previous architecture grouped its calls once, upfront; it could never look at data and decide to keep digging.

Guardrails. We have two: input, output.

Input screening runs concurrently with the model's first step, and uses a faster model, so normally does not introduce any additional latency. If guardrail trips, it cancels the stream and declines to answer.

Output screening is expensive. Every answer block waits on the gate which is latency the user can feel. 

Everything the loop produced is persisted verbatim (message, tool calls, full tool outputs, answer) and replayed next turn; per-call injections (plan clue, compaction) ride the wire and never touch history. That's the whole trick above: the answer showed only the nearest strikes, but the persisted optionsChain output holds the entire grid. Data the user never saw is already in context, so the tapped follow-up costs zero tool calls. Two inferences collapse to one.

Replaying full history sounds expensive. It mostly isn't: prompt caching reuses compute for any byte-identical prefix, and the linear history rule above exists to keep the prefix byte-identical - replay verbatim, never rewrite, append per-call edits at the tail. Production: tens of thousands of input tokens on a turn's final call, 98% of them cache hits, at the median. The follow-up request, linearly:

Dumping every use case into a single prompt stopped scaling (was never meant to stay this simple). Now it's three layers, each with its own lifecycle - and all three obey the caching constraint: the prefix must not move.

• Core: ~25k tokens (yes we know it needs trimming :D) of identity, principles, compliance, and 40 core examples.

• Skills: vetted depth for niche territory. The prompt carries only a catalog of names; activation appends the full playbook as a message. Tax lots shipped first. A bit like the experts from our older architecture, except a skill just loads the extra prompt into the main loop.

• Steering examples. Somewhat special to Cortex: the escape hatch for small targeted patches we want to release quickly without affecting most of the product. Helpful when fixing Cortex’s response quickly after major stock splits / IPO news etc. We retrieve them using similarity score, most of the time we retrieve 0 relevant examples and clean them up once core / skills / tools properly address the issue we were patching.

Habits that beat prompt cleverness:

• Read the prompts of frontier agents: many coding CLIs are open source and you can read their prompts (Codex, OpenCode).

• Read the prompting guide for your exact model: don't be smart; follow the instructions from the company actually training the thing.

  • “In a sample of internal coding-agent eval runs, configurations with leaner system prompts improved evaluation scores by roughly 10–15% while reducing total tokens by 41–66% and cost by 33–67%.” - OpenAI

  • Claude Code with Opus 5 release deleted 80% of their system prompt (video)

  • Our next move is cutting, not adding. Prompt creep is real, and leaner prompts keep winning benchmarks.

• Have a good eval set to iterate confidently on the prompt and other parts of the system

One of the biggest frustrations we have seen with Cortex is mismatch / lack of data compared to what's available in the UI. Enter tool design.

Toolkit shape we eventually landed on:

• A couple of summary tools (portfolioSummary, accountSummary) make it feel instantly personal - what you own, what it's worth, today's move, cash and buying power

• Dozens of fine-grained data tools get near-parity with the app

• A toolkit protocol that defines all tools in one place. Makes it very easy to get a ‘feel’ of the entire API we give to our agents on a single screen. And easy to mock.

• Ability to gate tools by client version. Don’t even give the model an option to display a widget our client can’t render.

• DuckDB SQL in memory db + query tool for computing exact numerical answers.

Widgets are also modeled as tools, because a tool call is LLM inference API's one structured side-channel. Small annoyance - widgets (usually) return nothing useful, yet generation blocks on them - no provider lets you declare a void-returning tool. We still prefer them to parsing XML / structured outputs:

• a new widget is just a new tool - uniform to add, uniform to gate;

• an invalid call comes back as an error the model can fix mid-turn; parsed XML would swallow it;

• MCP Apps is standardizing the same shape.

Here's the widget from our earlier diagram:

• The docstring is a prompt surface that’s written for the model, not for engineers.

• The return value is the widget: the client renders it, the model sees a useless repr, and still blocks on the round trip.

• The error channel earns its keep: a bad symbol comes back as plain text the model reads and fixes mid-turn. Answered, not swallowed.

• Continuously follow and apply what works in state of the art. Claude Code, ChatGPT, and others have put tons of resources and great engineers into the problem of how to build a great assistant

• Keep your system as simple as possible. As models get better you will be in better shape to reconfigure your product faster

• Strive for exposing 100% of your product functionality through tools to delight users of your agent

• Maintain a good eval set. Most of this migration was possible because we were able to at scale compare how the legacy / new systems behave and ship to public with confidence

Kirill Dubovitskiy is a senior software engineer on the Cortex Assistant team at Robinhood. He focuses on making agents delightful to interact with through rapid prototyping, tool design, and specialized dev tools. Previously at Meta he built a product analytics framework for Facebook.

Xiaojing Wang is a machine learning engineer, focused on agent orchestration, agent harness, agent memory, and evaluations. He previously led Robinhood’s ML training platform and helped build Google Assistant and various Google Ads products at Google. 

Chaofan Wang is a staff machine learning engineer on Robinhood’s Agentic team, where he drives the development of agentic frameworks spanning evaluations, optimization, memory, and LLM fine-tuning. He has led the design and production deployment of several agentic products at Robinhood, including the customer service chatbot, Cortex Digest, and Cortex Assistant.

There are more challenges than fit in one post… the ones we know about, and the ones we haven't met yet. Come find them with us: https://careers.robinhood.com/

Robinhood Cortex uses generative artificial intelligence and is provided for informational purposes only. It shouldn’t be viewed as research or a recommendation to buy, sell, or hold a security or asset. Robinhood does not warrant or guarantee the accuracy, completeness, timeliness, reliability, or suitability of any response. Cortex Assistant is available to eligible Robinhood Gold subscribers. Brokerage services are offered through Robinhood Financial LLC, (“RHF”) a registered broker dealer (member SIPC), and clearing services through Robinhood Securities, LLC, (“RHS”) a registered broker dealer (member SIPC). Robinhood Gold is a subscription-based membership program of premium services offered through Robinhood Gold, LLC (“RHG”).

Options are risky and aren’t appropriate for all investors. To learn more about risks, read the Options Disclosure Document.