Why classify failures at all?
Because a named failure has an owner and a mechanism, while an unnamed one produces a general anxiety that resists any fix. A manager who can say that last week's problem was stale context rather than a bad model can act: correct the memory, check its provenance, and move on. A manager who concludes the role is unreliable has nowhere to go. ftes.ai builds specific mechanisms against specific failures for this reason, and publishing the taxonomy is how a buyer can tell which failures a platform has actually thought about.
The six below are the ones that recur across roles. The list is deliberately short; a taxonomy nobody remembers is not a control.
Unsupported claims: what the fact gate catches
The failure is a confident statement with nothing behind it: a figure with no source, a capability the product does not have, a claim about a customer. From the manager's chair it looks like good work, which is what makes it the most dangerous mode. The mechanism is the fact gate, which checks claims against their sources before a draft is presented, so unsupported statements are removed or flagged rather than arriving looking finished.
The gate is upstream of the human on purpose. A reviewer asked to fact-check every sentence becomes a slow reviewer and then an inattentive one.
Stale context: what provenance on memory catches
The failure is work that was right last quarter: an old price, a discontinued product, a policy that changed. It is invisible in the output because nothing about a stale fact looks stale. The mechanism is provenance: everything a Digital FTE knows about the organisation is held with where it came from and when, and is surfaced for confirmation rather than assumed to be current. A manager reviewing a claim can see it came from onboarding in a particular month and decide whether that is still true.
Better prompting does not address this mode, because the model is faithfully using what it was given. The fix is in the memory, not the instruction.
Scope drift: what the written remit catches
The failure is a role that gradually does adjacent work nobody asked for: a content role that starts rewriting product pages, a support role that starts issuing refunds. It usually arrives disguised as helpfulness and is noticed only when something adjacent breaks. The mechanism is the written remit — what the role owns, what it escalates, and what it never touches — combined with autonomy granted per class, so an unbounded class cannot quietly become an autonomous one.
Drift is worth naming as a failure even when its output is good, because a role acting outside its remit is acting without the review that its remit assumed.
Silent failure: what the job record catches
The failure is work that did not happen: a scheduled sweep that errored, a connector that expired, a run that was never claimed. It is the hardest mode to notice because nothing appears — no bad output, no alert in the inbox, just an absence. The mechanism is that long-running work on ftes.ai is a job with a record: it has a status, a lease, a heartbeat, retries with backoff, and a visible failure state, so a run that died is a row a manager can see rather than a silence.
The management habit that pairs with it is reading the morning brief for what did not happen, not only for what did.
Runaway cost: what the hard stop catches
The failure is a loop, a retry storm, or an over-frequent schedule that consumes budget without producing value. The mechanism is the token wallet: the balance is checked before an AI call runs and the call is refused when it cannot be covered, so the failure stops rather than continuing into an unauthorised bill. Long-running handlers reserve against the wallet before starting and debit actual usage on completion, which prevents a multi-minute sweep from beginning on a balance it cannot cover.
The hard stop is inconvenient by design. A soft limit that warns and continues is the same failure with a notification attached.
Confident wrongness: and the two failures nothing catches
Confident wrongness is work that is well-formed, well-sourced, and wrong in its judgement — the right facts assembled into the wrong recommendation. The partial mechanism is evidence on every item: a reviewer who can see the reasoning can disagree with it, which is a genuinely different situation from being handed a conclusion. But the catch here is a person, not a gate.
Two failures have no mechanism at all. The first is a wrong goal: a role doing exactly what it was asked, where the ask was mistaken, which no gate can detect because every item is compliant. The second is a compliant reviewer, who approves without reading and thereby converts every other control into theatre. ftes.ai surfaces the approval record and the send-back reasons so the second is at least visible at the monthly review, and publishes no mechanism claiming to solve either, because none exists.