Quant Memo
Core

Agentic Research Workflows

An agentic workflow lets an LLM plan its own sequence of tool calls — search, extract, compute — instead of following one fixed prompt, trading predictability for the ability to handle open-ended questions.

Prerequisites: Large Language Models

A single well-designed prompt can pull one number out of one document reliably. It can't answer "compare this company's margin trajectory to its three closest peers over the last eight quarters" — that question needs several documents found, several numbers extracted, and a comparison assembled, and no fixed prompt template covers every path that research might take. An agentic workflow hands the model a set of tools — search, fetch a document, run a calculation — and lets it decide, step by step, which tool to call next based on what the previous step returned, rather than following one prewritten sequence.

The gain is flexibility: the same agent can handle "compare margins across peers" and "find every 8-K amendment in the last year" without separate custom code for each. The cost is predictability: a fixed pipeline fails the same way every time you can debug once and fix, while an agent can wander down a different, wrong path on a rerun of the exact same question.

Every extra step an agent takes on its own is an extra chance to go wrong that a fixed pipeline doesn't have. Agentic flexibility is worth its unpredictability only when the task genuinely varies enough that a fixed pipeline can't cover it.

A concrete workflow

Given "compare margin trajectory across peers," a reasonable agent loop looks like: identify peers (search or a maintained lookup), for each peer retrieve recent filings, extract margin figures from each (see Structured Extraction From Filings With LLMs), assemble the results into a table, and produce a written comparison. At each step the agent decides which tool to call and reads the result before deciding the next step — it isn't following a hardcoded sequence, so if a peer's most recent filing is missing a figure, the agent can decide to check the prior quarter instead, something a rigid pipeline would need to be explicitly coded to handle.

Where it breaks

Agents can get stuck in loops — calling the same search repeatedly with slightly reworded queries because a first attempt returned nothing useful and the agent hasn't learned to give up and report the gap. They can also compound small errors across steps: an entity resolved to the wrong peer early on quietly pollutes every later step, and because each step looks locally reasonable, the whole trace can read as coherent while the final answer is simply wrong.

The practical mitigations are the same ones that make any automated system trustworthy: cap the number of steps an agent can take before it must stop and report, log every tool call and result so a wrong final answer can be traced back to the step that introduced the error, and require the agent to cite which document or calculation each claim in its final answer came from — the same discipline that makes extraction checkable applies to agentic output.

An agent's confident, well-structured final report is not evidence its intermediate steps were correct. Check the trace, not just the conclusion, especially on a question where you don't already know the answer well enough to sanity-check it yourself.

Agentic versus fixed pipelines: choosing between them

The decision isn't "agents are more advanced, use them by default." A fixed pipeline — extract this field, from this document type, every time — is easier to test, easier to monitor, and fails in ways you can enumerate in advance, because the same three or four steps run every time in the same order. An agentic workflow earns its cost when the actual set of steps genuinely depends on what earlier steps find: which peers exist, which filings are available, how many quarters of data are actually reported. If you can write down the fixed sequence of steps in advance and it covers the vast majority of real cases, a fixed pipeline with a manual escape hatch for the rare exception is usually the better engineering choice — it's cheaper to run, cheaper to debug, and its failure modes are ones you already know about.

What "agentic" adds beyond calling an LLM once

The distinguishing feature is that the model's own output feeds back into what it does next. A one-shot call takes a prompt and returns an answer; an agentic loop takes a prompt, takes an action based on the model's read of the situation, observes the result of that action, and decides the next action using that observation — repeating until the model itself decides it has enough to answer, or until a step limit forces it to stop. This is what lets an agent recover from a missing document by looking somewhere else, but it's also what lets a small early misstep compound, because nothing forces the model to notice that step three built on a wrong assumption from step one until the final answer is checked.

Cost and latency are part of the design, not an afterthought

Every additional tool call in an agentic loop is another model call, and both cost and latency scale with how many steps the agent decides to take — which, unlike a fixed pipeline, isn't fully known in advance. A workflow with no step budget can, on a genuinely hard or ambiguous question, spiral into dozens of exploratory searches before producing an answer. Setting an explicit maximum step count, and having the agent report "I couldn't find X" rather than continuing to search indefinitely, keeps cost bounded and turns an open-ended failure into a visible, actionable one.

Related concepts

Further reading

  • Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (2022)
ShareTwitterLinkedIn