Analyzing Agent Workflow Dependencies and Failure Points

Introduction

In our last lesson, we mapped the communication and control pathways of our agentic system, defining the inputs, outputs, and handoff points between agents. We saw that these handoffs are critical junctures where failures like context loss and misinterpretation can occur.

Today, we elevate that analysis from a simple awareness of risk to a systematic, engineering-grade methodology for proactive failure identification. The learning outcome for this lesson is to identify dependencies and potential failure points in a proposed agent workflow from the specification alone. We will treat our design documents—the Product Requirements Document (PRD), agent specifications, and information flow maps—as blueprints for a system that we can debug and harden before it is built.

To achieve this, we will adopt a powerful framework from classical systems engineering and manufacturing: Failure Mode and Effects Analysis (FMEA). This structured approach will allow us to dissect our agent workflow, component by component, identify what could go wrong, and understand the downstream consequences.

1. A Framework for Proactive Risk Assessment: FMEA

Failure Mode and Effects Analysis (FMEA) is a step-by-step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product or service. Given your background, you can think of it as a formal process for "red teaming" your own system design.

While traditionally used for physical systems, FMEA is remarkably well-suited for the probabilistic and non-deterministic nature of agentic AI. It forces us to move beyond hoping for the best-case scenario and instead design for failure.

The core takeaway is that we must treat our agentic architecture as a system with components that can and will fail. Our job as designers is to anticipate these failures and their cascading effects. FMEA gives us the structure to do this rigorously.

2. Decomposing the System for Analysis

To apply FMEA, we first need a clear breakdown of the system into analyzable parts. Just as you would analyze a software system by its modules, classes, and functions, we will analyze an agentic workflow by its core components.

This gives us a structured way to analyze our design specifications. For any proposed workflow, we can now examine it through the lens of these eight components:

1. User/System Prompting Layer: The static instructions.
2. Model Layer: The behavior of the core LLM.
3. Chunking & Indexing Layer: How knowledge is prepared.
4. Vectorization/Embedding Layer: How knowledge is represented mathematically.
5. Vector DB/Retrieval Layer: How knowledge is recalled.
6. Orchestration/Agent Controller: The logic that routes tasks and data.
7. Document Update/Ingestion Layer: How the knowledge base is maintained.
8. Tooling/Action Execution Layer: How the agent interacts with the outside world.

This lesson focuses on Design FMEA (DFMEA), which, as the article notes, analyzes failures inherent in the static configuration and logic of the agent. We are stress-testing the blueprint.

3. A Taxonomy of Agentic Failures

We now have the components to analyze. Next, we need a precise vocabulary for the failures that can occur within them. A vague notion of "it might fail" is insufficient; we need a detailed classification of failure modes.

To get the granular detail needed for a PhD-level analysis, we will go to the source research paper that produced this taxonomy.

The MAST taxonomy gives us the "Potential Failure Mode" column for our FMEA table. When we analyze the Orchestration component, we aren't just saying "it might fail"; we can now say it might exhibit Step Repetition (FM-1.3) or Premature Termination (FM-3.1). When analyzing a handoff, we can look for Information Withholding (FM-2.4) or Ignored Other Agent's Input (FM-2.5).

4. Identifying Dependencies and Failures in Practice

Let's now synthesize these concepts by performing a mini-FMEA on a hypothetical workflow. Imagine the sales agent system from our previous lesson, specified by a PRD and agent descriptions. Our goal is to identify dependencies and potential failures by inspecting this design.

Scenario 1: Orchestrator Routing

• Process Step: Orchestrator receives a user query, "My latest order is delayed, and I need to know if the new X-series can help speed up my production line."
• Component Under Analysis: Orchestration/Agent Controller
• Dependency: The orchestrator's routing decision is critically dependent on its ability to parse the user's mixed intent (a support issue and a sales query).
• Potential Failure Mode (MAST): Task Derailment (FM-2.3). The orchestrator might latch onto only one part of the query.
• Potential Effect: If it routes to the Sales Agent first, the agent might launch into a pitch, ignoring the user's urgent support issue, causing frustration. If it routes to the Support Agent and stops, the sales opportunity is lost.
• Potential Cause: Ambiguous routing logic in the orchestrator's system prompt; no mechanism for handling multi-intent queries.

Scenario 2: Inter-Agent Handoff

• Process Step: The Support Agent successfully identifies the order is delayed due to a supply chain issue. It hands off a summary to the Sales Agent.
• Component Under Analysis: Handoff interface between Support and Sales agents.
• Dependency: The Sales Agent is entirely dependent on the information provided by the Support Agent to craft a relevant, empathetic response. This is a classic cascade/conditional failure point described in the FMEA article.
• Potential Failure Mode (MAST): Information Withholding (FM-2.4). The Support Agent's specification may instruct it to only output structured data like {"order_id": 123, "status": "delayed"}. It withholds the reason for the delay (the supply chain context).
• Potential Effect: The Sales Agent, lacking context, gives a generic pitch for the X-series, failing to connect it to solving the user's actual underlying problem (supply chain vulnerability). The solution feels tone-deaf.
• Potential Cause: The data contract (the specified output schema for the Support Agent and input schema for the Sales Agent) is too simplistic.

Scenario 3: Tool Execution

• Process Step: The Sales Agent, based on the handoff, decides to draft a quote and an email using its tools.
• Component Under Analysis: Tooling/Action Execution Layer
• Dependency: The entire workflow's final output and real-world impact are dependent on the correct and safe execution of tools.
• Potential Failure Mode (MAST): Reasoning-Action Mismatch (FM-2.6). The agent's internal "thought" process might be to draft a quote for the X-100 model, but due to a poorly described tool or a hallucination, it calls the create_quote tool with the parameters for the more expensive X-200 model.
• Potential Effect: A factually incorrect quote is sent to the customer, eroding trust and requiring manual correction. In a more critical system, this could be disastrous (e.g., executing a trade instead of simulating one).
• Potential Cause: The tool's docstring is ambiguous; the agent's system prompt lacks constraints on which products it can quote without approval. This is precisely the kind of failure that a tool-level guardrail, which we'll cover later, is designed to prevent.

This exercise shows how by using the system decomposition from the FMEA guide and the failure vocabulary from the MAST paper, you can systematically "walk through" your specification and flag dependencies and specific, well-defined failure risks.

Conclusion

In this lesson, we introduced a formal, engineering-centric methodology for analyzing an agentic workflow specification to find its weak points before development begins.

Key Takeaways:

• FMEA is a powerful tool for proactive risk assessment in agentic AI, forcing a "design for failure" mindset.
• System decomposition is crucial for analysis. By breaking a workflow into standard components (prompting, orchestration, retrieval, tooling, etc.), we can analyze it systematically.
• A formal taxonomy of failures (MAST) provides a precise language to describe what can go wrong, moving beyond vague concerns to specific issues like step repetition, information withholding, or reasoning-action mismatch.
• Dependencies create cascading risks. A failure in one component (e.g., incomplete retrieval from the Memory Layer) directly leads to a failure in another (e.g., hallucination in the Cognitive Layer). Your FMEA should trace these dependencies.
• This analysis is performed on the design artifacts alone. The goal is to identify and mitigate risks at the cheapest possible stage: the design phase.

Preview of the Next Lesson

We have now established a rigorous process for writing specifications, mapping information flow, and analyzing those designs for potential failures. This puts you in a strong position to design robust systems. In the next lesson, we will explore a more advanced topic: using an agent-assisted workflow to generate initial PRDs and specifications from a business problem description. We will see how you can leverage an agent as a partner in the design process itself, potentially even tasking it to help you identify some of these failure modes from the outset.