E4: Reusable Analysis Operations
Troubleshooting agents need to handle unfamiliar failures without unrestricted code; E4 lets them compose reusable analysis operations and add new ones within the same structured language.
Read the paper ↗What it is
- Reusable analysis operations E4 breaks troubleshooting into named analysis steps, such as finding possible causes, comparing them with normal behavior, and ranking evidence.
- Structured extension If the available steps cannot express a needed analysis, E4 allows a new step while keeping the same rules for how workflows are built.
Why it matters
An agent can adapt its investigation to unfamiliar failures without writing unrestricted programs for each one. The steps stay visible for people to inspect, though a structured workflow can still reach a poor conclusion.
Before getting into the machinery, here is the simple version: E4 lets an AI investigate a failure by putting together reusable analysis steps, rather than writing a new analysis program from scratch each time. If the available steps do not fit a new kind of incident, it can add a step without changing the structure of the language it works in.
- Variety: Root-cause analysis has to handle failures that look quite different. A useful troubleshooting system cannot assume every incident matches a playbook someone wrote in advance.
- Reviewability: Free-form code gives an agent broad options, but makes it harder to inspect what it did. In a high-stakes setting, flexibility has to be balanced against the ability to check the investigation.
The canonical example is the RCA workflow itself. One step can propose possible causes, another can compare a cause with normal behavior, and another can rank the evidence. Think of these as entries in a troubleshooting notebook: you choose which analyses to run and in what arrangement, rather than asking the agent to invent every tool as it goes. The analogy has a limit: these operations are executable analysis building blocks, not just notes.
The crucial move is to make the operation the unit of choice. The agent can combine known operations into a diagnosis workflow, while the operations stand for meaningful kinds of analysis. In other words, it is choosing how to investigate, not freely implementing every low-level detail. How much useful freedom does that leave when an incident is genuinely new?
That leads to the second part: the operation list is extendable. If the existing steps are not enough, a new operation can be added while following the same DSL structure. The language's vocabulary grows, but the rule that analysis is expressed through structured operations remains. It is a bit like adding a new kind of page to the notebook rather than switching to an unbounded scratchpad; unlike a notebook, though, the operation can be executed and composed with others.
So the benefit is not that a structured workflow must be right. It is that you can see what kinds of analysis it performs and keep additions inside a shared structure. The cost is that a new operation still needs careful definition and review, and the agent can still select poor steps or misread their results. I like this middle ground more than either a frozen checklist or free-form code, but it makes the quality of the operation set matter. How much should the vocabulary grow before the structure stops being useful?
Read the deep dive
Why People Wanted It
A root-cause analysis agent faces failures that do not all look alike: an unusual user group in one incident, a subtle event sequence in another. A fixed playbook is easy to inspect but cannot cover every case; arbitrary analysis code gives more latitude but is expensive and difficult to verify. The practical question is how to let the agent adapt its investigation without giving up a structure a human can check.
The Core Move
E4 treats troubleshooting as a workflow assembled from reusable analysis operations, rather than as arbitrary code written for each incident. An operation has a defined role in the analysis; the agent can combine available operations into a diagnosis and, when those are insufficient, add an operation while keeping to the same DSL structure.
Why Operations Are the Unit of Analysis
Now the version for readers who want more of the machinery: the important design choice is to make the agent's choices about analysis steps, not unrestricted implementation details. For example, one operation can generate candidate causes, another can compare a candidate against normal behavior, and another can rank evidence. Those roles are given as examples of E4 building blocks; the key constraint is that the workflow is made from such blocks rather than arbitrary analysis code.
This changes what must be inspected. Instead of reasoning about every line of a bespoke program, a reviewer can ask which operations were selected and how they contribute to the diagnosis. The blocks do not guarantee a correct conclusion: their outputs still need to be interpreted and checked. What remains open is how to cover a failure mode that the current set of blocks cannot express.
Why New Operations Do Not Mean Abandoning Structure
Here is the part that gets technical: extending the operator set changes the available vocabulary, not the requirement that analysis be expressed in that vocabulary. If existing operations are insufficient, E4 permits the agent to create a new one while still following the same DSL. In structural terms, the extension adds a permitted analysis building block; it does not turn the workflow into arbitrary code.
That distinction is the point of extensibility. A fixed operator set would constrain the agent to anticipated analyses, while unrestricted code would make the analysis harder to inspect and verify. A new operation creates room for a previously unsupported analysis, but only within the existing language's structure. The design therefore shifts the boundary of what can be expressed without discarding the boundary itself. The remaining question is how much freedom the DSL should grant when a genuinely novel incident arrives.
Minimal Causal Code
This deliberately plain sketch shows the state of an investigation as a list of operations. It is illustrative, not a claim about E4's implementation API.
operations = {
"generate_causes": generate_causes,
"compare_to_normal": compare_to_normal,
"rank_evidence": rank_evidence,
}
workflow = ["generate_causes", "compare_to_normal", "rank_evidence"]
state = {"incident": incident, "candidates": [], "evidence": []}
for operation_name in workflow:
operation = operations[operation_name]
state = operation(state)
# If the available operations are insufficient, add a new operation
# that follows the same DSL conventions, then include it in a workflow.
The visible state update is the point: each operation receives the current investigation state and returns the next one. Real E4 operation interfaces are not specified by this sketch.
What You Gain, and What You Lose
Reusable operations make analysis steps explicit and checkable, while letting the agent compose them for different diagnoses. Allowing new operations avoids treating the original vocabulary as a complete list of every useful analysis. The tradeoff is that structure is not a correctness guarantee: a workflow can still choose weak operations or draw a bad conclusion. And every extension expands what reviewers need to understand. E4 aims for a middle ground—more adaptable than a fixed playbook, more bounded than arbitrary code—not an escape from review.
E4 makes troubleshooting adaptable by expanding the set of structured operations, not by abandoning structure.