The Harness Reached the Boardroom. The Job Was Already on the Desk.

On 24 August the Wall Street Journal's CIO newsletter introduced its readers to the AI model harness. David Pan of Moody's supplied the definition: the harness is the code that actually runs the AI system. It holds the model's memory and its business context, and it lets an agent take actions. A system wrapped around the brains, in his phrase. Moody's built its own, so that its research assistant can draw on different Moody's data sets and switch models on the back end.

The word is new to that audience. The job is not new, and I gave it a name last December.

The word is old. The audience is new.

Engineers have used the word for years: a test harness for code, an evaluation harness for benchmarking language models, and since agents arrived, an agent harness for running them. EleutherAI's evaluation harness has been public for years, and Anthropic published a guide to agent harnesses last year. Nobody on an engineering floor needed the term explained.

This year the word reached people who do not write code. OpenAI wrote up harness engineering as a discipline in February. The WSJ put it in front of chief information officers in August. Then Jacobi Strategies, a platform vendor to large multi-asset investors, renamed its whole company The Investment Management Harness in September, two months after its revenue chief had written that "the value is in the harness." Now it reaches the budget holders, and it has become a budget line.

Pan's case for building one is sound. Harness engineering, in his words, decouples a firm's workflows from the model underneath, so the firm depends less on any single AI provider and keeps control of its own workflows. That holds for a fund as much as for Moody's. The router is the one part a fund can ignore. It sends cheaper tasks to cheaper models to keep the token bill down, and at boutique volumes the token bill is small next to the market-data bill. The harness question for a fund is a different one, and the article, written for enterprises, never reaches it.

A harness has four parts, and only one of them is hard to buy

A harness has four parts: the context the model reads, the tools it can call, the skills that tell it how this particular team does its work, and the evaluation that decides whether an answer was good enough to act on.

Three of the four are being solved in public. Vendors are shipping the tools: FactSet extended its Model Context Protocol server to portfolio analytics in June, MSCI exposes its risk models the same way, and the rest will follow. The team already knows its own workflows, how the Monday risk meeting runs, what goes in the Friday pack, who signs off a hedge, and anyone who has sat in the meetings can write them down. Evaluation is older than any of this: a PM checks the number against their own until the checking stops.

Context is the fourth part, and it behaves differently. It is the house view of the book: your own sector scheme, which is never quite GICS; your model mix, equity risk from Axioma, say, and fixed income from Bloomberg PORT MAC3; your exposure conventions, gross, net or delta-adjusted, whichever the CIO actually means when they ask; your manual exceptions and overrides; the positions the administrator books differently from the PMS. None of that exists outside the team. No vendor can ship it; they do not have it.

Pan says as much at the end of the piece. As tools and techniques develop, "the basic need to provide models with business data will always exist," and whether the practice is called context engineering, prompt engineering or harness engineering, "what doesn't change is the ability to supply language models with the right context." The practice will keep being renamed. The context underneath does not change, and only the team can write it.

When I ran risk, the context lived in my head

I spent seven years running risk and quantitative research at a multi-strategy hedge fund, with Bloomberg PORT, an external risk model provider, an internal PMS, all the internal enrichments and the fund administrator's records live at once. Each system had its own identifiers, its own classifications and its own factor definitions, and now and then its own opinion on whether a position existed. Stress testing was worse: we adjusted the risk models' shocks by hand, and once you change one shock the rest of the scenario no longer hangs together.

The mapping between all of that, and every manual exception and override, lived in my head, in custom Python scripts and in Tableau workbooks. It had no name and no line in the org chart. It sat with whoever had been there longest, which is how most desks still run it.

That was before agents. Putting AI agents on top changes nothing about the mapping. Someone still has to write it down, and now a machine has to read it, which means it has to be written properly for the first time.

Last December, at RavenPack's Exponential Summit, I gave that job a name: the Context Engineer, part librarian, part architect, part investor, and explicitly not another data scientist. The argument of the talk was that natural-language interfaces had removed the technical gate to data, so domain knowledge now drives the work rather than Python, and the scarce person on any desk would be the one who could encode how the team sees its own book. My line at the time was that 2025 was the year of agents and 2026 would be the year of context.

A year of building since then changed one thing in that argument. I put context first and the rest second. The rest matters too: tools, skills and evaluation all have to work, or the context never reaches the model. Context turned out to be the first layer, and still the only one the team has to write itself.

Some will call the person who owns that a harness engineer, and the title is already in circulation for a software role: Pydantic AI is hiring one, and the job boards list agent harness engineers in Japan and Shanghai. Harness engineers build the scaffolding, and the labs and the vendors have plenty of them. The person who decides what the scaffolding is for sits on the investment desk. That is the Context Engineer, the person who makes the harness know the fund's book.

What the enterprise version gets wrong for a lean investment team

The WSJ frames the harness as a chief information officer's decision: build it in-house, as Moody's did, or standardise on a vendor's. For a lean fund the choice matters less than what comes after it. Whether a fund builds the harness, buys it or runs a public one, it still has to be wired to the fund's own systems and its own definitions: which risk model covers which asset class, how the desk defines exposure, the manual overrides, the positions the administrator books differently. Vendors will ship connectors, and connectors are the easy part. Moody's has engineers for the wiring. A fund with a handful of investment professionals has no chief information officer and no engineer to spare, so the harness sits unconnected or the wiring lands on whoever knows the book. A large firm puts a team on it. At a small fund it belongs to one person on the side, if it belongs to anyone.

Jacobi is the first buy-side vendor to sell a harness by that name, and it is a serious product for the segment it serves: large multi-asset managers, consultants and asset owners, with forward-deployed engineers to do the wiring and a proprietary data model underneath that Jacobi calls an ontology. An ontology is the vendor's view of your book, carefully built and governed, and still the vendor's. Every vendor's harness shows you its version of your portfolio.

The evidence on where the scarce input sits is the same as it was in June. Bridgewater's AIA Labs and Thinking Machines tested frontier models on six investment judgment tasks defined by Bridgewater's own investors. The models averaged about 50% accuracy, and none cleared 80% even after expert prompt engineering. Those were research tasks, not investment risk work, so the numbers do not map straight across. The scarce input is expert judgment about what a right answer looks like, and that judgment sits on the desk. Model access is table stakes.

So what: three things to do this quarter

Three things a small fund can do this quarter.

1. Write the house view down where a machine can read it. The sector scheme, the model mix by asset class, the exposure conventions, the administrator's exceptions. Most of it already exists in scripts and workbooks somebody guards; the work is getting it out of that person's head and into a form an agent can be given. One page, not a data project.
2. Name the owner. At a small fund the Context Engineer is rarely a separate hire. On most desks the quant or the risk person already carries the mapping, and naming the role changes what they can spend time on.
3. Test any agent the way you tested every new risk model. One PM, their own number, until the checking stops. If the checking never stops, the context was wrong, and a better harness will not fix it.

The models and the tools are the same for everyone now. A fund adds the harness around them, and inside the harness the context is the one part only its own team can write. Who on your desk is writing it?

If you want to see what this looks like on your own book, we will show you on your data: medusaip.ai/demo