Seven lessons from applying AI inside research teams at financial institutions: three operational, four technical, in enough detail to take back to your own team.
I've spent 20+ years building software, much of it in classical machine learning and data infrastructure — leading teams while staying hands-on in the systems myself. A lot of that time was inside hedge funds and fintech startups. My focus now, through my consulting practice PragmaNexus, is layering large language models onto that foundation and getting them working in production with teams in a few different industries. The lessons here come from the work with research teams at financial institutions.
Consulting at pragmanexus.com · fuller background at mattstockton.com/my-background · writing at mattstockton.com
How to use this guide. It follows the live session: three operational lessons, then four technical ones in plain language. Each lesson is one claim, an interactive figure you can poke at, the why behind it, and what to do about it. After the close: six more lessons in compressed form, pointers on where to go from here, and how this guide itself was built.
The tools are rarely the hard part. These three lessons are about why capable tools sit unused, and what actually gets a research team using them.
Nothing here requires writing code. These four run in order: how to pick the right task, how to get it working, how to make it trustworthy, and how to keep it trustworthy.
Don't try to boil the ocean with a firm-wide platform. Pick one named workflow: reviewing earnings transcripts, prepping for a management meeting. Have one motivated person get it working hands-on, in a tool with access to files. You shouldn't be doing this in ChatGPT in the browser; you want the tools that can work with your file system. Then write down what worked as shared instructions so the next person doesn't start over. Firm capability gets built one workflow at a time.
And it all traces back to the data. Where is it living? How are you storing it? Are your workflows actually capturing the information you care about? If not, that's the first fix, and it's a process change that needs buy-in. Buying something won't do it.
If early-stage research takes half the time, those hours go to looking at more names. That's the case that lands with leadership. And the most convincing use cases are things people can't do at any speed, like checking one company's claims against every competitor's public statements. Speeding up a slow task is a weaker story.
Fluency with these tools takes real hours. The techniques change fast, and the judgment you build carries over as the tools churn. This is also why the champion at the top has to actually use the tools instead of delegating them. The fluency stays with whoever puts in the hours.
And try something you think the model can't do. A lot of people still use these tools like a fancier Google search, and it caps what they get out of them. Usually it clicks the first time the model handles something you assumed was impossible.
Paste this into any tool your firm has approved, and let it interview you. It's Lesson 3 pointed at yourself. Fill in the two blanks and the prompt updates:
I work as [your role] at [type of firm]. Interview me about my regular tasks, one question at a time, then suggest three specific places you could help. Then help me do the first one today.
The fastest way to learn these tools is to point them at your own job.
These didn't make the hour, but they come up all the time. Same shape as the main seven, compressed. Click a card to open the detail.
A short list on purpose. Each item is tagged with who it's for, so you know which one to forward.
This guide is itself an example of something I keep pushing teams toward: sharing information as a single self-contained page instead of a slide deck. There's no server and no framework behind this. It's one HTML file. You can save it, email it, open it on a phone, and the interactive parts keep working.
The build followed the same lessons it teaches. I started from material that already existed (my own notes, an outline, things I've already published) and worked with an AI agent that could read those files directly. I described the audience and what the hour needed to do, let it draft, and then ran the red-pen loop from Lesson 3: say specifically what's wrong and why, feed it back, go again. Getting it to sound like me took a few passes.
None of this required writing HTML by hand. Everything interactive above, the quizzes, the charts, the toggles, is plain HTML, CSS, and JavaScript in this same single file, and each figure started as a sentence or two describing what it should show. If you can describe the content and how people should move through it, the models can build the artifact for you. Next time you're about to make a deck for something people should explore themselves, try asking for a page like this instead.