Most agent demos show a model finishing a task in minutes. Arca, an "AI-native" wealth-management company, runs agents on work that can take up to ten days, and still keeps people in charge of every decision that touches a client's money. In a Latent Space interview recorded at AI Engineer New York, lead AI engineer Aman Singh summarized the philosophy in one line: "agents prompt people more than people prompt agents."
This is a vendor-adjacent interview, so treat the claims as Arca's own account, not independent verification. Still, the engineering choices are concrete and transferable: per-client persistent memory, an owned harness that routes between models, deterministic safety limits, and a feedback loop that turns advisor corrections into improvements. This post pulls those out and shows what you can borrow.
TL;DR: the Arca design in one table
| Design question | Arca's answer (per Latent Space) |
|---|---|
| How long are tasks? | Up to ten days; long-horizon but not long-running |
| Who decides? | A human advisor; agents analyze and propose |
| Who can move money? | Only humans; trading and money movement are not agent actions |
| Memory | A persistent record per client: what happened, what is tracked next, who owns each action |
| Models | Frontier labs including Anthropic and OpenAI, Claude primary |
| Harness | Custom, routes each task to the best model by internal benchmarks |
| Safety | "Fully deterministic" restrictions plus checks for prompt injection and other known issues |
| Code execution | Sandboxed computation; code converted to a strict format, then discarded |
| Improvement loop | Advisor feedback plus agent traces analyzed by a meta-agent that suggests harness changes |
| Funding context | Arca recently raised $48.5 million, led by General Catalyst, per the interview write-up |
Agents that act on your behalf need rules. See how explainx helps secure your agents →
Long-horizon is not long-running
The most useful distinction in the interview is between a task that runs for a long time and one that spans a long time. Singh said Arca's work is "very stop-start, there's many actors in between, many decision points, many handoffs." The agent finishes a step, waits for a client document or an advisor's approval, then picks up again days later.
That changes what the system needs. A long-running agent needs to stay alive; a long-horizon one needs to remember and resume. For a related approach to resumable overnight work, see our post on Sentient OS, an open-source Mac agent that works overnight.
Memory per client, written by the agents
Arca built an internal memory system with persistence for every client. Singh described the record as answering four questions: what has happened so far, what is being tracked next, what must happen in the next couple of days versus the long term, and which individual is responsible for each action. The agents contribute to that memory themselves.
The shape matters more than the technology. It is not a chat transcript; it is a task ledger with owners and horizons. Compare it with the argument in Agents don't need memory, they need documentation and the cross-tool approach in Beacon, an open-source cross-harness agent memory. Arca's ledger-with-owners is a good template if your agent hands work to people.
Why own the harness
Arca uses models from Anthropic and OpenAI, with Claude as its primary provider, but it wrote its own harness instead of using a managed one. The harness picks the best model for each task based on the company's internal benchmarks. Singh said owning it also keeps the company free to switch providers.
The trade-off is cost: you maintain routing, evals and tool plumbing yourself. The payoff is that a model change becomes a config and eval decision instead of a migration. Our analysis of switching between harnesses in the Cindy open-source agent and the Agent Lightning harnessed-RL guide covers the same pressure from other angles.
Safety: deterministic limits instead of asking the agent to behave
The quote worth keeping: "All of our safety restrictions are fully deterministic... they take the decision making off the agent's hands." Singh said an agent can execute some tools and tasks by itself, but not ones that involve risk to the client. Trading and money movement belong to human advisors. Arca also runs verification checks for known AI security issues such as prompt injection.
This is the central design pattern for any agent that can touch real assets: put the dangerous actions behind code, not behind a prompt. A model can be talked out of a rule; a function that does not exist for the agent cannot. For a toolkit-level look at the same idea, see Archestra's guardrails and remote agent runtime, and for sandboxing, our write-up of Capsem's VM sandbox for Claude Code, Gemini CLI and Codex.
A mechanical gripper offering a bead to a human hand, showing an agent handing a decision to a human advisor in a long-horizon agent workflow
Sandboxes without trusting the code
Arca's agent is not itself sandboxed, but it uses sandboxes for computation. Singh described an extra layer for sensitive data: code the agent writes is translated into a strict expected format, the code is thrown away, and guardrails are applied to that format before it reaches the back end. That lets agents aggregate and transform data to produce things like a financial plan without letting arbitrary code reach production systems.
The idea generalizes: validate the intent, not the program. Reduce what the agent produced to a narrow schema you can check, and execute only that.
The feedback loop: advisors teach the harness
Another process Singh described: feedback from human advisors, together with traces from the agents, is analyzed by a "meta-agent" that suggests changes to the harness. In the interview's timestamps, this shows up as turning staff feedback into evals and improvements. It is a small-scale version of the loop labs describe for improving agent scaffolds, grounded in real corrections from experts.
If you are building something similar, the practical steps are:
- Log every human override with the agent's trace and reason.
- Convert recurring overrides into eval cases, so a regression shows up before it ships.
- Let a separate process propose harness changes, but keep a human reviewing them.
Why prompt injection is the right threat to name
Singh singled out prompt injection among the known AI security issues Arca checks for, and it is the right one for a firm whose agents read client emails, statements and documents. An instruction hidden in an uploaded PDF is read by the agent as if it came from the operator. The OWASP Top 10 for LLM Applications lists prompt injection first for this reason, and its guidance lines up with Arca's approach: limit the agent's privileges, keep a human in the loop for high-risk actions, and treat model output as untrusted input to the next system.
Notice what makes Arca's setup resilient even when an injection succeeds. If the worst a hijacked agent can do is write a bad proposal, the advisor who reads it is the control. The deterministic limits mean the agent never held the ability to wire money in the first place. That is a better security story than a classifier that tries to catch every malicious string.
Questions worth asking Arca-style teams
The interview is a good conversation starter, not a complete spec. If you are evaluating a vendor or designing your own agent system with similar claims, ask:
- What is the exact list of actions the agent can take without a human? Get it as a list of tool names, not a description.
- Where do the deterministic rules live? In the harness, the API gateway or the database layer matters for how hard they are to bypass.
- How is memory corrected? A per-client ledger that an agent writes can also record mistakes; ask who audits it.
- What do overrides cost? If advisors override a third of proposals, the agent is a drafting aid, not an assistant; if almost never, check whether they are rubber-stamping.
- How long does a stale task wait? In ten-day workflows, a forgotten handoff is the common failure, so ask about reminders and escalation.
What to be careful about
- It is one company's account. The interview is a conversation, not an audit. We have no independent data on error rates, client outcomes or how often advisors override agents.
- Financial claims are out of scope. Arca's regulatory standing, returns and fees are not covered here, and nothing in this post is financial advice.
- Deterministic does not mean complete. A fixed rule set protects the actions it covers; the interview does not say how new risk categories get added.
- Prompt-injection checks are partial by nature. Arca says it verifies known issues, which is the right wording: known issues, not all issues.
What builders can borrow
| If you build... | Borrow this from Arca's account |
|---|---|
| Back-office or approval agents | Agents propose, humans decide; money movement stays human |
| Multi-day workflows | A per-case ledger with owner and time horizon, written by the agent |
| Multi-model products | Own the routing harness and pick models from your own benchmark results |
| Agents with code execution | Convert code to a strict format, check it, discard the code |
| Quality improvement | Turn expert overrides into evals; use a meta-agent to suggest changes |
For readers working through the cost of checking AI output, our post on the AI verification tax shows why designs that make humans review only the decisions that matter, rather than everything, are attractive.
Details reflect the Latent Space interview published October 31, 2026 and may change. Nothing here is financial advice.
Related reading
- Sentient OS: an overnight open-source Mac agent
- Agents don't need memory, they need documentation
- Beacon: open-source cross-harness agent memory
- Cindy: harness switching across Claude Code, Codex and Pi
- Archestra 1.4: guardrails and remote agent runtime
- Capsem VM sandbox for coding agents
- Official: Latent Space interview with Aman Singh of Arca