The Next Step for Financial Agents: Not Just Better Answers, but Recovery After Failure
The Next Step for Financial Agents: Not Just Better Answers, but Recovery After Failure
Let us start with the conclusion: the hard part of building a financial agent is not generating a complete-looking analysis. The hard part is making a financial research task run reliably to completion. The agent needs to know what data it needs, what data it already has, which evidence is still insufficient, where a failure occurred, and how to continue from the previous task when the user adds one more sentence.
In other words, a financial agent should not only try to "answer like an analyst." It needs to behave like a traceable, recoverable, and reviewable research process.
01 A One-Shot Prompt Can Answer a Question, but That Does Not Mean It Can Do Research
Many financial agent demos look impressive at first.
A user asks: "Help me analyze whether this stock is still worth buying."
The model quickly produces a complete response: business overview, recent price action, industry environment, valuation risk, and investment view. The structure looks clear and the tone sounds professional.
But once the system enters real financial work, the problems appear quickly. Which version of the data did it use? Did it get the latest K-line data? Are the news and market data aligned? Are financial reports, filings, and research notes from the same time window? If a data source failed, did it degrade explicitly, or did it quietly fill the gap with guesswork?
The problem with a one-shot prompt is not that it cannot write. The problem is that it struggles to keep proving why it wrote what it wrote.
Investment research is not a single question. It is a changing set of workflows. Today you look at market data; tomorrow you look at filings; the day after tomorrow a news event forces you to rerun the hypothesis; next week you need to compare the result with the actual price path. An agent that only generates an answer on the spot has a hard time supporting that continuous process.
02 The More Tools You Add, the Less You Can Rely on Improvisation
After a financial agent is connected to tools, its capability appears to increase immediately: market data, news, financial statements, filings, research reports, macro data, and backtests are all available.
But as the number of tools grows, another issue becomes more likely: tools are not just a list of APIs. They are data entry points with different semantics.
The same symbol may mean a security code in a market data tool, a company entity in a financial statement tool, and a search keyword in a news tool. A-share, US equity, and Hong Kong tickers may use different formats. Technical indicators, fund flows, news search, and financial summaries may all require different parameters.
If every rule is stuffed into one very long prompt, the model can forget rules and can also apply the rule of one tool to another tool by mistake.
So financial agents will inevitably move from "one general prompt" to layered context: global rules, provider rules, precise tool rules, historical failure experience, and parameter repair experience should all be loaded dynamically for the current task.
This is not about making prompts more complicated. It is about making tool calls repairable, explainable, and reusable.
03 The Core of a Financial Agent Is Not the Answer, but Evidence Organization
The biggest risk in financial analysis is not a conservative conclusion. It is a conclusion without evidence.
When a user asks why a company has been volatile recently, a fast answer can say that it may be related to industry news, order expectations, or changes in capital flows. That sounds reasonable, but in finance, "sounds like an answer" does not mean it can survive follow-up questions.
A reliable system should be able to place different sources side by side for cross-checking:
- Market data shows whether the market reacted.
- Volume and fund flows show whether the reaction was unusual.
- News and filings explain possible event drivers.
- Financial reports and fundamentals help determine whether the impact is short-term noise.
- Research reports and industry information help assess whether the market had already priced in the expectation.
These sources are not interchangeable interfaces. They are different types of evidence with different roles. The value of an agent is not that it can stitch them into a paragraph. The value is that it knows what each type of evidence can prove, and what it cannot prove.
This is the core step when a financial agent moves from Q&A to workflow. The user should not only see "analysis complete." The user should see the conclusion, rationale, risks, data gaps, and next actions.
04 Failure Is Not an Edge Case. It Is Part of the Financial Workflow
Failure is an easily underestimated problem in financial agents.
In practice, failure is very common:
- The user did not provide a stock code, strategy conditions, or time range.
- A data source returned no results.
- A data request is still processing and the result is not ready.
- Different data sources have special ticker format requirements.
- The quote response does not include
volume, while OHLCV already contains volume. - A macro question is incorrectly forced into a single-stock analysis model.
- The data result has returned, but the report layer did not resume aggregation in time.
If the system describes all of these cases as "analysis failed," the user will be confused. Did I ask the wrong question? Is the data source broken? Or does the model not know how to analyze it?
A better approach is to split failure into understandable states: fetching data, needs additional input, data source temporarily unavailable, partial data missing, request timed out and can be retried, result completed but evidence is insufficient.
This may sound like a product copy issue, but it is fundamentally a system modeling issue. Only when the underlying system models tasks, steps, evidence, requests, results, and retry actions clearly can the upper layer translate complex states into language users can understand.
05 Do Not Turn LLM Text into a Data Pipeline
Financial agents have another common trap: using the model to "retell" structured data in natural language for the next step.
For example, in a backtest task, the market analysis module may already have obtained K-line data, but the parent flow then tries to parse candles from that module's reply text. If the model response is incomplete, the context is too long, or the field format drifts, the final result may become 0 candles.
This is not because the model is not smart enough. The chain design is wrong.
K-lines, volume, financial statement tables, portfolio holdings, and backtest results should not be passed through natural language. A more reliable method is artifact-first: after a tool call succeeds, write requestId, toolId, parameters, state, raw result, normalized candles, quote, news, and financials into structured artifacts. Backtests, reports, and evidence audits should then read the artifacts instead of scraping data from chat text.
LLMs are good at understanding questions, explaining results, and summarizing risks. They should not serve as the intermediate transport layer for high-density financial data.
06 Users Do Not Need Process Noise. They Need Understandable Research State
Traceability does not mean exposing every internal detail to the user.
Users do not need to see storeDir, requestId, toolId null, low-level heartbeats, raw JSON, or sourceRequestIds. Those are engineering diagnostics, not product information.
What users really need to see is:
- Whether the current task is planning, fetching data, analyzing, or writing.
- Which core data has already been retrieved.
- Which optional data is missing but does not affect the main conclusion.
- Which missing data reduces confidence.
- Whether the system needs the user to provide more input.
- Whether the task can continue, retry, or finish with degradation after failure.
This is a key step in moving a financial agent from demo to product. The inside can be complex, but the outside must be stable, restrained, and understandable.
07 From "Can Answer" to "Can Recover"
The next stage of financial agents should not be a competition over who connects more tools or whose model writes a better report.
The real question is whether the agent can organize the financial research process.
It must recognize task types, plan data requirements, call the right tools, distinguish core evidence from optional evidence, persist structured artifacts, generate explainable reports, and recover when data is missing, requests time out, users ask follow-up questions, or input is insufficient.
A mature financial agent does not never fail.
On the contrary, it should acknowledge failure, explain failure, preserve the state, allow additional input, and continue from the previous research thread as much as possible.
That is the boundary between one-shot Q&A and real investment research workflows.
The point can be summarized in one sentence:
The core competitiveness of a financial agent is not answering every question beautifully. It is making every answer grounded in data, evidence, state, and boundaries, while still being able to continue after failure.