AI Engineer World's Fair 2025
How to Build Planning Agents Without Losing Control - Yogendra Miraje, FactSet
Read the talk
How to Build Planning Agents Without Losing Control
A natural-language blueprint can give an enterprise agent room to plan while keeping its tools, task dependencies, and evaluation criteria explicit.
From a talk by Yogendra Miraje
Before you start: Familiarity with LLM tool calling and basic service APIs will help; the article introduces the planning and workflow terminology.
Capability exceeds control
Building AI applications can feel like driving a monster truck through a crowded mall with tiny joysticks. The model has considerable power; the developer has surprisingly little control over how it behaves. Yogendra Miraje, working at FactSet, a financial data and software company, uses this mismatch to explain why he believes AI applications have yet to experience their own ChatGPT moment despite rapid improvements in model intelligence.
One source of that mismatch is missing context. In an enterprise, the missing information is often knowledge of the organization's workflows: what needs to happen, in what order, and with which capabilities. A capable model cannot reliably follow a business process it has never been given.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Who controls the workflow?
Tools extend what an LLM can do beyond its training-time knowledge. Combine an LLM with tools and memory, and Miraje calls the result an augmented LLM. Put it on a static, predefined path, and it becomes a workflow. Give it substantial autonomy and a feedback loop, and it becomes an agent. Workflows offer control and reliability; agents offer flexibility and autonomy. An agentic workflow aims to combine those properties by planning and executing a workflow according to the goal, context, and feedback.
The distinction rests on who decides the path:
| System | Who controls the path? | Workflow |
|---|---|---|
| Workflow agent | Predefined workflow | Static; run by an agent |
| Agentic workflow | Agent | Dynamic; planned and run by the agent |
These are Miraje's working definitions, useful because the terms are often used interchangeably. He also invokes Andrew Ng's view of agentic systems as a spectrum: an agentic workflow generally sits farther toward autonomy than a workflow agent.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Reuse enterprise services, then plan around them
For enterprises, the attraction goes beyond predictability. Agentic workflows offer a way to automate processes while building on existing microservices—capabilities that may represent years or decades of investment. The agent layer can compose those services instead of requiring the organization to replace them. Although the examples here concern enterprises, the architecture applies more broadly.
Miraje recommends moving from a predominantly ReAct-based approach toward proactive planning. ReAct already supports tracking and updating plans through interleaved reasoning and action; the architectural change here is to make task decomposition an explicit stage. Alongside tools, memory, and reflection, introduce planning by sub-goal division: break the goal into simpler steps that the system can execute.
Different planning architectures make different tradeoffs. Miraje recommends LangChain's explanations and accompanying code; its Plan-and-Execute Agents article provides relevant implementation reading. At FactSet, his team adapts LLMCompiler to its own problems, adding a high-level planning stage before the task planner.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From a user question to a replanning decision
The architecture wraps enterprise microservices in tools, then routes a user question through four responsibilities:
- Blueprint generator: produce a high-level plan for the requested workflow.
- Planner: turn that blueprint into a low-level task plan.
- Executor: execute the planned tasks.
- Joiner: combine the outputs from those tasks.
The blueprint describes the intended work before the planner commits to the details of individual calls.
After the joiner, replanning logic determines whether the system should take another pass or terminate and return a response. A recursion limit can bound the loop so the agent does not continue indefinitely. FactSet implements the blueprint generator, planner, executor, and joiner as separate LangGraph nodes. The graph makes both the forward execution path and the return path for replanning explicit.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Design tools from the agent's point of view
Miraje expects much of the implementation effort to go into building tools around enterprise microservices. Their relationship is many-to-many, not necessarily one tool per service. A tool interface should reflect the work an agent can understand and perform, rather than simply copying the organization's service boundaries. The design question is whether the agent has enough information to choose and use the capability correctly.
An MCP tool server provides a standard interface for those capabilities. Within that interface, different pieces of documentation answer different questions:
| Tool information | Agent's question |
|---|---|
| Purpose | Which tool should I select? |
| Detailed description | When should I invoke it? |
| Input/output contracts | How do I use it? |
Here, input/output contracts are interface-design requirements. The historical March 2025 MCP specification defines inputSchema and returned result content, but not an outputSchema field. Validation checks complete the interface by acting as brakes on incorrect tool use.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the planner a blueprint
A blueprint is a sequence of natural-language workflow steps matched to available tool capabilities. It is fed to the planner rather than executed directly. FactSet introduced this stage after finding that the planner became overloaded when asked to handle too much at once. Decomposing the task in natural language separates deciding what work is needed from specifying the low-level calls.
The blueprint also provides finer control over task planning by narrowing the tools placed in the planner's context. Large collections of tool descriptions consume the context window and burden tool selection. The blueprint stage can select the relevant tools, leaving the planner with a smaller set of capabilities appropriate to the workflow.
That intermediate representation makes agent behavior easier to interpret. It also gives nontechnical collaborators something they can discuss directly: natural-language steps are less intimidating than a collection of function calls. The same artifact therefore helps constrain planning and expose the intended business process for review.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Preparing for NVIDIA's earnings call
Preparing for a company's earnings call is a common financial research workflow. Miraje demonstrates a deliberately simplified version for NVIDIA. The blueprint pairs a tool with a task; the executable plan pairs a tool with a function call. He describes two tools in the blueprint, supporting a sequence of four tasks.
The workflow first summarizes NVIDIA's previous earnings call, then retrieves financial data for the company. It uses that material to suggest questions for the upcoming call and finally generates a comprehensive report. Task context passes into the corresponding function calls, allowing later work to use earlier results.
A compact JSON representation makes the intended dependencies explicit. The identifiers below describe a proposed plan, with context_from naming earlier task outputs that a later step will need:
json
{
"company": "NVIDIA",
"status": "planned",
"steps": [
{
"id": "previous_call",
"task": "Summarize the previous earnings call",
"context_from": []
},
{
"id": "financial_data",
"task": "Retrieve company financial data",
"context_from": []
},
{
"id": "questions",
"task": "Suggest questions for the upcoming earnings call",
"context_from": ["previous_call", "financial_data"]
},
{
"id": "report",
"task": "Generate a comprehensive preparation report",
"context_from": ["previous_call", "financial_data", "questions"]
}
]
}
This representation illustrates the task-context relationship; the planner's next responsibility is to bind the work to tool calls and their input contracts.
In the displayed response comparison, Miraje describes the original answer as generic and the answer after introducing the agentic workflow as structured around the financial research process. The useful change is that the response reflects the requested workflow, rather than merely supplying a broadly relevant answer. This is a qualitative demonstration; no numerical improvement is reported.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Evaluate the behavior you need to control
The architecture needs an evaluation framework that is built and maintained alongside it. Miraje calls for both component evaluations and end-to-end evaluations, using metrics that matter to the application. Evaluating individual stages helps locate failures; evaluating the complete workflow checks whether those stages together produce the desired result. Code-based checks, LLM judges, and human review serve different purposes.
Choose the method according to the aspect being tested:
| Aspect | Suggested evaluation |
|---|---|
| Blueprint resembles a golden blueprint | LLM-as-a-judge |
| Correct tools selected | Code-based checks |
| Plan follows the blueprint | LLM-as-a-judge |
| Report formatting | Human review |
A single overall score can hide which part of the system failed. These separate checks distinguish an unsuitable workflow from incorrect tool selection, a plan that departs from the blueprint, or an unsatisfactory presentation of the results.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
When planning is the wrong choice
The ability to plan dynamically is not useful in every application. Miraje identifies several cases where an agentic workflow is a poor fit:
- Fixed, repeated tasks: an ETL pipeline is probably the better choice.
- Work that cannot be captured as a workflow: the architecture has little useful process structure to operate on.
- Deterministic outcomes: strict compliance or safety-critical requirements may rule out agentic planning.
- Tight latency or cost constraints: the planning architecture may not fit the operating budget.
These boundaries belong in the architecture decision before investing in a planner and its supporting infrastructure.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Start with simple blueprints
Start with simple blueprints and work toward a more complex retrieval-augmented system for blueprints as the need develops. The immediate job of the blueprint remains concrete: supply the high-level plan and reduce the tools in the planner's context. Keep tool usage simple, and build safety guardrails, evaluations, and observability into the system.
The reliability at scale that Miraje seeks depends on this combination of task decomposition, plan-and-execute architecture, and tools that complement existing microservices. His own blueprint stage is an example of adapting a research architecture to the problem rather than treating it as fixed. Experiment with those architectural changes, but make evaluations first-class components so there is a basis for judging whether the changes help.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Implementation references and orchestration choices
Asked for a GitHub project or implementation reference, Miraje points back to LangChain's planning-agent material and its code for the research architectures. The reference slide groups Plan-and-Solve, ReWOO, and LLMCompiler as starting points for exploring plan-and-execute agents.
The final question asks whether MCP, LangGraph, or another approach will become the primary orchestration method. Miraje's answer separates two complementary jobs. MCP provides an organizational standard for exposing functionality: wrap a shared capability once, then reuse it across different AI applications.
LangGraph handles orchestration—the arrangement of planning, execution, and feedback inside an application. Miraje regards it as a useful choice while expecting multiple frameworks to remain useful. Standardizing tool access does not require every application to use the same orchestration framework; the appropriate framework depends on the use case.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The research architecture behind LLMCompiler's dependency-aware planning and parallel function execution.
The original ReAct paper explains how interleaved reasoning, actions and observations support interactive task solving.
Further reading
- Plan-and-Execute AgentsArticle
LangChain's guide to plan-and-execute, ReWOO and LLMCompiler architectures, with links to implementations.
Original implementation with setup instructions, benchmark runners and examples for configuring custom tools.
Historical protocol reference for exposing tools, defining inputs, returning results and enforcing validation.
Miraje's earlier explanation of enterprise data retrieval, semantic metadata and domain knowledge for financial-data assistants.
Updates since the talk
Current introduction to LangGraph's orchestration runtime, including a minimal graph example.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hi everyone, I'm Yogi.
- 0:17
I work at FactSet, a financial data and software company. And today I'll be sharing some of my experience while building agent.
- 0:27
In last few years, we have seen tremendous growth in AI, and especially in last couple of years, we are on exponential curve of intelligence growth.
- 0:38
And yet, it feels like when we are develop AI applications, driving a monster truck through a crowded mall with the tiny joysticks. So AI applications have not seen its ChatGPT moment yet.
- 0:53
There are many reasons why agents don't behave, but probably one reason that strikes out is it misses the right context.
- 1:04
And in case of enterprises, often it means that it does not have knowledge of enterprise-specific workflows.
- 1:13
But before that, we will see some common context, and just like agents, human also need a common context. So let's start with some key definitions.
- 1:24
So as you know, LLMs are limited by the knowledge at the time of training, so we enhance their functionality by
- 1:34
increase it by tool. And when you combine this LLM with tool and memory, we call it augmented LLM. When you place this augmented LLM on a static and predefined path, we call it a workflow.
- 1:48
And if these augmented LLMs have high autonomy and feedback loop, we call it as an agent.
- 1:56
Now, workflows are controllable and reliable, while agents have flexibility and they are highly autonomous. So the question is: Can we get best of both worlds? So the answer is yes.
- 2:09
With agentic workflows, we can plan and execute the workflows based on the goal, context, and feedback.
- 2:19
I see these terms being used very loosely and at times interchangeably, so I would like to make a key distinction between workflow agent and agentic workflow.
- 2:32
Workflow agent is a predefined workflow run by agent,
- 2:37
while agentic workflow is a workflow planned and run by an agent.
- 2:44
I know these terms are, like, quite confusing and in AI we are very bad at naming things, so if you are confused, don't worry. In case of workflow agent, just remember that workflow is in control and workflow is static.
- 2:58
In case of agentic workflow, agent is always in control and the workflow is dynamic.
- 3:07
It is also important to view these systems, uh, as agentic system, as Andrew Ng pointed out correctly. On agentic spectrum, agentic workflows have more agenticness than workflow agents, generally speaking.
- 3:25
So why all of this matter? Apart from control, reliability, predictability for enterprises, agentic workflows provide a way to automate the workflows at scale. And perhaps most important thing is
- 3:45
enterprises can use their existing enterprises, uh, microservices to build on top of it. And in some cases,
- 3:55
these enterprises have invested years, not, uh, if not decades.
- 4:02
So before diving deep, I would like to say that even though I'm speaking in terms of enterprise context here, the concepts are generally applicable.
- 4:11
So where do we begin? In last few years, the focus really has been on the react-based agent. And in building agentic workflow, we need to move on from react-based agent to proactive agents.
- 4:25
By the way, great philosophy for life as well.
- 4:30
So for building agentic workflows, you need tools, memory, and reflection. But more importantly, you will need a design pattern called planning by subgoaledivi-- subgoaled division,
- 4:46
sometimes also referred as a task decomposition. And it is just a fancy way of saying that take your goal and break it down into simpler steps.
- 4:57
Here are some specific agentic architecture and research papers that you will find useful, and each of that has, like, its own pro and cons. And LangChain has done fantastic job of, uh, creating a blog from this and, uh, also gi-given the code.
- 5:14
So I highly recommend checking it out. So how does it look in practice? So what-- In, uh, in FactSet what we have done is we are taking this LLM compiler architecture and trying to adapt for our problems.
- 5:29
And you can see some components here, uh, that you also find that in your organization, uh, microservices, and you build tools around those microservices. And when a user question ask, it goes to blueprint generator, and I will get to that in a bit.
- 5:45
But consider it as a, like a high level plan.
- 5:49
What we call it is a blueprint that gets fed to planner. Planner is your low-level task planner. It gives the plan to the executor, and executor is supposed to execute it.
- 6:03
And joiner combines the outputs from different tasks.
- 6:09
Based on your replanning logic, either you do replanning again or you just, like, terminate and give the response back to the user.
- 6:18
Sometimes you also set some recursion limits so that your agent just, like, doesn't go into loop.
- 6:24
On LangGraph, we are using each of these component as a nodes. So blueprint generator, planner, executor, and joiner are all nodes on the LangGraph.
- 6:37
When building these, uh, tools in, in your enterprises a-around microservices, probably this is where you will spend most of your time.
- 6:47
And it's important to consider how this relation between tools and microservices goes. And here, the relationship is definitely not one-to-one or end-to-end, it's m-to-n. It's up to you how you want to design your tools according to your microservices so that your agent knows how to use this tool.
- 7:07
Perhaps this is, like, the most key point here that you need to make, really put yourself into agent's shoes so that agent really understand what tool to use, and it has that knowledge of your microservices.
- 7:22
Always follow standard. I know MCP is everyone's favorite, so build a MCP tool server for your tools. And for providing the tool details, just think from agent's point of view that you need to provide a tool purpose, description, and input/output contracts.
- 7:40
So tool purpose will help you what tools to be selected, tool detail description will tell you when these tools need to be invoked, and input/output contracts will tell you how to use this tool.
- 7:53
And lastly, add some validation checks which acts as a break for your agent.
- 8:00
Now, I would like to a little bit zoom in into this blueprint, uh, because this is, like, one of the key architecture change that we made. A blueprint is just a series of steps for workflow as per tool capabilities in natural language.
- 8:15
And it gets fed to planner, but why we are doing it? So what we realized was,
- 8:23
planner really gets cognitively, uh, loaded, uh, when you try to just put too much onto it. So introducing a blueprint, which is just a natural language of breaking down of a task, is very helpful.
- 8:38
But we also notice that it brings a lot of other benefits as well. For example, it achieves the finer control over task planning. It limits the in-context tool for the planner.
- 8:50
So when blueprint, you can select what tools to be... need to be given to the planner, and sometimes this, uh, planners has lot of tool description, and you run all sort of problems as context window limit and planner gain, uh, getting very much overloaded.
- 9:09
So using blueprint, you can limit what tools really goes to the, uh, planner, and thus, uh, it really helps in, in the planning.
- 9:21
It also helps interpreting the agentic behavior. And lastly, when you need to collaborate with non-technical, uh, people, it's, like, really helpful because natural language is less intimidating.
- 9:34
Let's see a concrete example. So in financial research, preparing for an, uh, company's earnings call is a common workflow. So this is a very, very simplified version of a workflow of preparing for a company's earnings call.
- 9:50
And for example, we are showing you preparing for NVIDIA's earnings call.
- 9:55
Now, you can see in the blueprint, there is a tool and there is task, and in the plan, there is tool and the function call.
- 10:03
So how does it look in, in the blueprint is you have two tools, and then your first step is summarizing the NVIDIA's previous earnings call. And the next step is retrieval, gathering some of the financial data from, uh, for NVIDIA.
- 10:17
And then your reasoning, suggesting some questions for the earnings call. And finally, reporting, uh, generate a comprehensive report from the all the information.
- 10:26
And there are corresponding function calls, and as you can see, context is being fed from a task.
- 10:34
A, a concrete, uh, example of the response is before you implement agentic workflow, the response is very much vanilla. But after this, it can easily capture your workflow and give a very structured response.
- 10:49
So whatever we talked about, none of this would really work without writing a proper evals. So always make sure to invest and build and maintain your eval framework. You should have at least component and end-to-end evals.
- 11:04
You should really use the correct techniques like code-based, LLM-as-a-judge, human-in-the-loop. And more importantly, write evals for metrics that you really care for.
- 11:15
Aspect-based eval is something like we should really, uh, think about. And for example, for blueprint, uh, you can check an aspect like how many, uh, blueprint, whether it resembles a golden blueprint or not, and you can use LLM-as-a-judge.
- 11:31
If you want to see whether tools are selected correct or not, you should leverage code-based evals.
- 11:37
If you want to check whether plan is in line with the blueprint or not, LLM-as-a-judge probably the right technique. And for some cases, leveraging human-in-the-loop is good because report formatting, uh, that's the best approach to deal with report formatting.
- 11:55
So when not to use agentic workflows. So in some cases, definitely agentic workflow doesn't make sense. In case of fixed and repeated task, just probably go for ETL pipelines.
- 12:06
If your workflow cannot be really captured, uh, you cannot really capture use case in workflows, agentic workflows are probably not worth. And if deterministic outcome is paramount in cases of strict compliance and a safety-critical context, uh, you should probably n- should not go with agentic workflow.
- 12:24
And in case of la- low latency and cost-constrained environment also, uh, you should probably try to avoid agentic workflow.
- 12:32
So wrapping up, some learnings. Um, start with simple blueprints. Work wir- work, uh, work wire way up, uh, building a complex rack system for the blueprints. Use blueprint to reduce the in-context, uh, tools and provide the high level plan to the planner.
- 12:52
Design tools from agent point of view. Um, always aim for the tool usage simplicity. Implement safety guardrails and evals observability and all the good software engineering, uh, that should, uh, help you a lot.
- 13:11
And from the whole, uh, presentation, the key takeaways are agentic workflow is planned and run by agent. Agentic workflows bring the reliability
- 13:21
at scale, and planning by sub-goal division is a key design pattern. Plan-and-execute is a key agentic architecture.
- 13:30
And build your tools to complement your microservices. Always try to leverage your microservices in the tools, and modify your architecture to solve the problems. Don't really shy away from changing, taking research paper and experimenting on it.
- 13:49
And finally, treat your evals like first-class citizen.
- 13:54
And with that, thank you very much for your time. [audience applauding]
- 14:02
All right. Uh, thank you. Any questions? We have a little bit of time to spare.
- 14:09
I have a question.
- 14:09
Sure.
- 14:10
Um, do you, um, have, uh, in top of your mind any like, uh, GitHub project or reference that we can follow?
- 14:19
Sure, sure. So if you just go back here, um, I kind of, uh, shared some of the
- 14:28
links, um, for the LangChain. It ha- it should have all the code for this research paper, and that's probably the most, you know, best place to start with this plan-and-execute kind of agents.
- 14:42
Thank you.
- 14:43
Yeah.
- 14:46
Any other questions? Uh, all right. Um-
- 14:52
Yeah.
- 14:52
I guess one question I would have for you-
- 14:53
Sure
- 14:54
... is the... When you talk about MCP and other forms of orchestration, what do you foresee being the, the primary method of orchestration going forward? Is it gonna be LangGraph or some other...
- 15:07
Yeah, I think the answer is probably, like, everything. MCP, you use it so that you provide a standard across the arc, and MCP will really help for organization to, you know, build once, use it everywhere.
- 15:21
Uh, you can have... Oftentimes in organizations we see that, uh, people just like trying to just use this functionality in different AI apps. But if you can build an MCP around it, you can keep using it.
- 15:33
And obviously for orchestration, LangGraph is great, and whatever the other tools that you find to solve your problem, that will be also. Um, so the answer is probably there will be like multiple things that is useful.
- 15:45
It depends on your use case, what is the, uh, most optimal framework that you want to use.
- 15:50
Amazing. Thank you so much, Uri. [outro music]