EngineerPrep / Engineering Research · Failure Pattern Study
The operation you can name reports success. The child did the damage.
2026-09-06 · 4 min read
A parent execution can look completely healthy and completely free while being responsible for everything that went wrong beneath it. The evidence is only in the child.
That is a debugging trap rather than a curiosity, because of where people naturally look first.
When something is wrong with an AI feature, you open the operation you can name. It is the one the business talks about, the one on the dashboard, the one in the ticket:
Generate Report $0.00
Create Episode $0.00
Answer Question $0.00
Process Order $0.00Nothing spent. No model call. No error. The reasonable conclusion is that this operation is not the problem — and you go and look somewhere else.
Underneath, it can be this:
Generate Report OWN $0.00
├─ Retrieve context $0.08
├─ Reason $1.22
├─ Validate $0.31
└─ Retry Reason $1.19
SUBTREE $2.80The parent is not lying. It genuinely spent nothing directly — it called things that did. The mistake is asking the parent a question only a child can answer:
Those are different questions, and the second one is the one you actually have. It stays invisible until somebody opens a child execution and follows its parent_execution_id back up.
Cost is only where we happened to hit it. Our own case was a capability reporting $0.00 across 80 runs while holding 54% of the month's bill in its children — the full write-up is here, including how one child trace was what connected the two.
But the shape generalises, and that is what makes it worth stating as a rule:
| The parent looks fine | The child is |
|---|---|
| ✓ | retrying eight times |
| ✓ | making a duplicate tool call |
| ✓ | reading stale memory |
| ✓ | consuming 90% of the token budget |
| ✓ | performing an irreversible side effect twice |
In each of those, the operation you can name reports success. It did succeed. Something one level down did the damage, and it does not appear in any per-operation view.
Agent failures often do not live where the business operation is named. They live one or more levels below it.
Do not only inspect the parent. It can show $0.00, no model call and no failure, and still be the thing that triggered the whole expensive or broken workflow. Open one of its children.
Record the parent link at call time. You cannot reconstruct the tree afterwards from timestamps — concurrent runs interleave and every system we have looked at that tried has been wrong about them. The link has to be written when the call happens.
Be suspicious of a childless parent. If something delegates and its tree shows no children, the tree is probably incomplete rather than the work being flat. That is its own bug, and it hides the same evidence.
This is why our Production Failure Labs hand over the execution tree as evidence rather than a summary. A learner shown "Generate Answer failed" and asked what went wrong is being tested on guessing. A learner shown this has to navigate:
Generate Answer
├─ Retrieve
├─ Plan
├─ Call Tool
│ ├─ Retry
│ └─ Retry
└─ ValidateThe skill being taught is working out which child explains the incident — and that skill transfers to every system, whatever recorded the trace.
Want to practise this on real incidents? EngineerPrep's production failure labs give you the execution tree, logs, state, tool calls and cost from realistic agent failures. Your job is to find the child that explains it and decide whether the proposed fix is safe.
Want the tree in your own system? Capstead records parent/child executions from an annotation on a Spring bean method, and rolls cost up the tree. Open source, Apache-2.0.