The missing middle
Most roles are not composed of one narrowly defined task. They’re a mix of responsibilities, and each one needs a different amount of standardisation, analysis and judgement. The tools people use follow from those tasks, so they vary just as much. Highly specialised platforms sit next to spreadsheets, email and chat.
Whether a task earns its own software comes down to simple economics. A task gets a dedicated tool when its volume and standardisation justify the cost of building one. In capital markets operations, affirmations and reconciliations clearly pass that test, making them one of the first areas of focus for Arch (as outlined in our pieces on trade affirmations and reconciliations). They take up a large share of the team’s time, and their structure is predictable enough to design around. They still need flexible software, because no two firms run them the same way. Nonetheless they deserve dedicated products, and AI has now made it possible to collapse the investigation and resolution work that used to resist automation.
At the other end of the spectrum are bespoke, one-off tasks: a question asked once, an analysis for a single meeting. These fall to generic tools like Excel, email and increasingly, general-purpose AI assistants such as Claude or ChatGPT. People experiment here, with varying degrees of AI help, and that’s the right approach. Nothing about the task justifies more.
Between the two sits a large body of work that no one serves well: the missing middle.
- The COO office wants a regular analysis of which processes are most manual, to feed the technology book of work.
- Portfolio managers and traders want answers about their trades and positions without waiting in a support queue.
- Investor relations has to answer due diligence questionnaires that repeat, with small variations, what the firm has said many times before.
- Compliance has to do a first pass over surveillance alerts before anyone can apply real judgement.
Dealing with these tasks requires a combination of data sources and the ability to inject firm-specific conventions. In this case, this might mean pulling data from the OMS, the PMS, affirmation platforms, prime broker and custodian portals, and the mailbox. Further analysis is then required by someone who has an understanding of the idiosyncrasies of the firm. Each query type is too specific, and changes too often, to justify its own application. However, given the volume and relative complexity of these tasks, they can collectively take up a large share of skilled people’s time.
A general-purpose AI assistant doesn’t solve this even when provided with access to the firm’s systems. It has no knowledge of the firm’s conventions, no memory of last week’s edge cases and no audit trail. A dedicated application does solve it, but at a cost that does not justify the ROI. The middle needs domain depth built into the tools without the cost of building a dedicated application for every task.
Our solution: Agent Workspaces
To fill the middle, an agent needs what makes a dedicated application work without the cost of building one:
- configuration deep enough to capture the use case
- tools that reach the firm’s real systems
- skills that are continuously updated over time
- a collaboration layer that enables teams to work together
- governance a regulated firm can sign off on
We have already built all of this in Fulcrum, the platform underneath Arch. Agent Workspaces open that same foundation up to the middle. They follow five design principles.
1. Interactive configuration
Setting up an agent should be quick to start but able to go deep. Fully configuring one might take an hour, and all of that time should go on the substance: describing the use case, running validations and writing down how edge cases should be handled.
The process is self-service and iterative. The user describes the problem and works directly with the agent as it’s being built. They specify output formats, triggers, periodic tasks, which tools to use, which columns matter, and refine each one as they go. Where the work repeats, such as a morning pull of unconfirmed trades or a daily position comparison against the prime broker file, the agent writes a script, collaborating with the user to test and save it. From then on, that step runs deterministically: the same inputs give the same output, reproducibly and auditably, rather than being reasoned out afresh each time. The agent keeps its judgement for the parts of the task that need it.
2. Continual retooling
Complex workflows need the right capabilities. Some are simple, like read access to trade databases or the client’s PMS. Others are more sophisticated, such as coordinating sub-agents along a defined workflow when a query spans several systems and dependent checks.
The capabilities we build for standardised workflows also become building blocks for the middle. An agent answering a trade support query can call the same affirmation and reconciliation capabilities that Arch uses. Actions follow the same principle as the rest of our platform: the agent prepares the action, a human approves it, and code executes it. Every new tool or application we unlock makes every workspace more capable.
3. Continual upskilling
In the research literature, “continual learning” usually means a model updating its own weights at test-time, rather than going through new pre-training. Taking this as a general inspiration, we’ve built a system that captures new edge cases, instructions and patterns, stores them, and recalls them in future work. The underlying model doesn’t change, and client data is never used to train it.
Upskilling builds on the same interactive loop used in configuration. When the agent spots a better way to handle a case, it proposes an improvement. A user reviews it. Approved changes are versioned, so there’s always a record of how the agent behaved on any given day and why. Across a client’s deployment, Locus, our observability platform, aggregates traces to show where inefficiencies cluster, which gives improvement suggestions a firm basis. An enterprise environment never stops changing, and this is the only way an agent stays useful in it.
4. Collaboration
Operations is a team sport, so workspaces are shared. Agents, tasks, chats and outputs can all be shared with colleagues. One analyst configures an agent, and the whole desk uses it. When an edge case is resolved in London, the fix is there for the New York shift. Handovers between the agent and the team happen seamlessly. The knowledge that used to live in one experienced person’s head becomes something the team owns.
5. Guardrails and observability
Agent Workspaces inherit our governance model. Everything runs in the client’s own environment. The only data that leaves it goes to the client’s chosen model provider, under the client’s own agreement and API key. Access runs through the client’s identity provider, and role-based permissions set what each agent can see and do. Our connector suite also enables centralisation of access controls for simplified management by the client. Finally, actions need human approval and are executed deterministically by code rather than by the agent.
Our Locus platform sits alongside, deployed in the client environment. It provides OTel tracing of every step an agent takes, plus debugging and evaluations. Any answer can be traced back to the data and reasoning behind it, and any change to an agent’s configuration or memory can be traced back to who approved it.
The compounding effect
These principles reinforce one another. Dedicated workflows produce building blocks for the middle. Interactive configuration turns tacit knowledge into written procedures. Upskilling and collaboration spread that knowledge across the team. Observability keeps the whole system accountable. Over time, the middle stops being a gap between specialist tools and general ones. It becomes where a firm’s operating knowledge is captured and put to work.
to find out more about how Agent Workspaces can support your operations team.