AI agents on 10-day cases: Arca's records and guardrails

How many hours an agent can keep running is a common yardstick for whether it can take on long work. But long work in a business is often not continuous. You wait for a client to reply, the case moves to another person, and it picks up again days later. The case of Arca, a US wealth manager, describes concretely how to hand this kind of work, short on running time but long from start to finish, to agents. It covers four things: per-client records, guardrails, change logs, and nightly improvement.

The source is an interview article Latent Space published on October 31. Aman Singh, who leads Arca’s AI platform team, answered questions at AI Engineer New York 2026. The figures and mechanisms below come from Singh’s explanations in the article and the transcript. Arca has not published any performance or failure-rate numbers.

What Arca is#

Arca is a registered investment adviser that offers clients investment advice and tax, insurance, and estate planning. According to reports from WealthManagement.com on June 25, 2026 and InvestmentNews on June 26, it had more than $1 billion in assets under management and 28 employees, 9 of them advisers. It had raised $64 million in total: a $15.5 million seed led by Venrock and a $48.5 million Series A led by General Catalyst.

The premise of this case is that Arca does not sell software. It is an advisory firm with its own clients. Clients never deal with the AI directly; their contact is always a human adviser. According to General Catalyst, which invested in the company, agents handle most of the preparation and administrative work, while advisers handle the last 5-10%, the part where the human relationship creates value.

It takes 10 days because of waiting and handoffs#

Singh explains that financial work is “long-horizon” but not “long-running.” His example: a client emails to say they have received a $100,000 tax bill. Looking at the current asset allocation, working out where to sell to raise the $100,000 most efficiently, and having an adviser review and execute the trades can take up to 10 days. Along the way, he says, it “stops and starts, there are many people in between, and lots of decision points and handoffs.”

In work shaped like this, the assumption that one agent carries a conversation through to the end does not hold. A phone call in the middle is a new signal that is not tied to any running process. The person responsible for the seventh step does not need to be called on day one. The system that runs the agent (the harness) has to recover “where are we now” every time work resumes.

State lives in per-client records, not in the conversation#

Arca’s answer was to keep an internal record for each client. Each agent adds to this record. It holds what is happening now and what is being addressed, and what has happened so far. It also records what is needed in the next few days and what is being tracked over the long term, who owns what, and which person is responsible for which action.

Which agent receives a signal depends on its type. A reply in an existing email thread goes to the same agent that is reading that thread. A new signal that is not tied to any process, such as a phone call partway through, starts a new agent. The new agent reads the client’s record, grasps the situation (“we are working on a large tax payment”), then decides whether its signal relates to that case and adds to the record.

Another mechanism is a reflection process that Singh calls “dreaming.” It reviews the client’s whole situation and updates the record; elsewhere he describes it as a daily reflection. He says this long-lived record and the daily reflection are what let the system bring in the right person at the right time.

Arca’s design addresses the same problem as Anthropic’s article on harnesses for long-running agents, published November 26, 2025. Anthropic’s article starts from the premise that a new session remembers nothing from before, and has the agent leave a progress file and git history so the next session can quickly understand the situation. Arca’s record keeps that “handoff note to whoever comes next” per client rather than per unit of work. For an example of the same problem tackled from the research side, I also wrote an article on a paper that gives long-running agents a “current understanding”.

Trades and money movement are stopped by rules, not left to the model#

Singh says that “all of the safety restrictions are deterministic (decided by rules), and they take the decision out of the agent’s hands.” Simple tools, such as one that records a note, the agent runs by itself. Selling assets or moving money is technically possible through the custodian’s API, but it is configured so it cannot run without a person involved. Direct contact with clients likewise cannot happen without a person. When the agent finishes its analysis, it calls an adviser and hands over a plan they can review and adjust.

Beyond that, Singh named four checks:

• Every time a tool that writes to the database is called, a fast LLM call verifies the write
• Incoming email, documents, and phone call content are checked for prompt injection techniques when they are received
• When data goes out, as with web search or calendar invites, it is checked for personal information by rules, and a vote among several small models checks for exfiltration attempts
• Plans (PDFs) the agent produces are checked before release: rules look for raw account numbers, and a small model looks for wording that breaks regulations, such as promising returns

On where to put checks, Singh cites the principle of “constraining at the edges of capability, not before.” Looking at where the four checks above sit, the idea appears to be to leave the agent wide room to think, and to stop things where data is written, where it leaves, and where it reaches the client.

The handling of computation also seems to follow this principle. The agent itself is not in a sandbox, but computation is delegated to one. Data query code the agent writes is converted into a fixed, strict format, and the code itself is discarded. The agent can aggregate and transform data with code, but restrictions are applied to that format, and only the checked format reaches internal systems.

Using change logs for both audits and agents#

What financial regulation requires, Singh says, is being able to trace afterward what happened. At Arca, every agent action leaves a record of what changed, who changed it, from where in the system, and when. When a person changes client information in the UI, the same record is kept.

Besides audits, this record is used to notify agents of changes when a person modifies something in the UI.

Why they built their own harness#

Arca uses models from Anthropic and OpenAI, and today mainly uses Claude (it previously used Gemini, then moved to OpenAI and then Anthropic). Model choice is decided by internal benchmarks. Singh gave the example of trying a model that scored well on external benchmarks, only to find it too slow and expensive and not as good as expected.

Models are split into tiers by task complexity. Work like tax analysis uses the heaviest tier (Opus-class or Sonnet-class, or heavy GPT models), and many background tasks use lighter tiers. This choice is made internally; advisers never have to think about it.

The harness is built in-house and is not tied to any particular model. Arca does not rely on products that provide a harness, such as Anthropic’s Managed Agents. According to Singh, the core of such products is what the model remembers and what business knowledge it uses. Handing that to someone else means losing the room to tailor it to your own business, which is his reason.

One example of the in-house harness is a guard against stale facts. He says a model will sometimes run an analysis using 2025 tax brackets and call it done. When Arca’s harness detects that the model is about to make a financial recommendation, it prompts the model to use an internal knowledge base of facts verified as of today, or web search.

Turning frontline corrections into nightly improvement#

When staff correct or reverse an agent’s work, they are always required to write a reason. Singh explains that because Arca is itself the advisory firm, it can require staff to enter reasons. The reason is stored alongside the trace of the agent that did the work.

Each night, the traces of agents that ran in real work are collected, and a meta-agent runs over them to propose changes to the harness. What it finds includes misleading tools, operations that errored, and gaps in the knowledge base. However, a human engineer reviews prompt changes before they are made. Left to an agent, “every small fix turns into a whole prompt,” so the fixes cannot be consolidated into a generalized prompt, he says.

Business knowledge lives as files in the knowledge base, and in-house experts can edit it directly from a “Knowledge” tab in the product UI. Agents cite the knowledge base in their work, so errors in the knowledge are found by trace analysis and experts fix them on the spot.

As an example of results, Singh described having an agent read the documents of a prospect who was not yet a client. The prospect said they were paying their current adviser $1,500. From the documents, the agent found fees the prospect did not know about, and also showed that the adviser did not owe them a duty to act in the client’s interest (fiduciary duty).

Applying it to long business tasks#

If you bring this to work outside finance, Arca’s case suggests five items to check. This is my reading of Singh’s explanation applied to general business work, not something Arca has tested in other industries.

Item to check	How Arca does it
Where does a resumed agent read the situation from?	Per-client records holding owners, next steps, long-term items, and who is responsible
Which agent receives a new signal?	Follow-up replies go to the same agent; new signals go to a new agent
Which operations are never left to the model?	Trades, money movement, and direct client contact are done by people
Where do the checks go?	Writes, incoming data, outgoing data, and deliverables that reach clients
How are frontline corrections fed back into improvement?	Saved with reasons, analyzed nightly, and prompt changes reviewed by a person

For work that passes through many hands over several days, such as internal requests or inquiry handling, it seems best to settle the first and third items first. If you have not decided where state lives, you cannot resume an agent after stopping it. If you have not decided which operations people do, you cannot decide where the checks go either.

What is not known#

The interview does not say what format the records use, how they are searched, or how the system notices when an agent overwrites a record by mistake (every data-writing operation goes through LLM verification, but it is not known whether writes to the per-client record get the same verification). There are no figures on how many errors the write verification or the exfiltration checks have stopped. How many agents are involved per case, and how much model usage costs, has not been made public either.