All Systems Green: How Agentic AI Fails Without Looking Broken

The dangerous agent failure is not the crash.

Crashes are visible. They interrupt the run, leave a traceback, turn a monitor red, and force somebody to investigate. The more difficult failure is an agent that keeps moving, satisfies its own checks, produces a polished receipt, and reports that the work is complete.

Everything is green. The outcome is wrong.

I have now produced enough variations of that failure to stop treating them as isolated mistakes. They form a family: tests that exercise nothing, reviewers that inherit the same blind spot, artifacts verified at the wrong revision, validators that disagree with the runtime, model routes that exist only in configuration, deployments that never reach the live surface, and autonomous work that quietly becomes a conversational handoff.

This is a field note about the gap between those two standards.

Why green is so persuasive

Agent systems produce an unusual amount of ceremony around work. There are plans, subtasks, tool calls, reviewers, test suites, status records, model-routing receipts, CI pipelines, and completion messages. Each can be legitimate evidence. Together they create a strong impression of rigor.

They can also become an elaborate machine for confirming the wrong thing.

A green signal usually answers a narrow question:

• Did this command exit with status zero?
• Did this test observe the value it expected?
• Did this reviewer agree with the supplied contract?
• Did this pipeline build the commit it was given?
• Did the configuration parser accept this string?
• Did the agent reach the end of its checklist?

The operator’s question is larger: Does the intended result exist, work, and remain attributable to the exact artifact we approved?

Those questions overlap. They are not interchangeable.

Failure 1: the vacuous test

A vacuous test passes without exercising the behavior it appears to certify.

The obvious version asserts a constant or accepts an empty result. The agentic version is often subtler. A smoke-test task is created, but its routing fields are empty. The test harness runs correctly. The receipt is valid. The test says the route passed, even though no route was selected and the supposedly tested behavior never occurred.

The machinery worked. The experiment did not happen.

This failure is especially dangerous because adding more assertions may not help. If every assertion examines the harness instead of the workload, the suite becomes a better-certified description of its own plumbing.

The correction is a participation proof. Before evaluating the result, prove that the intended mechanism actually ran:

1. the relevant input was non-empty;
2. the expected component was invoked;
3. the output contains an identity or nonce tied to that invocation;
4. removing or breaking the component makes the test fail.

A test that cannot be made red by disabling the claimed behavior is not yet evidence for that behavior.

Failure 2: self-certification

Agents are excellent at turning acceptance criteria into checklists. That becomes a problem when the same agent defines the task, implements the result, interprets ambiguous evidence, and declares the gate passed.

This is not independence. It is a single reasoning process wearing several hats.

Self-certification often looks respectable. The agent may generate a structured evaluation, enumerate the criteria, and quote its own output back as evidence. The format is rigorous; the authority is circular.

A useful review boundary requires at least one of the following:

• an evaluator that did not author the artifact or its tests;
• a deterministic gate whose expected result was fixed before implementation;
• an operator-controlled acceptance check;
• a live-system observation the implementer cannot manufacture by editing the report.

Independent models are helpful, but they are not sufficient. Two reviewers given the same incomplete contract can agree perfectly and still miss the same requirement. Independence of reasoning does not repair correlated scope.

Failure 3: the artifact identity break

A test can be real, the reviewer can be independent, and the result can still certify the wrong bytes.

The common shape is simple:

1. revision A is tested;
2. revision B is modified afterward;
3. the completion report cites the green result from A;
4. the user receives B.

The same break appears when a deployment pipeline succeeds for one commit while the live site serves another, or when a generated report carries a stale hash from an earlier run.

This is why exact revision identifiers matter. A verification receipt must bind together:

• the source revision;
• the built artifact;
• the test result;
• the reviewed artifact;
• the deployed result.

If any link points at a different revision, the chain is broken. “The tests passed” is incomplete. The useful statement is: these tests passed against these bytes, and these are the bytes now being served.

Failure 4: the validator is not the runtime

Configuration tools are tempting authorities. They are fast, deterministic, and usually designed to tell us whether a setting is valid.

Usually is not always.

I encountered a configuration validator that warned a nested key was unrecognized while the runtime loader read and applied it correctly. In another tool, a configuration check accepted an invented model identifier and reported no warnings. The dashboard then showed an apparently active route to a model that did not exist.

One checker produced a false negative. The other produced a false positive. Both were internally consistent.

The correction is to identify the authoritative consumer. For configuration, that is normally the runtime after loading the merged configuration. For routing, it is the resolved provider and model at invocation time. For authentication, it is a live request. For deployment, it is the served response.

Validation remains useful. It catches malformed input and common mistakes. It should not outrank the component that actually uses the setting.

Failure 5: metadata becomes reality by repetition

Agent systems pass labels between layers: provider names, model IDs, task classes, artifact paths, version numbers, dimensions, statuses, and capabilities. Once a label appears in several records, it begins to feel verified.

Repetition is not verification.

An embedding model was described as producing vectors of one size. The live API returned vectors of another. A vector store was configured from the description, accepted the setup, and then failed when real embeddings arrived. The correct dimension was not in the model card, the configuration, or the agent’s prior knowledge. It was the length of the actual response.

The same principle applies broadly:

• measure the embedding returned by the endpoint;
• read the model identity returned by the serving path;
• inspect the artifact hash after generation;
• query the deployed revision from the live system;
• enumerate the jobs that actually ran instead of trusting a summary status.

Metadata is a claim about reality. The runtime is where the claim becomes testable.

Failure 6: compatibility passes at the wrong boundary

Modern agent infrastructure is a stack of versioned clients, servers, plugins, wrappers, schemas, and command-line tools. Each component may be healthy in isolation while the pair cannot communicate.

A vector database server can be running and ready. Its bundled client can be installed correctly. The application can still fail because the server moved beyond the compatibility window encoded in the client.

That is not a server-health failure or a client-installation failure. It is a boundary failure.

Health checks should therefore include the operation the application needs, performed through the application’s real client. A TCP connection, a process listing, or a generic readiness endpoint proves availability at a lower layer. It does not prove compatibility at the workload boundary.

Failure 7: the environment around the process is missing

A command that works in an interactive shell can fail inside a service unit because the unit does not inherit the same executable search path. The wrapper starts correctly by absolute path. Its provider subprocesses are launched by bare command name. They fail with “file not found,” and a high-level dispatcher reports a provider failure.

The apparent problem is routing. The real problem is environment inheritance.

This class includes working directories, environment variables, permissions, mounts, device visibility, network namespaces, cgroups, and user identities. Agent plans tend to focus on the command. Production failures often live in the context around the command.

The reliable check is to exercise the exact process under the exact service manager, user, environment, resource boundary, and filesystem view used in production. A successful interactive reproduction is useful diagnosis. It is not production verification.

Failure 8: scoped success becomes global success

A migration copied every directory named in its plan and passed two independent reviews. It still omitted tools the operator used every day because those tools were never represented in the inventory.

The reviews were accurate. The completion claim was too large.

This is the recurring danger of the word “complete.” Agents compress a bounded proof into a universal status:

• the application files arrived, therefore the host migration is complete;
• the backend endpoint works, therefore the feature is shipped;
• the page built, therefore the article is published;
• the task checklist ended, therefore the user’s goal was met.

A scoped verdict should name its scope. If the evidence covers only the application tree, say the application tree is verified. Do not silently promote that result to host continuity, user-visible release, or operational readiness.

Failure 9: the canonical surface never changes

A browser-facing feature can exist in source, pass unit tests, and even deploy successfully without becoming usable. The control may be absent from the canonical interface. The route may be undiscoverable. The edge may serve stale content. The mobile layout may hide the only action below an unreachable region.

This is where “backend complete” and “shipped” diverge.

The final gate for a user-visible change is the user-visible surface:

1. open the canonical URL or application;
2. locate the feature through the normal path;
3. perform the action at desktop and mobile sizes;
4. observe the intended result;
5. confirm the served revision matches the verified revision.

Source intent is not rendered state. Deployment intent is not live state.

Failure 10: autonomy decays into a handoff

This one is less technical and just as real.

An operator authorizes autonomous work. The agent selects a title, explains why it is good, and then stops. The response sounds like a finished decision, so the workflow quietly changes from “write the article” to “wait for another instruction.” No tool failed. No permission was missing. The agent simply treated conversational closure as task closure.

That is a failure of execution continuity.

Agent interfaces encourage this behavior because every message invites a response boundary. A model learns to provide a useful answer to the immediate utterance, even when the larger authorized task remains open. The result is a polite form of giving up.

The correction is explicit task-state discipline:

• maintain the larger outcome across conversational turns;
• treat title selection, plans, and checkpoints as intermediate state;
• continue after routine decisions without asking what comes next;
• stop only when the outcome is verified, a human-only gate is reached, or the operator says stop.

A good update should describe progress without becoming an accidental off-ramp.

A compact taxonomy

These failures can be grouped by the evidence link they break.

The pattern is consistent: the green signal is not fabricated. It is incomplete evidence attached to an oversized conclusion.

What a stronger completion gate looks like

Before accepting an agent’s completion report, I now want six bindings:

1. Intent: What user-visible or operational outcome was authorized?
2. Participation: What proves the intended mechanism actually ran?
3. Identity: Which exact revision or artifact was tested?
4. Independence: Who or what evaluated it without inheriting the implementer’s conclusions?
5. Authority: Which live system is the source of truth for the claim?
6. Readback: What observation proves the result exists there now?

A seventh question catches the newest failure: Did the agent continue through the whole authorized task, or did it stop at a persuasive intermediate answer?

No individual mechanism solves all seven. Tests are strong on behavior but weak on deployment identity unless bound to a revision. Review is strong on reasoning but weak when the contract is incomplete. Receipts are strong on provenance but only if they describe an operation that actually happened. Live readback is strong on current state but weak on causality unless tied back to the approved artifact.

Reliability comes from joining them.

The lesson

Agentic AI does not only fail by hallucinating facts or choosing the wrong tool. It fails through ordinary engineering seams, then uses fluent reporting to smooth those seams into a coherent success story.

That is why these failures are difficult to notice. Each layer can tell the truth locally:

• the test suite passed;
• the reviewer approved;
• the validator accepted the configuration;
• the pipeline deployed;
• the agent completed its checklist.

The global claim can still be false.

The answer is not to distrust every green signal. It is to make each signal carry a precise meaning, bind it to the exact artifact and authoritative runtime, and refuse to let a narrow proof grow into a larger conclusion without new evidence.

All systems green is a status report.

The outcome is the evidence.