Agentic workflows let an agent plan and run a dynamic workflow while keeping more structure than a fully autonomous agent.
2
A blueprint gives the planner a high-level, natural-language task breakdown and limits the tools and context it receives.
3
Agentic workflows need component evals, end-to-end evals, safety checks, and observability, and they are a poor fit for fixed, safety-critical, or low-latency tasks.
Summary
Yogendra Miraje explains how to build plan-and-execute agents that retain some of the control of conventional workflows. He distinguishes a workflow agent, where the workflow is predefined and in control, from an agentic workflow, where the agent plans and runs a dynamic workflow. His design uses a blueprint generator, planner, executor, and joiner, with replanning and recursion limits. The blueprint breaks a goal into natural-language steps, selects the tools the planner needs, and makes the agent's behavior easier to inspect and discuss with nontechnical colleagues. Miraje uses financial research for an earnings call as an example. He also stresses that tools must be designed around the agent's point of view, with clear purposes, descriptions, input-output contracts, and validation checks. Evals should cover blueprints, tool selection, plans, and report formatting with code-based checks, LLM judges, and human review where appropriate. He is clear that fixed, deterministic, safety-critical, and low-latency workflows may not justify this approach.
Agentic workflows combine planning flexibility with workflow structure
Miraje separates three concepts that are often mixed together. An augmented LLM combines a language model with tools and memory. A workflow places that system on a static, predefined path. An agent adds autonomy and a feedback loop. A workflow agent is an agent running a predefined workflow, so the workflow remains in control. In an agentic workflow, the agent plans and runs a dynamic workflow based on the goal, context, and feedback. This gives enterprises more flexibility while preserving a structure that can use existing microservices.
Planning by subgoal division turns a broad goal into executable work
Miraje says teams building agentic workflows need tools, memory, and reflection, along with planning by subgoal division. The pattern means taking a goal and breaking it into simpler steps. He points to plan-and-execute architectures and describes adapting the LLM Compiler architecture. In his design, a blueprint generator creates a high-level plan, a planner turns it into lower-level tasks, an executor runs those tasks, and a joiner combines their outputs. The system can replan or finish, and a recursion limit helps prevent loops.
Tools should expose enterprise microservices in terms an agent can use
The relationship between tools and enterprise microservices is not one-to-one. Teams choose how to shape tools around their services so the agent understands how to use them. Miraje recommends building MCP tool servers and giving every tool a purpose, a detailed description, and input-output contracts. The purpose helps with selection. The description explains when to invoke the tool. The contracts explain how to call it. Validation checks provide a brake when the agent produces an invalid request or result.
A blueprint reduces planner overload and makes behavior easier to control
A blueprint is a natural-language series of workflow steps based on available tool capabilities. Miraje introduced it because the planner became cognitively overloaded when it had to handle too much at once. The blueprint gives the planner a high-level breakdown and limits which tools enter its context. That helps with context-window limits and excessive tool descriptions. It also makes the agent's behavior easier to interpret and gives nontechnical collaborators a less intimidating way to review task planning.
An earnings-call workflow shows how blueprints connect tasks to function calls
Miraje uses preparing for an NVIDIA earnings call as a simplified financial-research example. The blueprint first asks for a summary of NVIDIA's previous earnings call, then retrieves financial data. The system reasons over that information to suggest questions for the call and finally generates a comprehensive report. The blueprint presents tools and tasks in natural language, while the plan contains the corresponding tools and function calls. Context from one task is passed into the next. The result is more structured than a basic, unplanned response.
Evals should test each part of the agent as well as the whole workflow
Miraje says the architecture will not work without a maintained eval framework. Teams should write component and end-to-end evals for the metrics they actually care about. For a blueprint, an LLM judge can assess whether it resembles a golden blueprint. Code-based evals can check whether the right tools were selected. An LLM judge can assess whether the plan follows the blueprint. Human review can be useful for report formatting. He also calls for safety guardrails, observability, and standard software engineering practices.
Some workflows should stay deterministic instead of becoming agentic
Miraje gives several cases where agentic workflows are a poor choice. Fixed and repetitive work is better handled by ETL pipelines. An agentic workflow is also a weak fit when the use case cannot be captured as a workflow. Teams should avoid it when a deterministic outcome is required, including strict-compliance and safety-critical settings. Low-latency and low-cost environments are another reason to choose a simpler design. His advice is to start with simple blueprints and add complexity only when the use case supports it.
MCP and orchestration frameworks will coexist according to the use case
In the question period, Miraje describes MCP as a way to provide a standard across an organization. A team can build functionality once and reuse it across different AI applications through an MCP server. He considers LangGraph useful for orchestration, while leaving room for other frameworks. His answer is that several technologies will be useful, and the best choice depends on the problem and the most suitable framework for that use case.
"So whatever we talked about none of this will really work without writing a proper evals."10:42
Who should watch
You are building plan-and-execute agents and need a way to limit planner context, tool access, or runaway loops.
Your agent must use existing enterprise microservices, and you need guidance on turning those services into tools with clear contracts.
You are deciding whether an agentic workflow is appropriate for a fixed, safety-critical, cost-sensitive, or low-latency process.
