What Arca's Stop-Start Financial Agent Workflows Reveal About Agent Design

Some of Arca's agent tasks can take up to ten days. They are stop-start, with multiple actors, decision points, and handoffs, according to Aman Singh, the company's lead AI engineer ¹. That changes the engineering problem. A system supporting this work needs to preserve state and respect decision boundaries across pauses and handoffs, not just produce a useful answer in one session.

Arca, which provides wealth-management services, describes an architecture built around persistent memory, a custom harness, and human advisors who make final decisions ¹. This is a useful design case, not proof that long-running AI agents are reliable or ready for consequential financial work. The account does not explain how memory accuracy is maintained or how workflows recover from interruptions, and it does not provide task-level reliability results ¹.

Why multi-day agent workflows need a different design

A short request-response task ends when the answer arrives. A task that pauses, changes hands, and resumes later needs to carry its state forward: what happened, what's left, who owns each action, and which decisions still need a human. Arca describes tasks that can take up to ten days and involve multiple actors, decision points, and handoffs ¹.

That shape creates failure modes a fluent answer can hide. A model could generate a reasonable-looking proposal from outdated information. A tool could complete an action whose result never gets recorded. A new person could pick up a task without knowing which decisions are still pending. These are risks implied by the workflow, not failures reported by Arca.

So the design question isn't only whether the model answers well. It's whether the surrounding system keeps a trustworthy account of the work across pauses and handoffs. Arca's account describes aspects of its architecture and operating boundaries, but does not report task-level reliability or establish readiness for consequential financial work ¹. Teams weighing similar designs may also find what Spawn teaches technical leaders about autonomous agent teams a useful comparison point.

Persistent memory for AI agents: what it should hold, and never silently change

Arca's internal memory system tracks what has happened for each client, upcoming work, near- and long-term actions, and who's responsible for each action. Agents contribute to that memory ¹. That is more than a transcript store. One architectural reading is that the useful unit is structured work state, including ownership and pending actions; the account does not provide a detailed specification.

The account doesn't say how memory is created, corrected, or checked when multiple contributors add to it ¹. Those are diligence questions, not assumptions to wave through. Anyone evaluating a system like this should ask what evidence backs each important memory item, how updates get attributed, and what happens when sources disagree.

Trade-off: Treat memory as a working record, not a source of truth. For every consequential item, log its origin, separate observed facts from proposed actions, and surface stale or conflicting state before the agent acts on it. If an agent can't tell whether an instruction is current, escalating to a person is safer than guessing which version to trust.

What an AI agent harness actually controls

Arca uses models from Anthropic and OpenAI, with Claude as its primary model provider. Its custom harness automatically selects a model for a task based on internal benchmarks. Arca says owning the harness gives it flexibility to change model providers ¹.

That flexibility may also mean Arca is responsible for integration, evaluation, and failure handling around its model choices; that is an architectural inference, not a detail established by the account. The source does not define the benchmarks or report their results ¹. Companies that route work across providers through a model catalog or an enterprise AI gateway face a version of the same question: who owns evaluation and failure handling once the model can change?

The diligence question worth asking is what the harness governs beyond model choice. Does it control tool access, preserve task state, log traces, route approvals, or manage recovery? These are open areas to investigate, not capabilities established by the account.

Trade-off: A benchmark measuring answer quality may not predict performance on work spanning days, memory updates, tool calls, handoffs, or the need to refuse an unsafe action. Ask for evaluations that exercise the whole workflow, not just the model's output, and whether changing a model triggers regression tests against the actual tasks the system runs.

How risk boundaries get enforced in financial services AI agents

At Arca, agents do much of the background work, including analysis and proposing solutions, while human advisors make final decisions. Trading and other money movement are handled by human advisors ¹. Singh says Arca's safety restrictions are deterministic and remove decision-making from the agent for certain actions. Agents can execute some tasks themselves, but not ones that involve risk to clients ¹.

That distinction matters, but a stated policy isn't the same as a tested enforcement boundary. Worth checking: does a prohibited action remain unavailable when a prompt conflicts with policy, when context is stale, or when a tool returns something unexpected? These are tests to run, not results Arca has reported. For a broader view of how stated behavior becomes enforceable rules, see OpenAI's updated Model Spec and company controls.

A concrete action matrix helps make the boundary real:

• Which tasks can the agent perform without approval?
• Which actions require approval, and what evidence does the approver actually see?
• What happens if approval is delayed, rejected, or overtaken by a change in the client's situation?

Without answers to those questions, it's hard to tell whether a system is proposing an action, preparing one, or capable of carrying it out on its own.

What to test when a long-running AI agent resumes after an interruption

Pauses and handoffs make recovery part of the design, not an edge case. Arca describes stop-start tasks involving multiple actors and handoffs, but the account doesn't say how its agents resume after a failed step or a conflicting update ¹.

Scenarios worth testing directly: a tool succeeds but its result never gets recorded; two contributors update the same action; a client's circumstances change during a pause; an approval arrives after the proposal it covers is obsolete; or the model provider changes mid-execution. These are not incidents Arca has reported. They are risks a multi-day workflow should be tested against.

Trade-off: A resume model worth trusting needs durable task state, clearly owned actions, versioned updates, and safe retry handling. Before continuing, the system should show what it believes has happened and flag anything uncertain or conflicting. Measure recovery separately from answer quality: did the task resume at the right step, avoid duplicate actions, surface conflicts, and route uncertain cases to a person? The source supplies no such measurements for Arca ¹.

Does translating agent code make tool use safe?

For agent-written code that accesses company data, Arca translates the code into a strict expected format, discards the original code, and applies guardrails to the translated format before it reaches the backend ¹. The design rationale is to constrain the interface between generated code and a sensitive backend so the backend accepts a narrower shape of request.

That design choice doesn't by itself prove the translation or guardrails are correct. Worth asking: how is the format specified, do unsupported requests fail closed, how is access scope checked, and are accepted and rejected requests tested? The account doesn't say.

Arca also runs checks for known AI security issues, including prompt injection. Its agent itself isn't sandboxed, though Arca uses sandboxes for computation ¹. That's a boundary worth examining, not evidence that the overall design is secure.

What evidence should a finance team demand before delegating more

Arca says it uses human-advisor feedback and agent traces to improve its harness, with a meta-agent analyzing that material and suggesting changes ¹. That describes a process; the source does not say how suggestions are reviewed or what outcomes the process produces.

Before expanding what an agent is allowed to do, ask for:

• Task-level error rates and performance on workflows lasting several days.
• Recovery behavior under interruptions, tool failures, conflicting updates, and changed circumstances.
• Memory-correction mechanics, benchmark definitions, and the basis for model selection.
• Approval records and tests covering unauthorized actions, prompt injection, and rejected approvals.
• Trace review showing inputs, memory state, model choice, tool calls, approvals, outputs, and final disposition.

These are buyer diligence requests, not evidence Arca has published. Treat a meta-agent's suggestions as inputs to engineering review, not an independent safety check. Require human sign-off on harness changes, a record of what changed, and regression tests before anything ships.

Trade-off: Start with analysis and proposals, and keep client-risk decisions with accountable people. Expand an agent's authority only when measured evidence covers the specific workflow and failure modes in question. Arca's reported split between agent analysis and human final decisions is a starting boundary, not a guarantee that transfers to another firm's workflow ¹.

Questions teams should be able to answer

What is a long-running AI agent workflow?

Work that may span pauses, actors, decision points, and handoffs rather than finish in one session. Arca says some tasks can take up to ten days, though it describes the work as stop-start rather than continuously running ¹.

How does Arca use persistent memory for AI agents?

Its internal system tracks what has happened for each client, upcoming work, near- and long-term actions, and who is responsible for each action. Agents contribute to that memory ¹. The account doesn't explain how accuracy or conflicting updates are handled.

What is an AI agent harness?

In Arca's case, a custom layer that selects a model for each task based on internal benchmarks. Arca says owning it gives the company flexibility to change model providers ¹. The source doesn't detail every control it implements or report benchmark results.

Can Arca's agents make financial decisions or move money autonomously?

Arca says human advisors make final decisions, and trading and other money movement are handled by human advisors. Agents are limited to analysis and proposing solutions; the account says tasks involving client risk are not executed autonomously ¹.

What should companies test before deploying multi-day financial agents?

Recovery after interruption, memory accuracy, conflicting updates, prompt injection, tool failures, approval boundaries, unauthorized actions, and task-level reliability. Arca's account describes architecture and an improvement process but does not publish results for these tests ¹.

Source

¹ “Agents Prompt People: Using Agents for Long-Horizon Financial Work,” Latent Space, Oct. 31, 2026. https://latent.space/p/arca/