Introduction
Our goal at Pace is to build a multimodal agent that can work seamlessly across all insurance tasks.
The ideal interface is a single agent that can talk, read, reason, use software, and take action across long-running workflows. We’ve seen early demos of language models that show these capabilities natively, but at Pace, we’ve been in production with these capabilities for insurance companies for months.
Consider an common workflow: processing a claim on a phone call. This often requires coordinating several specialized agents. A voice agent needs to handle the primary interaction, a general agent needs to hit the right APIs to pull the policy information, and a computer use agent needs to fill out the form for the claim. The voice agent then needs to give the user a confirmation number from the form submission.
Different Agents, Different Constraints
Each agent operates under different constraints. The voice agent needs to respond within a couple hundred milliseconds - and because it needs to be a lower latency model, is not smart enough to perform more complex tasks like navigating websites or diving deep into Excel files. The general and computer-use agents can take more time and run on stronger models, because nobody is waiting on a live call for them to finish.
The workflow may also not end when the claim is filed. We could have to follow up with the customer about missing information in a week or even months later. To support this, we need to preserve the relevant state and traces so the work can pick up where we left off.
The Context Problem
What we’ve found is that these insurance workflows can require a lot of context, often encompassing hundreds of pages of SOPs and files of data. But, agents perform best when their context is as small as possible and they have less to consider. LLMs have advanced to the point where a generic shell based agent can perform many workflows, but they’re often rediscovering information from scratch and loading way too much information at each step, requiring multiple turns of compaction and re-orientation. This balloons cost and latency beyond workable levels.
To enable complex workflows, but within acceptable latency SLAs, context management and minimization has become the core principle behind how we’ve built our harness. The techniques below have helped us support difficult, long-running workflows for customers while also giving us a solid engineering foundation to build on.
1. Agentic Operating Procedures
Each agent’s goal is defined in a mostly-natural language Agentic Operating Procedure, or AOP. An AOP bundles together everything needed to do a job: the task definition itself, plus the tools, skills, secrets, and files required to carry it out.
2. Orchestrator agent
When a specific AOP is triggered by an email, phone call, API request, SMS, or another event, we create an orchestrator agent. The orchestrator is responsible for either doing the work directly or coordinating subagents as necessary.
The orchestrator understands which subagents to spawn, when to spawn them, and what configuration to use for each one. Depending on the task, it can choose different levels of reasoning effort, model quality, latency, and tool access to optimize for accuracy, speed, and cost.
3. Subagents
The orchestrator can call predefined or custom subagents that manage their own context. We’ve built a set of predefined subagents for our most common requirements: document extraction, voice calls, and computer use.
These agents can operate in parallel and communicate with each other when necessary. Each one has a focused set of tools and skills for its specific job. This is especially important for document extraction and computer use, where customer-specific file formats, portal layouts, and workflows can benefit a lot from custom tooling. Keeping each subagent focused lets us improve accuracy and latency while avoiding unnecessary context bloat.
4. Shared context
All agents and subagents need to work with the same state. At any point, one agent may produce a piece of information that another agent needs. For example, the computer-use agent may receive a confirmation number from a claims portal, which then needs to be sent back to the voice agent to be spoken to the user. A week later, when the orchestrator sends a follow-up email, it may need that same confirmation number again.
We use a sandbox for each orchestrator agent as the shared working memory for the task. Documents, transcripts, extracted fields, intermediate artifacts, confirmation numbers, and workflow state are written to consistent locations so each agent can fetch only the context it needs.
5. Pre-computation
Coding agents can generate the scripts and artifacts they need, but they often spend a lot of time reshaping data into the format they want. We continually scan for what agents naturally look for and pre-compute those artifacts so they are already available in a natural location and shape.
For example, PDFs and some Excel files are automatically OCR’d as soon as they are put into the sandbox, so the agent does not have to spend tokens deciding whether to OCR them, writing code to do it, or parsing the output from scratch. Customer conversations, including emails, SMS messages, and voice-agent transcripts, are also synced to the sandbox in real time so every subagent is working from the same source of truth. Each of these techniques is the same instinct applied in a different place: give every agent the most useful slice of context, and put it exactly where the agent will look.
What this comes down to
As models improve, the level of scaffolding and prompt engineering will come down. What’s left is the harness: how context is partitioned, persisted, and pre-computed so each agent works from the smallest useful slice of state. That comes from the techniques above, and from enough time in insurance operations to know which problems are worth solving.
What’s next?
While a task can require all this careful orchestration, it can be a lot to manage for an end user who is mostly focused on getting the job done. The goal is that none of this should be the user’s problem: they should be able to describe the work they want done and trust the system to decide how to execute it. This is the direction we are building toward.
In upcoming posts, we’ll go deeper on:
CUA
Guardrails
Self-improvement