Summary
A single orchestration layer lets one analyst direct dozens of subagents through work previously handled one line at a time. The orchestrator factors the task, judges what comes back, and routes the exceptions to a person who reviews and owns every write operation. For investment operations, that’s the design pattern that holds up now.
Working at an operations desk used to have a certain rhythm to it. At the end of a trading day, you’d find an analyst grinding through a report of reconciliation breaks, one line at a time. Someone else would be working through end-of-day P&L anomalies or chasing down end-of-period reporting gaps. That pacing changed with the introduction of copilot-like AI tools. These tools help an analyst get answers faster, but their work still moves down a list, one item after another.
The next evolution of AI is the ability to delegate pieces of the entire list at once. AI agents give analysts many pairs of hands working in parallel instead of a single faster pair. But like the players in an orchestra, those agents need “someone” at the center keeping time. The pace of raw machine outputs would come too quickly for a human to manage. So, the more successful model is a conductor that orchestrates the activity of all of the subagents.
We’ve found the best pattern for doing this in investment operations is to have a single orchestrator sit over one layer of agents. Agents shouldn’t talk to each other or negotiate among themselves; however, they can still call the tools to do their own jobs.
In this model, an orchestrator takes a request in plain language, such as a fund’s worth of breaks to clear before the book closes and works out how to factor it across the agents that can do the work. The orchestrator might tap into dozens of these agents, each specialized in a particular task. It knows each agent through a declared set of skills: a plain description of what that agent can do that any capable model can read, keeping the design independent of any single model vendor. When the volume climbs, the orchestrator can spin up as many copies of the relevant agents as the work needs.
After all these subagents have done their jobs, they hand the results back to the orchestration layer. Currently, none of them pass work sideways to a peer. The metaphor of an orchestra makes sense because you want the musicians to follow the conductor if you want the performance to come together.
We’ve also noticed that a lot of the current agentic AI discussion runs ahead of this, toward chains of agents that negotiate and coordinate among themselves. That approach may prove out in other settings. But in investment operations, a confident wrong answer becomes a misstated book. To manage operational risk, as well as investor or regulatory risk, a single layer is the right design for the moment. This design pattern may evolve as agents get better at balancing deterministic and probabilistic tasks.
Orchestration layers need to be designed, and agents need to be factored to make the best use of commonalities between certain tasks. For example, daily P&L anomalies have to be explained before you sign off on the numbers. The orchestrator batches those anomalies by factors such as prime broker, asset class, trading venue, or pricing source. Each batch goes to one agent built for that kind of work, and where a group holds many line items, the orchestrator runs that agent in parallel across them.
Scope discipline is the hard part. If you give an agent too wide a definition, it becomes more likely to hallucinate. You might have different trading terms across multiple brokers. A single task that spans them all hands the agent too many conflicting rules to hold at once. So does a task that can only be resolved by reading the underlying deal documents or all limited partner agreements. It’s too easy for the agent to try to make probable inferences from the overall document base and miss context.
Getting the grouping right means that each agent works on a clean, bounded problem that it can actually finish. Knowing where that line sits takes deep familiarity with the instruments and the workflows, the kind of domain context that comes from the vendor and lives in the system of record. That context is what lets the orchestrator maintain an accurate picture of how to factor and delegate the task, and then how to interpret what comes back.
A well-designed orchestrator doesn’t pass agent output straight to the user. It gathers everything the agents return and runs a validation pass over it, built from confidence thresholds, rules, and worked examples of what good and bad answers look like. That validation pass, which we call a judge, sits inside the orchestrator itself. It sorts what comes back based on how much the orchestrator can trust it. Orchestrator triage looks like this at a high level.
Having gradations of outcomes and behaviors is essential. And every category should be transparent for the end user to review, even results that are deemed confident. When an API or a database won’t answer, you want the orchestrator to wait and retry rather than giving up on the first miss or accepting a probabilistic guess. It should be able to catch an obvious mistake like a wrong ticker symbol or currency and send it back to be redone. Hallucinations are the hardest case, because they’re plausible but wrong. You can’t let errors like that get into your P&L, NAV, investor reports, regulatory filings, etc. Questionable items go back to the analyst for further review.
When the person at a desk stops clearing items one by one and starts directing the work, capacity flexes to the day’s work instead of scrambling for headcount. When a particular venue or data source throws off a wave of pricing mismatches, or the workload intensifies, your resources expand to match the size of that wave. You don’t miss reliable end-of-day P&L just because you’re also covering quarter-end reporting.
The analyst’s role changes, too. A long agentic task can fail quietly, so it needs to leave a clear trail of what it did and why. When an orchestrator flags something as failed, the trail lets the analyst diagnose the problem in seconds. Without the trail, the agent must be rerun interactively until the error occurs. That visibility allows the analyst to jump in and redirect the tasks.
In addition, agents and their orchestrator should not be able to write data to the live system. The orchestrator proposes, while the analyst reviews and commits any writes. That’s the place where the human belongs in the loop.
For now, the more complex layering of orchestrators on top of orchestrators is premature. Adding second- and third-order inferences to the output of the underlying subagents compromises observability and traceability. But in some sense, cross-orchestration is already running between firms. When one of your agents asks the vendor for a price, it reaches an orchestration layer on the vendor’s side that goes off, does its own work, and returns the answer. Your single layer is already calling someone else’s.
Multiple orchestration layers are possible for the future. Getting there means replicating the same disciplines that you use for scoping and factoring in today’s two-level pattern. There’s also a clear role for judging every output and a strong case for writer permissions to make an orchestrator-of-orchestrators safe to build. Working through that thought process now in a way that connects to the real-world context of your data and portfolios puts you in the best position to add more sophistication as LLM technology matures.
Vivek Viswanathan
Vivek is a Senior Vice President and Distinguished Engineer at Arcesium. A technology evangelist and researcher, Vivek works to build frameworks and solutions that make the most out of a firm’s resources. He was awarded top Quora Writer in Software Engineering & Computer Programs in 2020.
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.
