Real and cited. This case is reconstructed from public sources (linked inline). One honesty note up front: neither Morgan Stanley nor OpenAI calls this an "FDE" engagement. The public material describes a close customer collaboration, not a staffing model. We use it because it's the best-documented example of the work an FDE does: take a general model, make it production-grade inside one customer's hard constraints, and earn enough trust that people actually use it. Where public sources don't expose internal process, the page says so and leaves the gap visible.
The customer context
Morgan Stanley's wealth-management business runs on its research, a corpus of 100,000 documents in OpenAI's description. Before the assistant, an advisor answering a client's question could realistically reach only a fraction of it: OpenAI puts document access at 20% before the rollout. In March 2023 the firm named OpenAI its wealth-management strategic partner (OpenAI). That September it rolled out the AI @ Morgan Stanley Assistant, an internal chatbot over that library, firm-wide.
The headline outcome: the system scaled from answering "7,000 questions to a place where we can now effectively answer any question from a corpus of 100,000 documents" (David Wu, Head of Firmwide AI Product & Architecture Strategy), and over 98% of advisor teams adopted it.
The distinctive tension
Every case on this site turns on one thing candidates usually under-weight. Here it is adoption under a compliance bar.
A wealth advisor is personally accountable to a client and a regulator. They will not put an AI between themselves and that client if it might return a confident, wrong, or non-compliant answer, even once. In financial services, a single bad output doesn't just annoy a user; it's a liability. So that adoption figure isn't a usage stat. It's a trust stat. The entire engineering effort bends toward earning it. A team that treats this as "build a RAG bot over the PDFs" ships something correct and unused. The work was making it trustworthy enough that advisors chose to rely on it.
Before reading on: you're handed "build an assistant over our research library." Name the first thing you'd worry about, and it shouldn't be the vector database.
If your first worry was retrieval quality or chunking, you're thinking like an AI engineer. The FDE's first worry is: what has to be true for a risk-averse, regulated professional to trust this in front of a client? Everything below follows from that question.
Phase 1 — Discovery
The real problem wasn't "search is slow." It was that advisors couldn't reliably reach the firm's intellectual capital at the moment they needed it. And any tool that occasionally fabricated an answer would be worse than the status quo, because it would be confidently wrong about money. Discovery here means naming both halves: the value (instant access to the firm's expertise) and the constraint that dwarfs it (it has to meet the firm's "strict standards for quality and reliability").
Phase 2 — Solution architecture
The shape is retrieval-augmented generation: embed and index the research corpus, retrieve the relevant passages for a question, and have GPT-4 answer from them. That choice is almost forced. The firm needed answers grounded in its own vetted research, not the model's parametric memory, and grounding is exactly what retrieval buys you. The genuine architectural decisions were elsewhere: how to keep proprietary data private (OpenAI's "zero data retention policy… ensuring Morgan Stanley's proprietary data remains private" was load-bearing here), and how to keep a human between the model and the client (advisors "review and adjust AI-generated outputs before finalizing them").
Phase 3 — Build
The build was less "train a model" than "tune retrieval until accuracy clears the bar." The firm put its own advisors and experts in the loop to shape the assistant's behavior (the grading process Phase 4 details), and the team worked closely with OpenAI to fine-tune retrieval methods:
"Based on all the questions we input and outputs we're getting, we'd sit with OpenAI and say, 'What can we change about our retrieval methods to help the accuracy we need at Morgan Stanley?'" — Kaitlin Elliott, Head of Firmwide Generative AI Solutions
That sentence is the closest public glimpse of the FDE working mode: a tight loop between the customer's accuracy requirement and the model team's levers, run until the number is good enough.
Phase 4 — Deployment
Deployment was gated on evaluations, not on a launch date. Morgan Stanley built an "evaluation (eval) framework to test every AI use case before deployment". Concretely:
- Advisors and prompt engineers "graded AI responses for accuracy and coherence", and the team refined prompts from those grades.
- They ran summarization evals and, for multilingual clients, translation evals, fine-tuning retrieval with OpenAI.
- A daily regression suite of sample questions hunted for weaknesses and pushed the system toward compliant outputs.
Note what "production" meant here. The system was re-tested every day against a fixed question set, so a model or data change couldn't silently break compliance.
Bad / Good / Great — how you earn the advisor's trust
Bad — ship it behind a disclaimer. "We'll add 'AI can make mistakes, verify independently' and let advisors decide." This pushes the entire compliance burden onto the user, who responds rationally by not using the tool. Adoption stalls and you can't explain why the demo impressed everyone but nobody logs in.
Good — test accuracy before launch. You assemble a question set, measure answer quality, fix the worst cases, and clear a bar before rolling out. Solid, and most teams stop here. But a one-time pre-launch eval goes stale the moment the corpus or model changes, and in a regulated setting "it was accurate at launch" is not a defense.
Great — make the eval a standing, daily gate with experts in the loop. Domain experts grade outputs, the grades feed prompt and retrieval changes, and a regression suite runs daily so any drift surfaces within a day, before it can reach a client meeting. The advisor's trust rests on a process they can watch running, re-earned every day the suite passes. That near-universal adoption is built on it.
Phase 5 — Adoption
Adoption was the goal, and it came directly out of the trust work. Once advisors believed the answers, usage became daily and near-universal, with document access reported to have "jumped from 20% to 80%". A second tool, AI @ Morgan Stanley Debrief (Whisper + GPT-4 meeting notes into Salesforce, with client consent), launched in June 2024 and extended the same trust into a new workflow. One advisor reported it saved "about half an hour per meeting".
Phase 6 — Handover & scale
The pattern, once proven, became a platform play: Morgan Stanley moved to scale the Assistant beyond advisors into its institutional securities group.
The transferable pattern
In a high-stakes, regulated domain, adoption is a trust problem, and trust is an evaluation problem. The defensible move isn't a better retriever. It's a standing eval-and-review process the user can see is always on. Carry this into the AI system design round: when the prompt has a compliance or safety bar, lead with how you'd measure correctness continuously and keep a human in the loop, not with the model architecture.
Next: John Deere & Blue River — See & Spray, the same eval discipline under a different constraint: the model rides on a machine in a field.NextJohn Deere & Blue River — See & Spray