Paul Cuatrecasas posted something on LinkedIn that stuck with me: OpenAI hired 100+ ex-bankers to train AI on M&A, LBO, and IPO work, with the target of automating roughly 60% of junior banker tasks. He followed it with a detail that lands harder than the stat — five students email him their CVs every day asking for investment banking advice.
My first reaction was not about finance jobs. It was about the training data. OpenAI did not scrape a pile of public filings and call it a day. They hired the people who did the work. That is a specific, expensive, deliberate choice, and it tells you something about how these systems actually get good at narrow professional tasks.
Domain experts as the real dataset
I build bots for a living. The pattern I keep running into is that general models are competent at everything and excellent at nothing you actually get paid for. The gap is never raw capability. It is the unwritten rules — the formatting a managing director expects, the three adjustments everyone makes to a comps table without documenting why, the sequence of slides that survives a partner review.
None of that lives in a public corpus. It lives in the heads of people who have built four hundred pitchbooks. Hiring 100+ of them is the shortcut, and it is the same shortcut anyone building a serious vertical agent eventually has to take. You cannot prompt your way to tacit knowledge. You have to go get it from someone who has it.
If you are building in a specialized domain, that is the practical lesson. Your competitive moat is not model access. Everyone has model access. Your moat is the set of behaviors you extracted from practitioners and baked into your evaluation suite.
Why these tasks specifically
Look at what ChatGPT for Financial Services is aimed at: researching companies, analyzing financial data, and generating formatted presentations. Company research, running comps, testing valuation scenarios, building pitchbooks.
Those tasks share a structure that makes them unusually suited to automation:
- Inputs are structured or semi-structured — filings, market data, financial statements
- Outputs follow strict templates, which means correctness is checkable
- The work is high volume and repetitive, so small accuracy gains compound
- Success criteria are largely explicit, even when nobody wrote them down
Compare that to something like reading a room during a negotiation. Same industry, completely different problem. When people ask me which parts of their job an agent can take over, I point at this list. Structured input, templated output, checkable result, high volume. That combination is where these systems earn their keep.
The apprenticeship problem
The debate this launch kicked off is about entry-level finance jobs, and I think the interesting version of that debate is not “will juniors be replaced.” It is that Wall Street has used these tasks to train people. Building comps badly, getting corrected, and building them again is how an analyst learns what a valuation actually means.
Automate the task and you have not just removed labor. You have removed the training loop. That is a design question, not just an HR one, and it applies to software too. I have watched junior developers lose the debugging instinct that only comes from staring at a broken build for two hours. If the agent fixes it before they see it, the instinct never forms.
I do not have a clean answer. I suspect the honest one is that the apprenticeship moves up a level — from producing the deck to reviewing the deck, from running the model to interrogating the model’s assumptions. That is a harder skill to teach because the feedback is slower and less obvious. You know immediately when a formula breaks. You do not know immediately when a reasonable-looking output is subtly wrong.
What I would build differently
One of the sources referenced Rogo, a similar tool, and noted it was supposed to shrink the junior class but instead created more work for associates. That failure mode is worth sitting with, because I see it constantly in agent projects.
An agent that produces plausible output fast can generate more review burden than it removes. Ten decks that each need careful checking is worse than two decks somebody actually built and understands. Volume without reliability just shifts the bottleneck downstream.
So the engineering priority is not throughput. It is confidence signaling. The agent needs to tell you where it guessed, which assumptions it picked, and what it could not verify. Give a reviewer that and you have saved real time. Hand them a polished artifact with no provenance and you have created a new job called “trusting the machine,” which nobody wants and nobody is good at.
That is the part I would spend my build time on. Not making the output prettier. Making it auditable.
🕒 Published: