Configuring AI Agents for Context: Don’t “Set It and Forget It”

Configuring an AI agent is a calibration problem between agentic behavior and the outcomes you need. It’s not a “set it and forget it” process. This is especially true in investment management (IM) operations, where operating context changes continuously. The AI agent has to have just enough context to capture intent without overloading it or risking hallucination. We’ve seen both extremes become stumbling blocks for clients.

Pragmatic approaches exist, and they tend to cluster around six common patterns.

1. The calibration conundrum and “Goldilocks problem”

Configuring an AI agent is a calibration problem between agentic behavior and the outcomes you need. The remedy is measured context. This “Goldilocks” scenario means accepting trials and tweaks to get it “just right.” Too much context degrades the model’s output and invites hallucination as agents struggle to predict what to do next. Too little makes them brittle, able to handle only a narrow slice of a workflow in the context of a particular instrument type or situation. Your way through is to have clarity about the danger of the two extremes and the effort it takes to avoid them.

2. Context must include intent

The context an AI agent needs goes beyond trade execution details recorded in your core systems. It also has to include the intent behind an event. Understanding what a client or counterparty meant to do often takes referring to the communications around it. Both are needed, which calls for bringing in emails or other communication trails to complete the context.

For example, an analyst matching cash, position, or total-return swap activity with a counterparty would find trade economics of a given security on the platform. But the emails between the counterparty and the client describe what the trade and the position are actually meant to be. When reconciliations or breaks arise, an agent should also be able to read the communication around that specific break and work out the agreed state.

Sometimes intent also sits inside the system as specific configurations. An offering memorandum’s fees by share class, its carry, and its performance terms would already be captured in investor-allocation configurations. Treasury terms, the Standard Initial Margin Model (SIMM) margin and house margin in a PB or ISDA agreement would be captured through margin replication. An agent would need to understand the decisions made when the offering was pulled into the system instead of rereading the whole agreement each time.

Then the gaps emerge where the terms aren’t configured yet. For a more detailed review, you would also expect an agent to help you parse the agreements and pull the relevant terms to answer a specific but unexpected query.

3. Put the generic on autopilot while intervening for uniqueness

Agents are durable when they can be used in multiple scenarios. They use the model’s native command of asset classes and add bespoke context only where your data sources run out. Configuring an agent per asset class is a mistake because they choke on the first unexpected lifecycle event. You might see this, for example, when a bond converts to equity in a restructuring or bankruptcy. Other issues could arise in the economics of buckets, including fund and security types, realized and unrealized gains, price and FX returns, and income and expense lines.

For structured and OTC products, teams should expect to intervene in atypical situations rather than rely on an agent for every possibility. What we want to avoid is having our clients fall into the rabbit hole of creating multiple agents that work only for very specific types of instruments or particular situations. We want to give agents some headroom.

4. Organization of context to facilitate reliability

One major distinction is between ingestion and display. Trying to have an agent cover the entire lifecycle of a data point will cause overload.

It helps to provide context about how the data enters and leaves, and in what order, so that agents know when to do what. Adding timestamps to that lineage reduces the likelihood of errors or friction.

Presentation decisions are another layer: whether output arrives as a formatted document, a table, or a spreadsheet, and how to render figures and prices. And a third agent might have the context to address product-help questions by retrieving them from the firm’s own documentation instead of carrying it all in-line.

5. Context evolves, and agents must keep pace

Establishing context once is not enough. It’s not a “set it and forget it” process because operating context changes continuously. An agent stays correct only when the system tracks how terms and records change over time and lets the agent reproduce the state that was true at a given moment. This is why context is more of an evolving aspect of agentic design.

After capturing what’s happening around transactions in the real world, this information needs to be made available to AI agents. Context ages from the moment it’s captured. For example, a “staleness failure” could occur if information about a renegotiated margin agreement with a counterparty isn’t taken into account, and an agent continues to compute against outdated configurations. You can prevent staleness issues with effective dating and a bitemporal record. If every change to a term carries the date it took effect, an agent can traverse the terms that were in force at a point in time and apply the right ones from that date forward.

The same is needed from the other direction, such as at the month-end close. Books are finalized against one version of the records. Often, an immaterial change will land afterward as a prior-period item, and rerunning the P&L and trial balance against the latest data produces a delta due to timing differences relative to the cutoff. An accountant investigating a cost or P&L rollover has to see that delta cleanly, which means an agent has to reproduce the version that closed the month rather than recomputing against today.

6. Building for context today and tomorrow

AI agents are not mind readers. The context that matters most sits at the front and back of the AI agent’s run. First, an agent has to be able to interpret the user’s natural-language request before any work begins. Confirming that the interpretation is correct is an important moment for having the human in the loop.

In the middle of the process, however, probabilistic output is too risky. Instead, agents need a deterministic core in the middle that handles specific queries and computations. Then the behavior becomes dynamic again to summarize and draw a conclusion.