Arca shows how AI agents sustain financial decisions for up to ten days

Long horizon is not the same as continuous execution

At Arca, an AI-native wealth management company that raised US$ 48.5 million in a round led by General Catalyst (with participation from Index Ventures and Venrock), the agents don't run in a closed loop for hours. They work in cycles that can last up to ten days, but intermittently: they stop, wait for a human, resume, change owner.

Aman Singh, the company's lead AI engineer, described this pattern in a presentation at the AI Engineer New York event, held in October, and detailed the architecture in a conversation with the Latent Space podcast. The distinction he draws between a long-horizon task and a continuous-execution task matters for anyone designing agents: the challenge isn't keeping a process alive for days, it's rebuilding context after pauses, actor handoffs, and decision points.

It's very stop-start, there's many actors in between, many decision points, many handoffs.

Aman Singh, lead AI engineer at Arca

This framing changes what's worth building. An agent that only holds a long context window within a single session, which most agent frameworks handle well today, doesn't help here. What helps is a memory system that survives the session and the handoffs between owners.

Memory as infrastructure, not as a feature

Arca keeps a per-customer persistence layer, fed by the agents themselves with every interaction. According to Singh, this system answers questions that a regular chat history doesn't:

• What has already happened so far in this customer's case
• What is being tracked for next steps
• What needs to happen in the coming days
• What is tracked long-term
• Which individual, human or agent, is responsible for which action

This is different from traditional RAG, where search retrieves documents relevant to a one-off question. Here memory is a record of state and accountability, closer to a domain-specific financial state machine than to a vector database of embeddings. For anyone building B2B agents with multiple human actors in the loop, this might be the most transferable lesson from the case: spend less time optimizing the prompt and more time designing the data schema that the agent writes to and reads from between runs.

A custom harness to be able to switch models

Arca uses models from frontier labs (Claude, from Anthropic, as its main provider, plus models from OpenAI), but it doesn't depend on a third-party managed harness. The company built its own router, which automatically picks which model to use for each task based on internal benchmarks.

The decision to own the harness, instead of using something off-the-shelf, has a practical reason: freedom to switch model providers without rewriting the orchestration layer. This comes with a maintenance cost, but for a fintech running tasks that are regularly audited, depending on a closed third-party harness would be an extra risk.

Deterministic guardrails: the agent proposes, the human decides

In financial services, security isn't optional. At Arca, the agent's role is limited to analysis and proposing a solution. Any trade execution or movement of money goes through a human advisor.

All of our safety restrictions are fully deterministic. And they take the decision making off the agent's hands.

Aman Singh, lead AI engineer at Arca

In practice, this means there are tools the agent can run on its own and others it never runs, regardless of what the model decides. The cutoff isn't made by prompt instruction, it's made outside the model, in code that leaves no room for the LLM to work around the rule with a poorly calibrated response. The episode cites as an example the case of a decision involving a US$ 100,000 tax matter, which goes through human approval before any execution.

The sandbox trick: discard the code, keep the format

The most interesting part of the design for anyone writing agents that touch sensitive data is how Arca lets the agent query internal data without giving it direct access to the backend. The agent writes code to aggregate and manipulate customer data, but that code never reaches the real database.

As Singh described it, the system translates the code written by the agent into a strict expected format, discards the original code, and only then applies guardrails on top of that format before letting it reach the backend. The agent gets the flexibility to program the query it needs, but what actually runs against the real data is a validated representation, not the arbitrary code the model generated.

In short: it's a financial version of the pattern of not trusting the model's free-form output and validating it against a schema, just applied to code instead of structured text. Arca also runs specific checks against known AI security issues, such as prompt injection, before considering any action safe.

The loop that turns feedback into a better harness

Feedback from the human advisors themselves, combined with the agents' execution traces, feeds a meta-agent that analyzes this data and suggests changes to the harness. It's a pattern of continuous evals: instead of just measuring whether the agent got it right, Arca uses human correction as a signal to evolve the routing layer and the system's own rules.

What this means for those who don't work with client money

Not every agent application needs this level of engineering. Building a custom harness, per-entity persistent memory, and code sandboxing with format translation is expensive in engineering time, and it only pays off when the cost of a mistake is high: someone else's money, regulated data, an irreversible decision.

For internal prototypes or productivity tools, an off-the-shelf agent framework and a well-managed context window solve most cases. Arca's case is worth using as an architecture reference exactly at the point where that limit stops holding: when the agent takes part in a process that lasts days, involves multiple accountable humans, and can't fail in a way the company can't later explain to a regulator.