How to Build Planning Agents Without Losing Control - Yogendra Miraje, FactSet

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.

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:

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.

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.

The architecture wraps enterprise microservices in tools, then routes a user question through four responsibilities:

1. Blueprint generator: produce a high-level plan for the requested workflow.
2. Planner: turn that blueprint into a low-level task plan.
3. Executor: execute the planned tasks.
4. 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.

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:

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.

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.

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:

{
  "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.

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:

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.

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.

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.

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.