AI Wrote a Trading Signal That Is Running Real Money. The Lesson Is About Skills, Not Trading.
Man Group manages $200 billion in pension money. They put AI at the center of a research workflow that produced live signals. The story they told at Code with Claude London was about skills governance, and it applies to everyone.
Three key takeaways
- There are trading signals running in production at Man Group, in a regulated firm with real capital, that were researched, back tested, written up, and productionized by AI. Humans reviewed the output. AI was at the center.
- The thing that made it possible was not a model upgrade. It was skills governance. A common marketplace with workflow ownership, evals, tagging, versioning, and a library style review process.
- Adoption is the easy part. The hard part is making sure the right people, the actual workflow owners, are the ones writing the skills. Power users will fill the gap. That is what creates the hardcoded cost center code in someone else's expense skill.
Tashara Fernando is head of data and AI at Man Group, an alternative investment manager with over $200 billion under management. Their clients are pension funds, sovereign wealth funds, and large institutions. The money belongs to teachers in Canada and metal workers in Japan. When she talks about getting AI right, the stakes she means are real.
Her talk at Code with Claude London 2026 had a hook so direct it almost overshadowed the rest of the content. There are trading signals running right now in production at Man Group, at a regulated investment firm running real capital, that were researched, back tested, and proposed by AI. AI came up with the idea. AI got the data. AI ran the back test. AI wrote the strategy proposal. AI productionized the signal. Humans reviewed the output.
She then said, before anyone could ask, that she was not going to tell us what the signal was. That is their IP. What she would tell us was the foundation that made it possible, and how to apply the same lessons in any company.
The foundation is skills. The lesson is skills governance.
What systematic trading actually is
Quick translation for people who do not work in finance. Systematic trading means algorithmic trading across thousands of securities and hundreds of markets. The unit of work is a signal. A signal is a ranking strategy. You rank stocks by some factor, you back the ones at the top, you short the ones at the bottom, and you run that strategy through fifteen or more years of historical data to see how it would have performed.
Fernando used a fantasy football analogy that works. Your starting lineup is the green bars, the stocks you go long. The red bars are the reserves, the stocks you short. The middle is the bench. The interesting question is always which factor you rank by, whether it works, and how you know.
You never really know. You back test against fifteen years of history, you run the strategy through different macro environments and stresses, you compute the annualized return, the drawdown, and the sharp ratio. Those statistical factors tell you something. They do not tell you the future.
That is the work AI is now doing at Man Group. Coming up with ranking ideas. Pulling the data. Running the back tests. Writing the proposals. Productionizing the winners.
The iceberg
The signal is the visible thing. Underneath it is everything that makes it possible.
How you clean the data. How you stitch prices when symbols change. How you detect outliers. How you run the back tests. What infrastructure they run on. How you compare results across teams.
If different teams run different versions of those workflows, they get different answers. One team's back test looks amazing. Another team's looks average. You cannot tell whether one team had a better idea or whether they are just measuring differently. That kills your ability to compare signals, which is the whole point of doing systematic trading at scale.
Shared workflows fix that. One common foundation, no duplicated effort, comparable outputs. In systematic trading where you are constantly ranking ideas against each other, that comparability is the entire game.
This is where skills come in. Out of the box, Claude is a strong general purpose tool. It does a lot. It does not know your data. It does not know your systems. It does not know how your team cleans prices or which outlier detection method you trust. That gap is the same for every company.
"The first thing that we had to do was teach it. Not by retraining it, not by doing fine-tuning, but by giving it access to our data, our capabilities, and our workflows. That's our superpower. We have decades of institutional knowledge in systematic research and some of the best technical capabilities on the street."
Skills are the connective layer. You write a skill that captures one of your workflows, you attach it to an agent or a session, and now AI knows how your team does that thing.
The wrong way to roll skills out
Man Group went all in on adoption first. Workshops with Anthropic. Hackathons. Internal blog posts. Show and tell sessions. Everyone wrote skills. Adoption was, in her words, out of this world.
Then the cracks showed up.
The skills were being written by power users. Not by process owners. The skills represented local optimizations for one user. They were not common organizational solutions. Fernando told a story that captures the failure mode perfectly.
There was a guy at Man Group who travelled a lot and had a lot of expenses to file. He wrote a skill that ate pictures of receipts and produced expense reports. He showed it off, shared it with a few teammates, and it worked well. Then a few days later the expense approver came around and asked why Claude was creating expense reports against his cost center for people from technology, from the people team, from departments he had nothing to do with.
The cost center code was hardcoded. The skill worked for the guy who wrote it. It would have worked for everyone on his team. Nobody had reviewed it. He was not accountable for the skill. He thought it was funny. Fernando did too. But it was symptomatic.
"People were just codifying their ways of doing things. They weren't the organizational ways of doing things. And in many cases, they weren't actually the workflow owner."
In a sales team that is annoying. In systematic trading where signals get judged against each other and run real capital, it is a non starter. If the person who owns the back testing workflow is not the person who wrote the back testing skill, you cannot trust the skill.
The marketplace
Their solve was a common marketplace. Every skill visible, tagged, tested with evals. They called it My Knowledge and it acts as Man Group's context store.
Skill suggestions are tailored to each business unit. Skills have clear ownership. They are organized into managed and community skills. Plugins group useful skills together, like a data plugin that gives access to Man Group's data sets. Individual skills can be installed too, like the data set skill that lets you search the alternative data sets.
The principles are worth listing.
Every skill is visible to everyone who could install it. Skills are tagged. Skills have evals. Each skill is owned by the actual workflow owner, not the power user who happens to use that workflow most. Usage is tracked. Skills are reviewed. Skills have a lifecycle. Skills get retired when they should be retired.
She compared it to a library. There are sections for the finance department, the people department, the research department. The library cares for each item. The library has a process for retiring books that no longer belong on the shelf. The care is what makes the library a library and not a junk drawer.
That care is what turns skills from an individual productivity tool into a foundation that holds up under enterprise scale.
What a research workflow looks like with this
The demo Fernando showed was a back test on credit card data. The setup was specific enough to be useful.
They start with the alternative data set skill. They ask Claude what credit card data sets are available. It identifies a US consumer transactions data set. They plot Amazon's monthly credit card spend against its stock price returns. The blue bars are credit card spend. The line is the stock price. You can see spikes around Black Friday and Christmas, which is the kind of seasonality you want a model to notice.
Then they run a back test. Is credit card spend predictive of the stock price? The signal performs better than buy and hold. A thousand dollars invested in 2021 using the signal would be worth around twenty five hundred today.
That could be a fluke for Amazon. So they run it across a broader universe of retail companies, using their distributed compute infrastructure. Each company runs on an individual worker. Findings get collected and compared.
"In this case study, we leveraged four skills to create a systematic trading signal. In reality, our signal research is much more nuanced, accounting for things like seasonality, inflation, and broader sets of securities. We do this with agents as well as humans exploring these ideas. The key takeaway is that the governance of these skills is key."
Four skills did most of the work in the demo. Each of those skills was written by the workflow owner. Each had evals. Each was visible to anyone in the firm who wanted to use it. The signal proposed by AI was reviewed by humans. The signal is now in production.
What this generalizes to
If you do not run systematic trading, the specifics do not apply. The pattern does.
Your organizational context is your moat. The frontier labs are not going to solve it for you. It is not on the internet. They do not know your workflows. You already have the context. You have decades of it. The work is on exposing it, not reinventing it.
Skills are how decades of institutional knowledge become usable by AI. Treat them like production code, because that is what they will become.
"Plan your approach before you plan the rollout. Who's going to own the skill? Who's going to review it? How does it get retired? How does it get tested? Decide this before shipping the first skill, not after the hundredth like us."
Adoption is not a licensing problem. It is a people problem. Once the platform is in place you have to encourage engagement. You have to capture organizational context and rethink workflows rather than just augment them. That is a training problem and an engagement problem.
The numbers from Man Group say something about how this scales when you get it right. The firm has around seventeen or eighteen hundred people. Seven hundred and fifty of them use Claude Code. That is across developers, quants, the people team, the finance team. Every department is on it. They have over a hundred governed skills and at least as many community skills, all looked after in a library, all visible.
Why "leverage that superpower" is actually the right framing
There is a phrase in the talk that I would normally argue with, because the word leverage as a verb is a tell I look for in AI prose. Fernando used it, and in her mouth it earned its place.
"We have decades of institutional knowledge in systematic research and some of the best technical capabilities on the street. And if we can connect that with AI, then AI can leverage that superpower."
The reason it works there is that she meant something specific. The institutional knowledge is real. The technical capabilities are real. They predate the AI work by decades. The new thing is the connector. Skills are the wire. AI is what pulls on the wire. You do not have a superpower because you have AI. You have a superpower because you spent thirty years building the workflows underneath, and now AI can touch them.
That distinction matters when you are talking to a board about AI investment. The mistake is to frame the investment as buying a model. The model is a commodity. The investment is in skills, governance, ownership, and the cleanup work that turns your tribal knowledge into something a machine can use. Most boards do not understand that. Most CIOs do not pitch it that way. They should.
Where this fails if you skip the governance
You can imagine the failure mode without much help. A firm gets excited about AI in research. They run hackathons. People write skills. The skills proliferate. There is no library, no review, no ownership map. The first signal proposed by AI looks great. It goes into a back test. The back test uses one team's price stitching skill. The signal looks great. It goes to compliance. Compliance asks how the stitching was done. The skill author is on holiday. The skill has not been reviewed. The cost center on the receipts is wrong, metaphorically.
That is the place most firms will land if they do not do the governance work up front. Not catastrophic. Just embarrassing and slow and impossible to scale beyond the team that built the original skill.
The Man Group story is interesting because they had to learn this the hard way. They went all in on adoption first, hit the cracks, and then built the governance after. Fernando's advice is to do it the other way around. Plan ownership, review, retirement, and testing before shipping the first skill. Not after the hundredth.
The lesson, distilled
Three things.
First, decide who owns each workflow. Not who uses it most. Who owns it. That is who writes the skill. That is who reviews changes to the skill. That is who decides when to retire it.
Second, build the platform before you encourage adoption. Visibility, tags, evals, versioning, ownership, lifecycle. Without that scaffolding you get the expense report story repeated a hundred times across departments.
Third, treat skills like production code. They are. They will run inside AI loops that touch real systems and produce real outputs. The hardcoded cost center in a hobby skill is a small mistake. The hardcoded assumption in a back testing skill is a regulatory problem.
The reason Man Group can have AI propose trading signals that run real capital is not that they hired the best AI researchers, although they have. It is that they built the infrastructure that makes AI's output reviewable, comparable, and tied to the right workflow owner. That infrastructure is what your firm needs too, regardless of what you are trying to automate.
The frontier labs will keep shipping better models. Your moat is everything underneath the signal. The cleaner workflows. The reviewed skills. The library that captures decades of how your team actually works.
That is the part you build. That is the part nobody can ship for you.
Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.
This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.
My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.
Source talk: Building signals that trade themselves at Code with Claude London 2026. https://youtu.be/EOg4gY0Yln0