Using Agents for Long-Horizon Financial Work — Aman Singh, Arca
- Arca’s $64 million raise supports an AI-native wealth firm built around human advisors. Singh wants AI to replace “all of the work around the advisor,” spanning financial planning, tax, insurance and estates. Owning the firm lets Arca standardize operations and run a proactive service around each client.
- A ten-day, $100,000 tax-bill workflow illustrates the boundary between agent analysis and human financial authority. Agents identify assets to liquidate, maintain context and summon staff; experts review plans and execute trades. Money movement and direct client communication require human involvement: “Agents prompt people more than people prompt agents.”
- Model selection follows Arca’s internal benchmarks, with Claude primary and provider dependence deliberately limited. Luna disappointed despite external benchmark claims: it was “way too slow” and costly. Tax analysis receives heavier model tiers, while background activity uses lower tiers, with routing hidden from advisors.
- Persistent client memory is the strategic layer Singh wants Arca to own. Shared state and a daily “dreaming process” connect new signals to ongoing work. He sees outsourcing memory and operational knowledge to managed agents as a control risk: “Owning your intelligence” preserves the ability to shape the business.
- Financial safety combines fixed permission boundaries with model-based verification. Singh calls restrictions “fully deterministic”; separate LLM checks examine database writes, data leakage and client artifacts. Decision models also nudge financial analysis toward verified current facts or search, addressing confident use of stale 2025 tax brackets.
- Staff feedback becomes nightly evaluation data, but engineers still approve prompt changes. Edits and cancellations carry reasons linked to agent traces; a meta-agent proposes improvements to the harness and knowledge base. Singh’s warning about autonomous prompt repair: “every little fix becomes the whole prompt.”
- The client evidence centers on discovering hidden fees, with investment performance unquantified. A prospect who believed an advisor charged $1,500 learned of additional fees and, in Singh’s account, that the advisor was not a fiduciary. Singh credits agents’ “attention to detail,” without supplying realized savings or investment returns.
1. Owning the firm lets Arca standardize agent work
- At AI Engineer New York 2026, MacManus introduces Arca’s $64 million raise. Singh leads its AI platform team, building the harness to run the business with AI; services span financial advice, tax, insurance and estate planning.
- Singh’s mandate is “not to replace the advisor” but “to replace all of the work around the advisor.” Clients receive human empathy and care while agents monitor markets and life circumstances; selling a business, for example, creates financial complications involving multiple partners.
- “We are the firm ourselves,” Singh stresses: Arca can standardize how work happens. His distinction from firms buying AI tools is proactive service running twenty-four seven, where “agents prompt people more than people prompt agents.”
2. Ten-day workflows depend on memory and timed human intervention
- MacManus’s tax-bill walkthrough spans ten days: a client needs $100,000, and agents analyze existing allocations to determine the most optimal assets to liquidate.
- Despite custodian APIs capable of moving money, human review gates liquidation, transfers and client communication. Experts can adjust proposed plans and execute trades. Pressed later on failed-trade recovery, Singh clarifies that Arca is not doing autonomous trading.
- Asked how resumed work stays aligned with client needs, Singh distinguishes email replies, which return to the same agent, from a new phone call, which wakes another. Shared memory records “Who owns what?”, completed work, immediate next steps and longer-term obligations, letting the new agent connect its signal to the existing tax bill.
- A daily “dreaming process” reflects on the client’s situation and updates memory. Timing matters: the person needed at step seven need not be involved earlier; agents use incoming signals to pull in the right person when required.
3. Models can change while business intelligence stays in-house
- Claude is the primary model, following earlier use of Gemini and OpenAI. Internal benchmarks govern selection: despite strong external claims for Luna, Singh found it “way too slow” and costly. Arca wants to remain model-agnostic and preserve provider optionality.
- Routing is invisible to advisors. Tax analysis receives the heaviest tier—an Opus tier model, a Sonnet tier model or a heavy GPT model—while simpler background activity uses lower tiers. One internally built harness supports these choices.
- MacManus raises managed-agent orchestration and the risk of removing humans. Singh is bullish on Anthropic and OpenAI models but reluctant to outsource memory and operational knowledge: “Owning your intelligence” preserves the ability to shape the business; handing it away risks losing control over what makes Arca distinctive.
4. Guardrails constrain agents at the edges of capability
- Singh calls safety restrictions “fully deterministic”: permission decisions sit outside the agent. Separate fast LLM calls verify every database write. Agent actions and staff edits produce logs of what changed, who changed it, where and when; “compliance cares about auditability,” and those same events can inform agents.
- Incoming emails, documents and calls are screened for prompt injection. Outbound web searches and calendar invitations face deterministic PII checks plus a consensus of small models checking for exfiltration. The principle is to “contain them at the edges of capability.”
- The agent uses a sandbox to offload computation. For data access, generated code becomes a strict format; the code is discarded and guardrails apply before the backend. Financial-plan PDFs face checks for raw account numbers and non-compliant language, such as promising returns. Singh argues tireless checking can improve compliance relative to humans.
- Financial confidence needs another check: models will happily use 2025 tax brackets for current analysis. Decision models detect actions requiring financial rigor and nudge agents toward verified knowledge or web search. Asked about decision models for failed-trade recovery, Singh says, “No, not today.”
5. Staff corrections feed improvements, while client evidence remains specific
- Staff edits and cancellations require a reason, paired with the originating agent trace. Each night, a meta-agent reviews real-world traces and suggests harness changes, including clearer tools or missing knowledge. Human engineers approve prompt changes: left alone, agents make “really nasty prompt changes,” because “every little fix becomes the whole prompt” rather than a generalizable correction.
- Experts maintain file-based operational knowledge through a first-class Knowledge tab. Agents cite those files; trace analysis surfaces incorrect information, and staff can edit it directly. Owning the firm lets Arca require feedback as part of its operating process.
- Asked for a measurable investment or tax result, Singh describes a prospect who believed an existing advisor charged $1,500. Agents reviewed documents, investments and goals, finding additional fees and, Singh says, that the advisor was not a fiduciary. The prospect had not yet become a client; Singh gives no quantified savings or investment return.
Full transcript
We’re actually not a SaaS company. We are the firm ourselves. Agents prompt people more than people prompt agents, and it’s a proactive kind of service that’s running for them 24/7.
We’re here at the AI Engineer New York conference in 2026, and I’m here with Aman Singh from Arca. Arca recently raised $64 million for an AI-native wealth management firm. First of all, Aman, can you tell us a bit about your role at Arca, the financial services you provide, and how you’re using AI agents to run them?
1. An AI Native Advisory Firm
Yeah, for sure. Thanks for having me. My role at Arca is to lead the AI platform team, so we’re building the underlying harness and capabilities to run the business with AI, which is our ultimate goal.
The services we provide to our clients cover a broad spectrum of financial services. That includes financial advice and financial planning for their assets, as well as tax planning, insurance, and estate planning as people get wealthier. Maybe you’re someone who just sold a business, for example, and there are lots of complexities with all the different partners. We can help you think through that.
We also have clients who are really large technology executives trying to figure out a real plan for retiring early, and small families trying to buy their first home.
The clients you have so far—do you have to talk them through using agents, explain why you’re using agents, and tell them a bit about the technology behind it?
The role of AI at Arca is not to replace the advisor. It is to replace all of the work around the advisor. Our clients don’t really interface with AI directly. All they experience is a level of service that hasn’t been possible in this industry before, delivered through the empathy and care of a human advisor.
We’re building the machinery behind every client that’s constantly thinking about what the market is doing and how it impacts Richard. What else is going on in your life? What are the textures of your life that impact your finances? We’re able to be way more proactive and responsive, and deliver a better level of client service using AI to do all of the back-office work.
Let’s get into some of the technical aspects. Which models are you using to power your agents, and how do you decide which model is best for which action?
2. Choosing Models By Task
Today we’re using frontier models from frontier labs like Anthropic and OpenAI. Claude has been our primary model, but we’ve gone through several iterations of models over the years. We used to be on Gemini way back when, then OpenAI, and then Anthropic.
What guides all of our decisions are our internal benchmarks for the various capabilities our general harness needs to express in running our business. Recently, for example, despite the external benchmarks claiming great things for Luna, it didn’t quite work out for us as well as we’d expected. It was way too slow, and it was costing a lot.
Our internal benchmarks guide our model decisions. As a principle, we want to be model-agnostic and not depend on a certain provider or a certain harness from one of these labs. We want to keep that optionality open for us.
You just mentioned harnesses. Are you using different harnesses depending on which model you’re using?
No. We have our own harness, built internally, that’s model-agnostic.
When a financial advisor is doing something like a tax report, how does the harness decide which model to use? Is that automated?
Yes. We have certain tiers of models based on the complexity of different tasks. A task like assisting with a tax plan or doing a tax analysis would get our heaviest tier of models. Within that tier, it’s a little flexible, so you could use an Opus-tier model, a Sonnet-tier model, or a heavy GPT model.
There’s a lot of background activity that our agents participate in, and that uses a lower tier of model based on the complexity of the task. That’s how we decide which model serves which task.
Is it the financial advisor who’s actually making that decision while they’re using the product?
Not really. They’re not aware of that happening. We’ve abstracted it away from them entirely. They just interact with our product as they would, and those decisions are made internally by us.
In your presentation at the conference earlier today, you talked about a tax bill example. Could you walk us through an example of adjusting a client’s investment portfolio—from identifying a need to rebalance the portfolio to executing trades? Which parts of that process does the agent do, and which parts does the human advisor do?
3. Long Running Client Work
Just like in the talk, this is something that will span 10 days. Agents are ultimately responsible for delivering that outcome, but there are certain parts that they do and certain parts that they don’t.
In this example, when the client emails us with a tax bill, there’s an analysis of where the client’s money is allocated today and what the most optimal way is to liquidate some of it to produce $100,000. That’s best suited for agents to take on as an analysis task.
Right. So they do exactly that. Do they have certain limits? They can’t execute a trade above a certain amount?
Correct. The analysis part is fully automated, but they’re unable to execute any sort of money movement or liquidation automatically. We have a deep integration with our custodian, which gives us APIs to be able to do that, but we have strict guardrails around human-in-the-loop for things that would move money or liquidate assets, or even directly communicate with our end clients, because there’s a level of service and quality that we expect.
All of the internal analysis will be done by agents, but they’ll also pull in the right person to execute the trade when needed. They’ll give that person a plan to review and adjust, and then go from there.
You mentioned that these processes tend to take 10 days, or at least have a longer running time than most agent tasks these days. When an agent resumes a task days later, how do you check that the plan still fits the client’s needs?
This is an interesting one to think about. We have tons of signals, like I described in the talk. For example, there might be an email thread receiving responses, with chatter happening. Any additional response to that goes to the same agent that’s reading the email thread and reacting to it.
But a fresh signal, like a phone call that was made in the middle, is a brand-new signal that isn’t attached to any other ongoing process. A fresh agent wakes up to figure out what it means. The way it understands what’s happening right now is through our internal memory systems.
For every client, we persist what’s happening right now, what we’re trying to service, who owns what, and what has happened so far. We track what needs to happen next, what needs to happen immediately in the next couple of days, what we’re tracking for the long term, and which individual is responsible for each action. All of this is tracked by our memory systems, which our agents contribute to.
There’s also a kind of dreaming process that reflects on the state of the world as it relates to Richard, the client, and updates these memory systems to persist long-horizon tasks. So the agent that receives a new signal quickly ramps up on the client’s situation. It’ll know, “Okay, we’re actually executing a big tax bill,” and be able to see that its signal relates to that tax bill, then contribute to the state of that world.
Can you talk a little bit about the safety aspects you’ve built into your product or harness to make sure that no money is lost along the way?
Yeah.
4. Safety And Auditability
All of our safety restrictions are fully deterministic, and they take the decision-making out of the agent’s hands. For example, certain tools let the agent execute the tool itself. If it’s a simple record-keeping tool, it will execute it. Every time a tool is called that writes data, we also have an LLM-based verification running on that action. These fast LLM calls analyze every single write to our database.
Mm.
That’s another layer of verification we’re running. We also ingest a lot of external information, so emails and documents come in, and phone calls are made. Those are targets for prompt injection, so we run verifications at the edges to detect certain flavors of prompt injection.
Mm.
Anytime data leaves our system—for example, in a web search, which is the most obvious case, but also if we’re sending a calendar invite to Richard—that’s external data. We have deterministic checks for information we know is PII, as well as a consensus of small models to ensure that there isn’t any data exfiltration being attempted.
Mm.
We have lots of different guardrails built into the harness, with the principle that we want to contain them at the edges of capability, and not earlier than that.
Right. And because you’re in the financial industry, are there certain regulations you have to comply with in terms of the technology you’re using, or is it more about outcomes and how you deal with clients?
Yeah. The industry cares about outcomes, but compliance cares about auditability.
Right.
Our system is set up so that auditability is built in by default. Every single action an agent takes produces a change log of what changed, who changed it, which part of the system it came from, and when. This applies not just to agents, by the way, but to human actors as well. If you change something in the UI that affects a client, we’ll log that action.
Mm.
That gives us auditability by default, but also powers some of our agentic capabilities. The same thing that tracks a UI change can also inform the agent that it happened. Auditability has been a big part of our story, both for compliance and regulation, but also for our agentic loop.
Yes. In your presentation, you had a nice line: “Agents prompt people more than people prompt agents.” How do the agents decide who to involve, and how much context they need to provide that person to do what they need to do?
5. Orchestrating People And Agents
Another interesting one. This is similar to how humans work in our industry. There’s a process we’re tracking over 10 days, with multiple actors involved. The actor at step 7 may not need to know about it just yet; they’re pulled in at the right time.
Mm.
Our agents, with their long-term memory persistence and daily reflection on what’s happening, reflect on the current state of the world. They’re able to pull in the right person at the right time, when there’s a signal that implies that person must be pulled in.
Mm.
All of this is work we’ve done to operationalize the context of how this industry works—not just that, but how Arca wants it to work, and our principles for how work happens in this industry. Another advantage is that we’re actually not a SaaS company. We are the firm ourselves, so we can standardize how this work happens, and our agents can participate in the standard ways the work must happen.
So, early in the conference, Anthropic did a workshop about its Managed Agents infrastructure, and a lot of it—even the orchestration—is becoming more automated now. Do you foresee using that type of functionality? Obviously, it presents a danger in that a human isn’t necessarily always in the loop anymore. Have you had any thoughts about using that technology to automate even more of the process?
I think we’re very bullish on the models from Anthropic and labs like OpenAI, but less so on taking a dependency on a product like Managed Agents. One of the key things about Managed Agents is how the models persist and contribute memory about what’s happening in the world, along with all the operational knowledge they need to use to be successful.
Mm.
Letting them own that part of the business is a risk, because owning your intelligence gives you the ability to impact the business. If you hand off the intelligence to another provider, you lose some of the control you need to build something unique and tailored to your business to such a great degree that it can actually impact your business.
And just on Anthropic, they’ve also recently released financial services, so they’re partnering with a whole bunch of different firms. Do you think what they’re doing is competitive with what you’re trying to do, or do you see them as different things?
I think Anthropic getting into our kind of industry is very validating for our industry. But the way I think about it is that it’s very different to be a services firm that has access to AI tools versus a firm that was built to be AI-native.
Mm-hmm.
A firm with AI tools requires its users to prompt the agents to produce work or do work. But here at Arca, as I said, agents prompt people more than people prompt agents. It’s a proactive service that’s running for them 24/7, running the business in the most standard way we expect, at the level of service we aspire to. That looks very different if you’re a company with AI tools.
Yes. Okay. A little bit more on the security side: Can you explain what in your processes runs inside a sandbox, and how you verify a change to a financial plan before anyone acts on it?
The way we use sandboxes is that the sandbox is one component of our harness. Our agent isn’t actually inside the sandbox; it uses the sandbox to offload computation. We’ve built systems to make it safe for code inside the sandbox to access our data.
Mm.
We have a system that translates the code it wrote into a strict format that we expect, throws away the code, and instills guardrails on that format before it reaches our back end. We allow the agents to use code to query our data, which means they can aggregate it, munge it, and work with it as they see fit to produce something like a financial plan.
Mm.
Inside the same sandbox, they produce a beautiful artifact that we can share with clients: a PDF of their financial plan and how we’re planning to approach their financial life. Once that’s produced, we run our verifiers. It’s a certain type of artifact produced from the sandbox, and the moment it’s produced, we run a bunch of different verifications on it.
Yep.
Some are deterministic checks for things like, “Hey, did you just put a raw account number in there? You should not do that.” We can check that deterministically, but we also use fast models, like smaller models or JEV[?], to analyze for things that might make the artifact non-compliant. For example, you really shouldn’t promise returns in that artifact. We check for that before it’s publishable.
Mm.
The last thing I’ll say is that doing this actually makes our compliance better than if humans were doing it, because AI is tireless at finding even the smallest mention of non-compliant writing. We’ll continue to invest in more of that and constrain things at the edges of capability.
Yes. You mentioned JEV[?] there. You’ve started to use decision models as part of your process. What other products, other than JEV[?], are you looking at?
What we’ve noticed is that when models are working with financial data, when they’re answering questions that require financial knowledge, they’re very confident in the knowledge they have. A small example is that models will very happily use the tax brackets from 2025 to come up with an analysis and say, “All right, that is it.” But that is obviously incorrect.
That is one way we use decision models in our harness: to check when the model is about to make a financial recommendation or take an action that requires financial rigor. The decision model will detect that and nudge the model to use our knowledge base of verified facts about the world as it is today.
Mm-hmm.
And/or use web search.
Yes.
This is a point about the harness and owning the harness: it lets you do things like this to help your models be accurate where it matters.
And do you use decision models for recovery if, for example, a trade fails to execute? Is there a decision model involved there, or is there another path to get the agent back on track?
No, not today. That is not a use case we’re exploring today.
Okay. If a trade does fail, for example, how does the agent recover at the moment in your process?
At the moment, we’re not doing autonomous trading with agents.
Okay.
It’s very much a process where the agents propose that we make trades.
I see.
Yep, and it’s fully up to our experts to figure out if that’s the right trade to make—
Right.
—and to execute the trade.
On the same line, your slides say that every staff edit or cancellation comes with a “why” and becomes an eval. How does that feedback get turned back into a measurable improvement in the system?
6. Turning Feedback Into Improvements
That’s another advantage of us being the business and not a SaaS company: we’re able to require them to give us feedback. The way we loop feedback back into improvements is what you’d expect: all of that feedback gets piped into a data store that couples it with the trace of the agent that produced it.
Mm-hmm.
We’re able to take that trace, put it next to the feedback, and every night run a process where we collect traces from the real world, from our agents in the wild, and run a meta-agent on top that suggests changes to our harness.
Mm.
It might identify tools that were misleading, things that had errors, or missing knowledge in our knowledge base.
Mm-hmm.
They’ll surface this information to us, and then we’ll be able to improve it. Today, we still have a human engineer in the loop before we actually ship a prompt change.
Yes.
I’ve noticed that agents will make really nasty prompt changes if you leave them to it. Every little fix becomes the whole prompt, and they’re unable to stay meta and generalize the fix into a prompt that generalizes.
Mm.
But we do have feedback loops from our product that we collect directly as first-class product features, to collect evals and turn them into improvements.
Hmm. Okay. You also mentioned in your presentation turning knowledge of how a firm works into agent context. That’s something a lot of forward-deployed engineers try to do: turn an organization’s internal knowledge into actionable things for agents. What does that look like technically at your company, and how do you keep it up to date?
We have a knowledge base represented as files, and we’ve handed it to our experts to curate and update.
Mm.
It’s a first-class feature in our product. On the left-hand side, there’s a tab called Knowledge, which has the full operational context our agents use. As they work on things, they’re able to cite knowledge, which creates a loop: “Oh, we noticed that the knowledge is incorrect.”
Mm-hmm.
That gets surfaced to us in our trace analyses. Because it’s part of the product itself, people can go in and edit it directly.
Okay. That’s how it works. All right. So you mentioned that you’re offering these services to clients, and I presume you have a staff of financial advisors at your firm. Can you give us an example of a client who’s had a measurable improvement in their investments, taxation, or something else through the agent system? And maybe some details about what in the agent architecture helped them get such a good return?
I’ll give you a recent example. This person wasn’t a client yet, but they were at the point of becoming one. We had all their documents, statements, current investments, and so on.
Mm.
This person was already working with an advisor. They met with us and told us, “Hey, I have this advisor already. They’re charging me $1,500 for their services, and they’re not very responsive to me, so I’m chatting with you.”
Mm.
Our agents read through all those documents and analyzed them, including the person’s stated goals. They also analyzed the information about who the current advisor was and how much they were charging. They discovered fees the person wasn’t aware of and surfaced that to them, making them aware not only that they were being overcharged, but also that the advisor wasn’t a fiduciary.
Mm.
So the advisor wasn’t obligated to act in the client’s interests.
Mm.
That’s the sort of attention to detail our agents bring when analyzing a financial picture—something that wouldn’t have been possible if we didn’t have these agents. There are several examples of the proactivity our agents bring: someone has a deadline coming up, or they’re at risk of missing their RMD, for example. That’s difficult for humans to keep track of at scale, but it’s the default behavior of our agents at Orka.
Yeah. Wonderful. That’s probably a good point to stop. Thank you very much, Aman, for joining us.
Thank you for having me.