The AI Architecture Series – Part 3

The bottleneck in investment workflows is often not the analysis itself, but rather everything that has to happen before analysis can begin: running compliance checks, mapping portfolio positions against mandate criteria, classifying a fund against a regulatory standard, surfacing controversies across a universe, amongst many other such tasks.

These are not analytical duties. They are retrieval and formatting tasks wearing analytical work’s loose-fitting clothing. The architecture we described in the previous piece was built to address exactly this problem.

In parts 1 and 2 of the AI Architecture series, we established why architecture choices compound over time and how the four layers (the LLM, MCPs, skills, and agents) fit together in theory. In this piece, we get practical, exploring what each layer contributes to real investment workflows, what a concrete use case reveals about present possibilities, and the constraints of model context protocols (MCPs).

The problem worth naming in investment analysis

Data availability once acted as a constraint on investment analysis and compliance. However, as corporate disclosure matured and data sources multiplied, the constraint inverted for many firms. The quantity of data available to them exceeded their ability to act upon it. The result is a sort of “stranded insight” defined by the gap between information that exists in a system and a decision that can actually be made with it.

Consider an analyst checking mandate compliance. The steps that precede their analysis include navigating to the correct dataset or file, selecting the right portfolio, locating the relevant mandate, launching the compliance check, interpreting the metric-level output, and identifying the violations and associated drivers. None of those steps involve deep judgment or critical thinking. They involve knowing where to click and being able to reliably repeat the process.

This is not a criticism of existing systems. It is a description of how most structured data products have always worked: powerful systems that require users to know how to operate them.

AI, and specifically the architecture toward which this series of articles has been building, allows us to reimagine this status quo. An LLM’s general reasoning, paired with the domain-specific data and methodologies of a specialized MCP collapses the distance between question and answer. The “overhead” work that once consumed an analyst’s morning (the navigation, filtering, exporting, formatting) disappears. What remains is judgment; the differentiated work that the analyst was hired to do.

AI-powered mandate monitoring: A real-world example

As a tech company, Clarity AI’s philosophy is to meet clients where they work, rather than requiring them to come to us.

Our API-first foundation makes the agent layer a natural extension of that guiding principle. Our suite of MCPs, including one tuned to monitor portfolio compliance with investment mandates, integrates Clarity AI’s data and methodology directly into the preferred AI applications or internal systems our clients already use. These MCPs facilitate workflows that run end-to-end with simple natural language prompts like “please check the compliance of my portfolio with my investment mandate”.

A single sentence in plain language sets a full workflow in motion. Absent any additional user specification, Claude reasons about the requirements of the prompts and, in response, calls a series of distinct tools, pulling the user’s mandates and portfolio holdings, running the compliance checks at the metric level, and assembling the results.

The outputs render as a structured, interactive table inside the chat, including metric-level pass/fail outcomes and enumerated breaching companies. All values are traceable via follow-up questions or direct linkout to Clarity AI’s web application for deeper investigation.

What used to require navigating a data portal, locating the right portfolio and mandate, interpreting metric-level outputs, formatting the results, and filtering for offenders is now resolved with a single exchange.

A well-designed web application is the right tool for exploring data, specifically for open-ended questions where visual scaffolding helps the user navigate an environment rich with possibilities. After all, many of the best questions arise as a result of mere data exploration. However, the workflow described above is not exploratory.

The portfolio manager knows the question, portfolio, and mandate, and wants the answer. For this kind of concrete-outcome work, even the best-designed interface adds a translation step in which the user must convert a plain-language question into a sequence of clicks. MCP architecture removes that translation and compresses the path from question to answer. The user asks the question in the language they would have used with an analyst, and the system returns the answer in seconds.

That compression depends on the MCP doing something that the LLM itself cannot do alone. Foundation models like Claude carry enormous general knowledge but lack the specialized, curated data and methodologically-grounded information that regulated industries depend upon.

Consider a portfolio manager running a faith-based values mandate against a portfolio of funds.

A general-purpose LLM with web access would have to identify each fund’s holdings (rarely publicly disclosed and usually a quarter stale), reconcile naming conventions across PDFs and factsheets, locate twenty metric values for each of perhaps a hundred holdings per fund, decompose composite metrics inconsistently reported across firms, estimate values for non-disclosers, normalize units across reporting standards and fiscal calendars, and preserve a regulator-defensible audit trail through every step. That’s 2,000 data points per fund, in a portfolio that may hold dozens, with no governance layer to adjudicate definitions and no way of knowing which holdings were silently skipped because the data wasn’t findable or the page wasn’t fetchable.

The task is structurally impossible for a model working from web access alone. Thus, the specialized MCP acts as the “power-up” that endows the general reasoner with domain-specific command, in this case, of the verified fund holdings, mandate criteria, regulatory context, and methodology-encoded data the workflow requires. 

This is just the primitive first step toward truly transformational value. Because this work now runs inside of a powerful application layer replete with potential connections (schedules, inboxes, CRMs, calendars, etc.), it can be integrated into a truly end-to-end automated workflow. A scheduled task in Claude can run the same check each weekday morning, flag and substantiate relevant changes, draft a summary according to your voice guidelines, align the alert visuals with your firm’s design style, and send it to the portfolio manager’s inbox by 9 am.

That workflow, which previously required dedicated tooling or significant manual effort, is configurable in under thirty minutes. That is what the agent layer, the marriage of an LLM, MCPs, and skills, makes possible.

Anatomy of an agent workflow: The four primitives

The workflow described above decomposes into four primitives. Each does one job. In isolation, none of them is sufficient; composition is what makes them work. Below are those elements as applied to a mandate monitoring workflow. Each primitive is paired with something concrete you can try yourself.

Claude, the LLM, is the reasoning engine. It interprets the prompt, decides which tools to call, sequences them, reads the results, and drafts the output. The user does not need to specify any of this in advance.

MCPs handle access. For example, a database MCP retrieves the portfolio and fund holdings, associated extra-financial data and methodologies, and runs the compliance check. A Gmail or Outlook connector delivers the alert. Tools govern which systems the LLM can access.

Skills govern how the system should execute the work. They guide the LLM to replicably undertake a task according to a specific set of criteria rather than ad hoc every time. In an example in which Claude is provided with both an email-drafting skill and a report-formatting skill, the former encodes the firm’s preferred voice; the latter encodes how the firm communicates analysis, like the structure of an investment committee memo, the order in which risks are surfaced, and the way recommendations are presented. Skills allow LLMs to actually execute on firms’ institutional ways of working.

Scheduling is the trigger. It shifts the workflow from reactive (you ask) to proactive (the system acts according to your established cadence). Without it, the generation of this example’s briefing sits inert, waiting for someone to remember.

The output below is what those primitives generate when unified by a user: a branded compliance briefing in the portfolio manager’s inbox by 9 am, written in the firm’s voice, formatted to its standards, using verified holdings, mandate, and extra-financial data sourced from the MCP-connected system, without anyone having initiated it.

Taken in isolation, each primitive is limited, but in connection, they compound. If you strip out the schedule, the analyst still has to remember to trigger the workflow. Without the skills, the briefing is generic, unactionable, and stochastic. Discard the MCP, and the data is either entirely unavailable or completely unreliable.

Why data quality is the real constraint in AI-powered workflows

MCPs are not magic. The quality of the output they produce is a direct reflection of the quality of the data on the other end. In the workflow example detailed above, what counts is the quality of the extra-financial and holdings data. If that data is suspect, the entire workflow is worthless.

Each necessary element of data quality represents its own discipline:

• Data coverage requires enormous computational power and primary research operations, along with machine learning prowess for estimations.
• Freshness demands continuous dedicated data operations covering ingestion, validation, and refresh cycles across thousands of sources.
• Methodological rigor requires regulatory monitoring, deep domain expertise, and disciplined versioning across thousands of metrics.
• Auditability requires infrastructure that preserves provenance through every transformation, so that any figure can be traced back to its source.

These disciplines do not fall out of a more capable model. Rather, they are developed slowly and deliberately, with the kind of expertise that does not compress into a context window. The implication is structural. As models commoditize reasoning, the moat shifts to the substrate: the data.

Beyond architecture: Four questions to ask any AI vendor

The architecture in this article is convergent. Every serious vendor will offer some version of it within the next few years. The questions worth carrying into vendor conversations should, therefore, focus on what supports that architecture.

Follow us on LinkedIn or subscribe to our newsletter to receive Clarity AI insights.