Finch automates operational work for law firms: work that rarely looks like a clean API workflow or single task in a benchmark for agents. It spans a lot of task modalities and workflow types: document drafting, data syncing with external parties, emails, faxes, phone calls, web portals, and human review queues.
The hard part is not building one agent for one task, but supporting a large surface area of tasks where every task has variations:
- A medical records request might go by fax, email, portal, or mail and the best follow-up strategy might vary by what state the provider is in or what type of provider it is.
- A claims task might depend on what carrier is involved, what documents are available, whether a claim is already open, and whether the next step should be handled by Voice AI or escalated to a team member.
- A case risk assessment might change based on firm policy, jurisdiction, treatment pattern, liability facts, coverage limits, and evidence quality.
We built AgentFlows for that environment. The goal was to create an engine for high-cardinality legal operations where agents, humans, tools, deterministic systems, and monitoring loops can work together without every new variant becoming a bespoke engineering project.
Core Thesis
AgentFlow is a composable framework for human-agent blended workforces, and was designed around three product goals:
- We needed to support many task types and many variations within each task. That meant workflows had to be assembled from reusable capabilities rather than written as one-off scripts.
- We needed non-technical operators to have leverage. Operators should be able to review, approve, edit, reject, escalate, and guide agent work without asking engineering to fork a workflow.
- We needed auditability. Every meaningful agent step should produce traces, typed outputs, artifacts, and outcomes that can be inspected later.
This is critical for two things: impact measurement and hill-climbing. If a prompt, tool, model, schema, or policy changes, we should be able to compare the result against structured outcomes and human feedback. Longer term, this is the substrate for optimization efforts through automated harness evolution and post-training.
Why High Cardinality Matters
Legal operations are full of edge cases. A workflow that looks like one task in the product often contains many subtypes in practice.
Records requests are a good example of this type of variance: we may need to submit a request through a specific method, use specific forms, or send multiple requests to entities contracted to a specific provider. The shape of the work changes based on provider, firm, document state, task state, and prior correspondence.
Claims opening has a different kind of variation - the next action depends on context. The agent may need to open a claim according to carrier-specific pre-requisites, confirm an existing claim, read matter files, escalate to a human, draft an LOR, or ask for human review of a file before proceeding.
Overtreatment risk is a risk engine rather than a task-completion agent. It combines deterministic scoring, policy packages, LLM synthesis, and deterministic finalization. Firm policy and evidence quality change the final recommendation.
These examples pushed us toward the same conclusion: the framework needed to support variation as a first-class design constraint.
Technical Architecture
At the implementation level, AgentFlow is a thin agent-specific layer on top of Temporal. Temporal owns durable execution, retries, signals, waits, child workflows, and replay. AgentFlow adds the conventions that make those primitives useful for high-cardinality agent work. The root unit is an AgentFlow workflow. It is the durable controller for a business process. It decides which blocks or activities run, how typed outputs move from one step to the next, when to wait, when to ask a human, and when to write the final artifact or task update.
Blocks are reusable workflow capabilities. Some blocks run LLM subagents. Some wait for external events. Some send faxes, emails, calls, or task updates. Some collect human approval. Some wrap deterministic scoring or finalization stages. The important point is that a block has a contract. It accepts typed input, returns typed output, and emits enough trace data to be audited later. Tools and activities sit behind those blocks. They handle side effects such as database reads and writes, file access, correspondence, phone calls, web research, or integrations with external systems. Keeping side effects behind activities lets the workflow remain durable and replay-safe while still giving agents access to the real world.
External events come back through routing infrastructure. Webhooks, task events, and human approvals can wake waiting blocks through matter-scoped signals and subscriptions. This lets a workflow pause for real-world work without becoming a polling loop or a long ad hoc script. Agents and tools can also dynamically subscribe to events using the subscription system, allowing for dynamic agents that can send a request to the outside world and then trigger the next action based on the outcome in the future.
On the output side, AgentFlow writes structured artifacts, decisions, task updates, run projections, step traces, and snapshots. Those outputs feed operator surfaces and monitoring systems. For example, the claims panopticon agent monitors aggregate behavior, scheduled jobs can identify recurring issues, and issues PRs to target any gaps in the system.
Design Pillar: Composability for Task Variety
AgentFlow workflows are composed from reusable blocks, triggers, and subagents. A block can represent a sub-agent call, a file read, a wait, a human approval, a phone call, a fax, a task update, a scoring stage, or a finalization step. Blocks can either be bound as tools to an agent or deterministically trigger for static workflows. Workflows can be assembled from atomic capabilities that are already observable, typed, and production-ready, which provides engineering leverage: when we improve a file-reading block, approval block, call block, or LLM tool interface, every workflow that uses that capability benefits. Engineering effort moves from building one-off workflow code to improving shared primitives - composability also helps with product variation. An agent for a new task type can be quickly spun up by reusing existing capabilities, while a firm-specific variation can often be expressed through config, prompts, policy packages, schemas, or block composition instead of a new workflow from scratch.
Design Pillar: Human-Agent Blended Workforce
AgentFlow treats humans as part of the execution model, not as an exception path: a key product thesis we have as a company. Agents can research, draft, classify, call, wait, prepare decisions, and escalate. Humans can review, approve, correct, reject, or provide missing judgment. This allows our people to focus on what they do best: deep domain-specific judgement and human-human communication, whether that is guiding a client through treatment over the phone or convincing an adjuster to provide coverage documentation ASAP.
Design Pillar: Auditability and Hill Climbing
AgentFlow makes agent behavior inspectable: every meaningful step can produce typed inputs, typed outputs, traces, tool calls, artifacts, and final outcomes. This matters because production agent failures are rarely explained by a single global metric. We need to know whether the failure came from retrieval, routing, tool behavior, model output, schema design, policy, or human handoff. Human handoff also gives critical quality signals: as our paralegals provide feedback by editing a package, rejecting an output, approving a draft, or submitting something as-is, their judgement becomes proprietary workflow data for Finch's agents to optimize on.
AgentFlow Examples
Among other things, we wanted to highlight three different patterns AgentFlows currently supports: specialist pipelines, autonomous drivers, and hybrid decision engines.
Records Requests: A Collection of Specialist Subagents
Records Request is the cleanest example of the specialist pipeline pattern. The workflow decomposes package preparation into subagents grouped into lanes: contact routing, package assembly, field resolution, compile, and review. Each produces a consistent typed handoff for the next subagent.
Subagents complete work in a set sequence which makes the workflow easier to reason about, test, audit, and optimize. We further group these subagents into lanes as they depend on different entities (e.g. contact routing depends on our provider ontology) - and can also version or swap different subagents in a given lane based on performance evaluations. Finally, an adversarial review agent is capable of classifying failure modes by the subagent that produced it - giving us a practical way to improve performance for the subagent at fault.
Claims Opening as an Autonomous Driver
The case setup agent (code-named Crash Out) shows a different agent pattern: instead of decomposing the work into many specialist lanes, Crash Out uses one LLM driver that works through claim opening and LOR drafting tasks, replacing an entire slice of paralegal work. The prompt acts like a standard operating procedure -- it defines the allowed scope, phase order, prerequisites, source priority, escalation rules, and safety constraints. The prompt and configuration are controlled directly by the operations team, de-coupling business logic changes from engineering efforts.
The agent can read files, inspect coverage, store claim-opening context, call a carrier through Voice AI (and it can add call instructions based on context), escalate to BPO, audit claim or LOR actions, wait, send Slack updates, ask for human review, and finish. The LLM decides what to do next, but only through constrained tools, and uses a self-check subagent to introspect as it makes decisions. This pattern is useful when the next action depends heavily on messy context, and is critical since Crash Out marks off tasks fully autonomously, meaning it needs very strong guards. We also include driver telemetry, latest-tool status, human escalation, and review state so the autonomous loop remains visible to operators and engineers.
MoBrain as a Decision Engine for Treatment
Our overtreatment risk agent, MoBrain (named after Mo, our treatment wizard) shows that AgentFlow is not only for agents that complete tasks. It can also support auditable decision engines.
MoBrain evaluates overtreatment risk for personal-injury matters. The architecture is staged:
- Stage A performs deterministic scoring and rule evaluation.
- Stage B uses an LLM for bounded synthesis over evidence and context.
- Stage C deterministically finalizes the score, tier, recommendation, confidence, and snapshot.
This pattern is useful because it separates deterministic policy from LLM judgment. The LLM does not own the whole decision. It contributes a bounded synthesis stage inside a larger scoring engine.
That makes MoBrain customizable and auditable. Policy packages can evolve. Snapshots preserve risk outputs, policy versions, and confidence. Recommendations can be reviewed over time. The system can improve without becoming an opaque model-only decision.
Evaluation and Optimization Loop
As AgentFlows run, they persist traces, artifacts, snapshots, and human outcomes. A subsequent layer of evaluation agents and dashboards consume the execution trajectories and slice performance by workflow, variant, firm, task type, lane, stage, model, tool, policy, and failure modes. Finch's software engineering agents are then able to propose updates to prompts, schemas, tool sets, blocks, retrieval bundles, policy packages, or even model configurations. Regularly scheduled jobs read eval data, summarize emerging issues, group examples, and propose targeted work and PRs.
Some examples:
- If Crash Out repeatedly escalates after a specific carrier phone pattern, a job can surface the carrier-specific failure mode and propose tool or prompt updates.
- If MoBrain recommendations are frequently downvoted for a policy package version, a job can collect snapshots and suggest policy or Stage B prompt revisions.
- If a tool starts failing across workflows, a job can connect the operational failure to the shared block or tool implementation.
The team sees investing in observability as a path to compounding improvement: production runs become issue discovery, issue discovery becomes targeted PRs, and targeted PRs improve reusable blocks, prompts, tools, schemas, or policies for every workflow that depends on them.
Impact
AgentFlow reduced the cost of creating new agent workflows because teams could reuse blocks, tools, approval gates, tracing patterns, and monitoring surfaces. As a result, agents at Finch have crossed a critical barrier in the last few months: they have multiplied the productivity of our human operators at an unprecedented pace as we scale AI-native legal workflows. One unique thing about Finch is that every engineer co-leads one or more product verticals and is responsible for working with operations to multiply the output of their teams. These teams work towards work quality and throughput each and every week, creating a unique environment where engineers don't just theorize about impact, they live and breathe it every day, week, and month.
If that sounds like somewhere you would thrive, check out our careers page.