In the previous article, I shared my reading notes on several survey-type papers to build a broader landscape view of augmented LLMs, GraphRAG, and tool learning. Those papers were useful because they provided context. They showed that modern LLM systems are moving beyond standalone text generation. LLMs are increasingly being augmented with retrieval, tools, external knowledge sources, graph structures, and orchestration mechanisms.
This article has a narrower purpose. I do not want to summarise another broad set of papers. Instead, I want to focus on a few papers whose ideas are directly relevant to the Agentic Semantic Layer of an AI-native financial data foundation.
The papers I will discuss are:
- ReAct: Synergizing Reasoning and Acting in Language Models
- MRKL Systems: A Modular, Neuro-Symbolic Architecture
- Toolformer: Language Models Can Teach Themselves to Use Tools
- Graph RAG-Tool Fusion
I am not trying to provide a complete academic review of every study, benchmark, or implementation detail in these papers. My aim is more selective: to extract the ideas that help explain why an AI-native financial data foundation needs an agentic orchestration layer above the semantic graph, canonical model, validation rules, lineage records, and source-system metadata. The key question is:
If an AI agent needs to work with financial data safely, what kind of orchestration pattern does it need?
Paper 1 – ReAct: from answering to reasoning and acting
The first relevant paper is ReAct: Synergizing Reasoning and Acting in Language Models.
The core idea of ReAct is that reasoning and acting should be interleaved. Instead of producing only a reasoning chain or only an action sequence, the model can reason about what it needs, take an action, observe the result, update its reasoning, and continue.
The pattern can be simplified as:
reason → act → observe → reason → act → observe → answer
This is highly relevant to an Agentic Semantic Layer.
In my AI-native financial data foundation design, the ReAct pattern becomes a semantic reasoning loop. The agent receives a user question, interprets the intent, decides which semantic capability is relevant, invokes that capability, observes the result, decides whether more evidence is needed, and finally synthesises an answer grounded in the collected results.
The pattern can be expressed as:
user question → identify intent → invoke semantic capability → observe result → continue or answer
This is different from simply retrieving a fixed set of documents and putting them into a prompt. It is also different from asking the LLM to generate a confident answer based on its own general knowledge.
The important point is that the action is not random tool use. The action is guided by the reasoning step, and the next reasoning step is grounded in the observation returned by the tool.
For example, if the user asks what a field means, the agent should resolve the concept. If the user asks where a concept is stored, the agent should search mapped fields. If the user asks whether a feed supports a use case, the agent should check readiness. If the user asks why a mapping is suggested, the agent should retrieve the semantic path and supporting evidence.
The lesson from ReAct is therefore not that financial systems should expose unrestricted tools to LLMs. The lesson is more controlled:
When the answer depends on external financial truth, the LLM should use governed actions to obtain evidence before answering.
In this sense, ReAct provides the first architectural pattern for the Agentic Semantic Layer: an iterative loop of reasoning, governed action, observation, and grounded response.
Paper 2 – MRKL Systems: the LLM should not own the truth
The second relevant paper is MRKL Systems: A Modular, Neuro-Symbolic Architecture That Combines Large Language Models, External Knowledge Sources and Discrete Reasoning.
MRKL stands for Modular Reasoning, Knowledge and Language. It proposes a neuro-symbolic system architecture. Instead of asking one large language model to do everything, the system combines language models with external knowledge sources and discrete reasoning modules.
In simple terms:
A MRKL system is an LLM-based router or orchestrator, connected to a set of specialist tools.
The LLM handles the language side. It understands the user request, decides what kind of capability is needed, routes the task to the right module, and explains the result.
The specialist modules handle things that should not be left to the LLM alone: database lookup, calculation, rule checking, graph traversal, API calls, symbolic reasoning, validation, or access to proprietary and current knowledge.
A simple non-financial example makes this clearer.
Suppose a user asks:
“What is the square root of the population of France?”
A pure LLM may try to answer from memory and easily make mistakes.
A MRKL-style system would split the task:
- Use a knowledge source or API to get the current population of France.
- Use a calculator module to compute the square root.
- Use the LLM to explain the result in natural language.
So the LLM is not the source of truth. It coordinates the right modules.
For an AI-native financial data foundation, the mapping is natural:
| MRKL idea | In the Agentic Semantic Layer |
|---|---|
| Language model | Understands the user question and orchestrates actions |
| Knowledge source | Semantic graph, financial registry, and source metadata |
| Reasoning module | Validation rules, readiness checks, and product decomposition |
| External tool or API | Concept resolution, field discovery, lineage tracing, and transformation support |
| Final language response | Grounded explanation for the user |
This is directly relevant to financial data. A financial data foundation already contains many forms of structured and governed knowledge: canonical data models, semantic repositories, product definitions, field mappings, validation rules, lineage records, source-system ownership, workflow states, and access controls.
It would be a mistake to collapse all of this into the LLM. The LLM may be useful for language understanding, intent recognition, planning, interaction, and explanation. But the source of financial truth should remain in governed structures and deterministic tools.
That is the main lesson I take from MRKL:
The LLM should not own the truth. It should orchestrate access to truth.
Paper 3 – Toolformer: tools as explicit capabilities
The third relevant paper is Toolformer: Language Models Can Teach Themselves to Use Tools.
If MRKL explains why an LLM should be connected to specialist modules, Toolformer helps explain how those modules become usable by the model.
The practical question is simple:
How does a language model know when to call a tool, which tool to call, what arguments to pass, and how to use the result?
This question is central to the Agentic Semantic Layer. In an AI-native financial data foundation, semantic capabilities need to be exposed as tools. Examples include concept resolution, field discovery, source-system lookup, product decomposition, readiness checking, validation, lineage tracing, mapping explanation, and transformation support.
These tools are not merely helper functions. They are the controlled interface through which AI agents interact with governed financial meaning. This is a shift in how we think about data architecture.
In a traditional data platform, the main interfaces may be SQL, dashboards, catalogue pages, reports, or APIs designed for human developers. In an AI-native platform, one of the main interfaces is a set of machine-readable tool contracts designed for AI agents.
A tool contract should define what the tool does, when it should be used, what inputs it accepts, what outputs it returns, what errors may occur, whether the tool is read-only or has side effects, whether the output is authoritative or advisory, and whether human review is required.
This is especially important in financial data. An incorrect tool call may lead to a wrong mapping suggestion, an incomplete readiness assessment, a misleading lineage explanation, or an unsafe downstream action.
Therefore, for the Agentic Semantic Layer, tool design should be treated as a governance problem, not only as a software engineering problem.
A concept-resolution tool should not return vague free text if the next step depends on the resolved concept. It should return a structured concept identifier, matched labels, confidence, context, and possible ambiguities.
A readiness-checking tool should not only return a natural language paragraph. It should return structured evidence: present concepts, missing concepts, concepts requiring review, readiness status, assumptions, and reasons.
A lineage tool should not merely describe a path. It should identify the source, transformation, target, relationship type, timestamp, and confidence of the lineage relationship.
A validation tool should clearly separate pass, fail, warning, missing data, and SME review.
This means semantic tools should produce structured outputs that the agent can reason over. The LLM should not have to guess the shape or meaning of the result. This gives a third design principle:
In an AI-native financial data foundation, tools are governed semantic contracts, not arbitrary functions.
The Agentic Semantic Layer depends on those contracts. They define what the agent is allowed to ask, what evidence it can receive, and how safely it can act on financial data.
Paper 4 – Graph RAG-Tool Fusion: tools have dependencies
The fourth relevant paper is Graph RAG-Tool Fusion.
This paper is particularly interesting because it connects tool use with graph structure. The problem it addresses is simple but important. Traditional RAG-based tool retrieval may find tools that look semantically relevant to the user question, but it may fail to capture the structured dependencies between tools.
In real workflows, tools are rarely isolated. One tool may require an input produced by another tool. A complete task may require a chain of tools. Some tools may depend on prerequisite checks, supporting metadata, permissions, or intermediate results.
In simple terms, Graph RAG-Tool Fusion suggests:
Do not retrieve tools only by semantic similarity. Retrieve tools together with their dependencies.
This idea maps very naturally to financial data.
Financial semantic operations are rarely isolated. A readiness check may identify missing concepts. Those missing concepts may become inputs to source-system discovery. An ambiguous field may require concept resolution before mapping can be explained. A validation failure may require lineage tracing. A transformation suggestion may require mapping evidence, validation rules, and target model context.
Consider again the question: Can this IRS feed support valuation?
A single tool may return a readiness status, but a useful answer often requires a chain of semantic operations. The agent may need to know which concepts are required for valuation, which of those concepts are present in the current feed, which are missing, which are ambiguous, where missing concepts may be sourced, which concepts require SME review, and what evidence supports the final conclusion.
This sequence forms a dependency chain. The output of one operation becomes the input to another. The missing concepts identified by readiness checking may drive cross-system source discovery. Ambiguous terms may require concept resolution. Mapping explanations may require graph traversal from source field to semantic concept to product component. Validation results may require lineage evidence.
Therefore, an Agentic Semantic Layer should not only expose individual tools. It should understand how semantic capabilities connect. This suggests that the Agentic Semantic Layer may eventually need to represent tools and their dependencies explicitly.
There may be a financial semantic graph that represents data meaning. There may also be a tool capability graph that represents what the agent can do, what each tool requires, what each tool produces, and which tools can follow from which results.
This gives a fourth design principle:
AI-native financial data workflows require graph-aware orchestration of semantic capabilities, not only isolated tool calls.
The agent should not simply ask, “Which tool looks relevant to this question?” It should also ask, “Which tools are required before this tool can be used responsibly, and which tools are needed to produce a complete, evidence-backed answer?”
The emerging architecture
Taken together, these four papers suggest a coherent architectural pattern for the Agentic Semantic Layer.
ReAct provides the behavioural loop: the agent reasons, acts, observes, updates its understanding, and then answers.
MRKL provides the modular architecture: the LLM is not the whole system. It is supported by external knowledge sources, symbolic structures, and deterministic reasoning modules.
Toolformer provides the tool-use perspective: semantic capabilities should be exposed as explicit tools with clear contracts.
Graph RAG-Tool Fusion adds the dependency perspective: tools are not always independent, and the output of one semantic operation may become the input to another.
For an AI-native financial data foundation, the resulting pattern is:
LLM as controller + semantic graph as reasoning substrate + governed tools as capabilities + tool dependencies as workflow structure + audit trail as governance.
This is the architectural direction behind the Agentic Semantic Layer. The key lesson is that an AI-native financial data foundation should not treat the LLM as a standalone reasoning engine. The LLM should orchestrate governed semantic capabilities grounded in the financial semantic graph, canonical model, validation logic, lineage metadata, and source-system registry.
This is the shift from AI-enabled to AI-native. An AI-enabled data platform may let users ask natural language questions over existing data. An AI-native financial data foundation allows agents to reason over financial semantics, invoke governed tools, trace evidence, and produce auditable answers.
In the next article, I will move from tool-using orchestration to graph-grounded reasoning and evidence checking, where graph traversal, GraphRAG, adaptive retrieval, and self-correction become central to the design.
References
Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv preprint arXiv:2210.03629. DOI: 10.48550/arXiv.2210.03629.
Karpas, E., Abend, O., Belinkov, Y., Lenz, B., Lieber, O., Ratner, N., Shoham, Y., Bata, H., Levine, Y., Leyton-Brown, K., Muhlgay, D., Rozen, N., Schwartz, E., Shachaf, G., Shalev-Shwartz, S., Shashua, A., & Tenenholtz, M. (2022). MRKL Systems: A Modular, Neuro-Symbolic Architecture That Combines Large Language Models, External Knowledge Sources and Discrete Reasoning. arXiv preprint arXiv:2205.00445. DOI: 10.48550/arXiv.2205.00445.
Schick, T., Dwivedi-Yu, J., Dessì, R., Raileanu, R., Lomeli, M., Zettlemoyer, L., Cancedda, N., & Scialom, T. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv preprint arXiv:2302.04761. DOI: 10.48550/arXiv.2302.04761.
Lumer, E., Basavaraju, P. H., Mason, M., Burke, J. A., & Subbiah, V. K. (2025). Graph RAG-Tool Fusion. arXiv preprint arXiv:2502.07223. DOI: 10.48550/arXiv.2502.07223.
Data Ninjago (Financial Data Architecture) 