I Built 11 Production AI Agents Inside a $3B PE Fund

I spent four months as the one forward-deployed AI engineer embedded inside a US real-estate private-equity fund with roughly $3B in assets under management. In that time I shipped 11 production AI agents.

One engineer, eleven agents, one fund

Here is the part the case studies skip. The agent count was never the hard part. The guardrails were.

I keep the fund confidential, so you will not find a name here. What I can show you is the data problem underneath it, the architecture every agent shared, the families of agents I built, and the one design decision that let software get anywhere near a regulated fund's books.

If you want the shorter build log, the case study covers the platform. This piece is the deeper why: the same 11 agents, told through the decisions that kept them in production.

What forward-deployed actually meant here

Forward-deployed does not mean I sat in another building and shipped a repo over the wall. It means I embedded with the fund, learned their real workflows, and built against the mess they had, not the clean problem a slide deck would describe.

A vendor sells you a product and hopes it fits. A forward-deployed engineer moves into your problem and builds the thing only your problem needs. For a fund buried under 13 years of documents, that distinction was the whole job.

The real problem was the data, not the AI

Before a single agent was useful, I had a data problem the size of a small library. The fund's ground truth was scattered across 13 separate sources, built up over 13 years, in formats that did not agree with each other.

When I mapped it, the numbers were the story: roughly 2 TB and 1.4 million files. A person answering one question might open five systems to find the single document that held the answer. The intelligence was never the bottleneck. The hunting was.

So the first thing I built was not clever. It was a single queryable store that turned "where is the document that explains this" from an afternoon of digging into a query that returns in seconds.

The architecture under all 11 agents

The retrieval layer over that store is what all 11 agents stood on: FastAPI in front, Postgres with pgvector holding the documents, and a router that picks a cheaper or stronger model per task under a hard cost cap.

The skeleton below is the shape of it. Every agent asks the same question the same way. Retrieve the evidence first, then reason over what came back, never over what the model happened to remember.

# One retrieval + routing path, shared by all 11 agents.
async def answer(task: Task) -> Result:
    # 1. Retrieve evidence before reasoning (pgvector over ~2 TB of docs)
    evidence = await store.search(task.query, k=12)
    if not evidence:
        return Result.abstain(reason="no supporting document")

    # 2. Route: cheap model for simple tasks, strong model for hard ones
    model = router.pick(task, budget=caps.for_task(task))

    # 3. Reason only over retrieved evidence, then verify it
    draft = await model.run(task, context=evidence)
    return verify(draft, evidence)  # NLI + numeric checks, else abstain

The two lines that matter are the retrieve call and the model routing. Retrieval is what keeps every answer grounded in a real document. The router and its cost cap are what keep 11 agents from quietly running up a bill nobody approved.

The 11 agents, by family

I will not walk you through 11 agents one at a time; the fund is confidential, and the useful way to see them is by family anyway. Every agent did one of a few jobs, and every family carried its own guardrail.

The layer that let them near the books

Every one of those families sat on the same safety layer. In a regulated fund a confident wrong answer costs more than a slow one, so this is where most of the engineering went.

Three moving parts. Every claim points at a real source document, not the model's memory. Every number gets checked before anyone acts on it. And when the evidence is thin, the agent says so and escalates instead of inventing something plausible.

All of it was evaluated and red-teamed before it went live.

I go deep on the citation-and-abstention design in its own episode on RAG that is allowed to say I do not know. The one-line version is that giving the agents permission to abstain is exactly what let them near the books.

One agent, unpacked: 8 hours to 23 minutes

Take the one agent people always ask about. The fund's bank reconciliation used to eat a full working day, about 8 hours of a smart person cross-checking numbers by hand. With the shared retrieval layer underneath it, that agent brought the same job down to 23 minutes, most of which is a human reviewing the handful of cases it was not sure about.

I broke that single agent down end to end in its own episode, including the part that mattered most: what it refused to match. It is the clearest example of the whole platform's thesis living inside one workflow.

What this unlocks, and who should hire it

So what do 11 production agents inside a real fund actually buy you? Mostly they buy you the difference between a listicle and a track record.

The market is full of consultancies that will send you a slide with 11 use cases for AI in finance. What almost none of them can send you is one engineer who embedded in a regulated fund, shipped the agents, and can name the guardrail on each one. That gap is the whole pitch.

If you want the framework I use to tell a real deployment from a demo, it is the FDE Evidence Ladder.

And if you are weighing whether a forward-deployed engineer is the shape of hire your problem needs, or you want to see what I actually do, those pages go deeper than this one can.

FAQ