Juan Luis DomÃnguez
AI Engineer
September 15, 2026
In research the hop worth taking is usually the one nobody anticipated. Whoever read the first document is in the best position to pick the second one.
The second argument compounds over time. Every branch condition you hard-code is a judgement you made on the model's behalf, fixed at the moment you made it. Every decision you leave to the model gets better on its own as the models do.
> Leave a decision to the model and it gets better at that decision for free.
We have run this system through several model generations. The decisions we left to the model improved without us touching them. The ones we hard-coded are the ones we have since rewritten.
So the agent works out the detail of the path. That puts the whole load on the rest of the list, because the path is no longer the thing holding a run together.
## What a Workflow declares
Every item on that list can be fixed up front without fixing the path, and that is what a Workflow template does.
You set out what the run needs before it starts, such as a list of companies and a date range. Next quarter you fill in the same fields with new values, instead of rewriting the instructions and hoping you phrased them the same way as last time. You give it a research plan, which lists the questions this kind of analysis has to ask. You set which sources it may search, and this is the part finance users reach for first, because the run then cannot go outside the sources you accept as evidence. You also say what a finished answer has to contain, such as a summary, a table of figures and a list of risks.
What you do not declare is how many searches to run, whether to delegate, or when the work is done.
The template owns the context and the procedure. The agent owns the execution. A run is fixed in the ways that make it comparable and free in the ways that make it useful.
Our [docs](/how-to-guides/agents/workflows/creating_templates) list everything a template can set, with worked examples, and there is a library of [example templates](/how-to-guides/agents/workflows/example_templates) covering what people build most.
### The orchestrator is where the plan runs
For anything spanning several companies or several angles, one agent orchestrates and the rest do the work. The orchestrator has no research tools. It cannot search, read a filing, or run code. It has a planning tool and a delegation tool and nothing else. We got this wrong the first time. An orchestrator that can do the work will do the work, fill its context window with raw tool output, and lose track of the plan it was supposed to be running. Each delegation opens a subagent with a clean context window and one part of the plan.
## Resolving the company comes first
Two runs are only comparable if "NVIDIA" means the same thing in both.
In finance it frequently does not. A ticker is not a company. A company is not its listed parent, or its subsidiaries, or the entity that actually issued the debt you are analysing. Names collide, tickers get reused, companies rename and merge and spin off, and the same firm appears under four different strings across a transcript, a filing, a news wire and a broker note. An agent that resolves those strings loosely will produce an answer that looks right and is about the wrong company, and there is no way to tell from the output.
RavenPack has been solving this since long before any of it was agentic, and the rest of the system is built on it. We resolve the company once, against the knowledge graph, and every tool then takes that resolved id rather than the string the user typed. Search, transcripts, filings, tearsheets and the calendar all take the same id.
A whole class of failure then disappears. When the agent asks for the filings of an id rather than the filings of "Volkswagen", it cannot hand back Volkswagen Financial Services when you meant Volkswagen AG, and you can prove that the sources it returns are about the company the user asked for. You can also audit the run afterwards, because the company a claim refers to is a resolved id and not something inferred from the surrounding text.
The rest of the tools follow the same idea. Our earnings calendar returns the dates, the EPS figures and the links to the transcript and filings for each one, and it already knows the company's fiscal calendar. The agent never has to search for a document it could have been handed, or guess whether "the latest quarter" means the fiscal one. If you know something about how research in your field works, put it in the tool result.
If you are building agents over financial data, build this part first. It is the cheapest piece of infrastructure described here and it has prevented more wrong answers than anything else we have shipped.
## Grounding: every claim points at a source
Every sentence in a finished answer is tied to the document it came from. Because the path is not fixed, a run uses whatever sources it turned out to need, found as it went, sometimes across several agents. We cannot wire up attribution in advance. It has to be built while the run happens, which means what gets recorded is what the run actually did.
We register every tool result as it comes back, along with the individual references inside it, such as the specific chunk of a transcript or the specific passage of a filing. As the model writes, it marks the text it is supporting and names the sources it used. We resolve those marks against what was registered during that run and turn them into citations while the answer is still streaming. A mark that does not resolve to something the run retrieved never becomes a citation.
So the agent cannot cite a source it did not read. The only things it can cite are results of tools that ran. What the answer claims about its own sources is checked against what the run did, rather than taken on trust.
The grounding data also stays with the conversation. A follow-up question three turns later can resolve a citation from the first turn without re-running the tool that produced it, and a user clicking a reference in an answer from last week still lands on the passage it came from.
### A side effect: citations are also how the agents talk
We did not plan this next part. Once the grounding data exists while the run is going, it becomes the obvious thing to pass between agents.
Most multi-agent systems pass summaries. A subagent finishes, writes a paragraph about what it found, and hands the paragraph up. That works, but it loses the sources at the point where you need them. The orchestrator now believes something it cannot attribute. Ask it to cite that claim later and it will either invent a source or re-fetch everything the subagent already read.
So we pass sources instead of prose, in both directions. A subagent inherits the orchestrator's sources with the content attached, so it can build on what has been found rather than search for it again. When the subagent returns, we attach its citations to the message the orchestrator receives. The orchestrator can then quote a passage it never read itself, in any later turn, and nobody has to trust a summary.
## Python instead of more tools
The third piece follows from the same decision to leave judgement with the model.
Model coding ability has improved faster than any other capability we depend on. Two years ago, giving a research agent a Python interpreter meant supervising it. Now the code is routinely better than what we would have written for the same task, and it is written in the moment, for the specific question, against the specific data.
That changes what a tool is for. When an agent cannot do something, the instinct is to add a tool. But every tool is something you design, name, describe and maintain, and it takes a slot in a list that gets worse as it grows. You can also only add tools for the analyses you thought of.
So our most useful tool contains no analysis at all. The agent writes Python against a library that exposes the platform, including prices, financials, company data, search, entity lookup, holdings and charting. It can pull a price series, join it to a screen result, compute the metric nobody built a tool for, and chart the output. None of that had to be anticipated, and the tool list did not grow.
Handing an agent an interpreter only works if the interpreter can reach your data and nothing else. The two easier answers both fail. A shell on real infrastructure gives the model a way to send data out. An approval prompt on every action gives you a product nobody uses.
This is what works for us. The code runs in a sandbox with no credentials the model can read and no general route out. It reaches our platform only through libraries we upload into the session. Every call those libraries make goes through one shared layer, which attaches a service key the model never sees, applies the requesting user's own entitlements, and records what the code consumes. Adding a new capability means writing a self-contained package and one line in a registry. The new package gets all of that without its author touching any of it, so a data scientist who knows a dataset can put it in front of every agent without going near the security code.
## Where this leaves us
Reproducibility turned out to rest on four things that are true about a run: what it was asked, who it was about, what it was allowed to look at, and what it can prove. Pin those four and you can leave the rest to the model. The rest is also the part that gets better on its own every time the models do.
***
## About Workflows
Workflows turn a research procedure into something you can run across your whole coverage universe, with every claim tied to the document that produced it. Start with [creating a template](/how-to-guides/agents/workflows/creating_templates), or take one from the [example templates](/how-to-guides/agents/workflows/example_templates) and edit it.
***
Juan Luis DomÃnguez
AI Engineer