Technical framework · Nikxius

An AI agent failure taxonomy

Separate denial, rejection, unknown effects, partial commitment and degraded recovery.

Nikxius ResearchResearch cutoff: 15 September 2026

A tool call needs more than success or failure

An agent can receive a timeout after an external change committed. It can receive an acceptance response before a controller finishes. It can observe a healthy present state without knowing whether the operation under investigation caused it.

This taxonomy separates those cases. It is an engineering synthesis, not a universal wire protocol. Native systems and runtimes may use different field names; map their documented semantics before comparing labels.

Before a possible effect

State Meaning Safe next question
Malformed / unsupported The request does not match an admitted contract Can the proposer correct its request without changing authority?
Denied The authority, policy or required review does not permit the operation Is new authorization appropriate, or should work stop?
Stale authority A previously acceptable grant or review is no longer valid Which current authorization is required?
Stale native baseline The target identity or checked state changed Does a newly proposed operation need a new review?
Admitted, not dispatched Local permission/durability exists but no native send is established under the implementation invariant May the documented worker continue safely?
No change required The supported preparation path found the requested state already present Can the operation close without mutation and without claiming it caused that state?

A local denial is not proof that nothing changed through some other writer. Its scope is the request and boundary that enforced it.

After dispatch may have occurred

State Meaning Unsafe shortcut
Native acceptance The system acknowledged receiving or queuing the request Calling the whole business process complete
Known commitment Accepted native evidence establishes the contract’s declared effect Calling the application healthy automatically
Known rejection Accepted native evidence establishes rejection of this request Assuming all related workflows had no other effects
Unknown commitment Evidence does not establish whether this operation committed Treating the timeout as failure or using a new key to repeat blindly
Known partial effect Evidence establishes some effects and some missing/failed work Repeating the entire workflow without considering committed parts
Integrity mismatch A committed result violates a checked invariant Rewriting a committed violation as a prevented action
Unknown outcomes remain unknown until sufficient native evidence establishes more. Commitment is separate from application health.

Observation is another dimension

After commitment, a controller may be pending, converged, degraded or superseded by later work. An observation can also be unavailable. These describe what is currently observable; they do not necessarily establish who caused an earlier transition.

In Kubernetes, a committed Deployment image change and a rollout condition are different facts. Application behavior may require additional checks. See the primary Deployment documentation.

Recovery is an obligation, not a verdict

“Reconciliation required” identifies work still owed. It should have an owner, evidence requirements, permitted actions and escalation. The result may be commitment, rejection, identified partial effect or continued uncertainty.

A workflow retry, a read-only reconciliation and a compensating action are different operations. Provider idempotency can make specific retries safe under documented conditions. Stripe’s advanced error handling and Temporal’s Activity guidance explain why a generic retry policy is insufficient by itself.

Mapping to Nikxius

Nikxius’s current lifecycle labels are PROPOSED, AWAITING_APPROVAL, REVALIDATING, ADMITTED, DISPATCH_RECORDED, PENDING, UNKNOWN, RESOLVED and DENIED. Its separate commit field is not_dispatched, committed, rejected or unknown. Observation and integrity have their own fields.

The conceptual taxonomy above is intentionally richer than one API enum. Do not assume that RESOLVED means success, that UNKNOWN is simply a failed request, or that every “partial effect” label maps to a dedicated current Runtime state.

Read the current state contract, the recovery model and the Agent Action Contract. Use the production-readiness checklist to decide which cases your workflow must exercise.

Explore the action contract, the Kubernetes rollback workflow, or evaluate one operation.