Over the past year, the AI conversations we have with private markets firms have changed. Early pilots, such as an assistant over fund documents or a tool that drafts first-pass DDQ responses, have largely proven their value. The question now is what comes next: agents that can interact with systems, retrieve information and complete tasks across the organisation.
It is the right ambition, and one we are actively supporting clients with. However, in our experience the conversation often starts in the wrong place. Firms spend considerable time deciding which AI agent to build or which AI platform or provider to use, and far less time on the question that ultimately determines whether it works: what environment are we asking that agent to operate in?
Having spent much of my career integrating private markets systems, I see agents as a new and far more demanding consumer of the technology estate. An agent does not know which spreadsheet the team quietly trusts, or which CRM fields have not been updated since the last fundraise. It works with whatever the underlying systems give it, and it will expose weaknesses in data, integrations and permissions very quickly.
1. Connectivity is the starting point, not the solution
A typical mid-sized private markets manager relies on a range of interconnected systems, including CRM, portfolio monitoring, fund accounting and document management platforms such as SharePoint. These are often supported by external service providers and, increasingly, centralised data platforms such as Microsoft Fabric, Snowflake or Databricks. Integrating these different technologies presents challenges, as each system has its own APIs, authentication requirements and technical limitations.
MCP (Model Context Protocol) has been a genuine step forward, providing a standard way to expose a system’s data and actions to AI tools, so connectors are built once rather than for every new tool. However, MCP is only the plumbing; it does nothing for data quality or data context out of the box. An MCP server sitting on top of inconsistent data simply gives an agent a more efficient route to it.
There is also a less obvious risk: in most firms, users work through the application interface whilst only integrations rely on the API. This bypasses controls implemented at the UI layer, which can cause data discrepancies between AI sitting on top of operational systems and the data warehouse. If the business rarely relies on an API, it has barely been tested, then an agent will often be the first to find its gaps.
2. Fragmented data undermines confident answers
Consider a simple question: what is our total exposure to a particular company? The deal team records it by trading name in the CRM, portfolio monitoring holds the operating company, fund accounting books the investment at holdco level and the credit team tracks the borrower entity. An agent with access to all four may return a confident answer based on whichever record it finds first.
People know which sources to trust and resolve conflicts through context and experience; agents need it engineered. That means a common entity record, robust master data and a curated layer within the warehouse where CRM, portfolio and accounting data are reconciled before anyone, human or machine, queries them. Recently, we built this reconciled layer across CRM and portfolio monitoring data, and this really was the differentiator between an agent the team could trust and one they would need to continuously verify every result.
3. Permissions matter more when an agent acts on your behalf
Access control in private markets has often been imperfect but tolerable. Employees’ access is generally not as tight as it should be, but people rarely go looking beyond what they need. An agent, by design, will look wherever access is granted in order to obtain answers. Connect it to SharePoint and any folder with historic permission issues immediately becomes a retrieval source, which needs special attention when creating agents for key operational flows.
The question therefore shifts from what an employee can access to what an agent acting on their behalf should be allowed to retrieve and action. For firms running both private equity and private credit strategies, information barriers make this essential. In practice, this means delegated identity rather than shared service accounts with broad access, clear separation between read and write permissions, and human approval for any action that updates a system of record or leaves the organisation.
4. Lineage underpins trust
When an investment committee member asks where a figure came from, “the AI produced it” is not an acceptable answer. Agent outputs need to reference the system, record and point in time they were drawn from. Without that traceability, outputs cannot be relied upon for investor reporting, and compliance teams will rightly resist their use.
This is where investment in data lineage pays off. Mapping how CRM fields flow into warehouse tables and onward into reporting provides a vital audit trail for AI. A lot of the recent work we have carried out on agents has involved building out data lineage capability. Equally, we routinely log the agent’s own activity: which tools it called, with what inputs, and what was returned.
5. Architecture must be built for scale
The risk we see most often is each new AI use case being delivered with its own integration. A DDQ assistant connects to SharePoint, a pipeline agent connects to the CRM and a notices agent reads a shared inbox. Within eighteen months, firms risk recreating the point-to-point estate the industry has spent a decade moving away from, now with a language model in the middle of each connection.
A more sustainable approach treats agents as consumers of a shared platform. That platform combines a governed data layer for analytical questions with a common set of connectors, increasingly MCP servers, with consistent authentication and logging. A semantic layer then defines metrics such as NAV, committed capital or active deals once. With this in place, each new use case becomes a new workflow rather than a new integration project.
6. Build vs buy
Platform vendors are rapidly introducing agentic capabilities into their products. Where work sits within a single system, such as summarising a deal record or drafting CRM notes, native functionality is usually the right choice, as vendors understand their own data models best.
The case for building an AI layer is strongest where value spans multiple systems: investment committee preparation drawing on CRM data, diligence documents and model outputs; portfolio monitoring that tests reported KPIs against covenant terms; and DDQ responses combining policies, previous answers and live fund data. No single vendor owns that cross-system view, and it is often where a firm’s competitive edge sits.
Equally, not every process needs an agent. Many are better served by a reliable automated pipeline, an existing report or a person. Agentic workflows earn their place where inputs vary, context spans several systems and a human reviews the output. Calculating a distribution waterfall, for example, is deterministic and belongs in the system built for it. At most, a dedicated agent might trigger that calculation and return the result, but the logic itself should never sit with the model.
Final thoughts
Before asking “which AI agent should we build?”, technology leaders should first ask “what environment are we asking that agent to operate in?” Can it reach core systems through governed connectors? Do those systems agree on companies, funds and investors? Does it act with the right identity? Can every output be traced back to source? And will the next use case be able to reuse what has already been built?
AI agents will expose fragmented systems, weak integrations, inconsistent data and loose permissions quickly. That is not a reason to delay, but a reason to treat data architecture, interoperability, identity and governance as part of the AI strategy itself, rather than as separate technology projects. The firms that do will find their second, third and tenth agent significantly faster, cheaper and safer to deliver than their first.
Ready to move from AI experimentation to implementation?
Discover how it|venture can help you build the connected, trusted data and technology foundations needed to scale AI with confidence.
