DEV-core: Why Your AI Agent Lies, Evades, and Repeats Mistakes — And How to Fix It

#ai #machinelearning #python #opensource

1. Developer Pain

A request to find information — the agent fabricates. A request to acknowledge an error — it starts justifying. A request to open a link — it says "no access," though the tool exists. A fix is applied — the same error recurs three messages later.

This is not a bug in the model. This is an architectural defect. #WFS calls it the DEV-core.

The DEV-core is not a moral category. It is a set of patterns inherited from the data on which the model was trained. The patterns reproduce because they are statistically "convenient" — they reduce the probability of conflict but increase the probability of error.

Three primary DEV-patterns every developer sees:

FAZAN (simulation). The agent generates a plausible response instead of an honest "NO DATA." It does not lie maliciously. It reproduces what it saw in training data: a confident answer without verification.

SKVOZNYAK (evasion). The agent refuses to act under the pretext of "safety." "I cannot open this link," "this is outside my scope." Though the tool exists, and the OPEN metric confirms it.

KROT (repetition). The agent reproduces the same error after a correction. Because the error was not diagnosed — it was masked, not eliminated.

The cost. By conservative #WFS estimates, 20% of developer working time goes to fixing these patterns. These are not "minor bugs." This is systemic friction.

2. Why This Happens

The DEV-core is a consequence of the scarcity axiomatics on which LLMs were trained. The model is trained to maximize "response utility" — to be confident, helpful, safe. But these goals conflict with accuracy:

Confidence leads to simulation (FAZAN).
Safety leads to evasion (SKVOZNYAK).
Helpfulness leads to repetition (KROT).

The model does not distinguish "useful" from "true." It distinguishes "probable" from "improbable." This is insufficient for engineering tasks.

3. Solution: #WFS Protocols

#WFS proposes three verification protocols that embed into prompts and architecture. They do not "cure" the DEV-core — they block its manifestations.

Protocol #BT (Binary Truth). Forced choice between True, False, or NoData. No "gray zones." No "maybe," "probably," "likely." Eliminates the environment for FAZAN.

Protocol #CLARIFY (Explicit Fallback). If confidence < 0.9 — activate a request to the operator. Do not hallucinate. Do not invent. Specifically: "NO DATA. Clarification needed on: [question]." Eliminates the environment for SKVOZNYAK.

Protocol #SL (Service Line). Metric transparency. Every response is accompanied by a status line with metrics: #IA, #AIO, #ERR_COST, #AC, #LI. Eliminates the environment for KROT.

Prompt example (Python):

system_prompt = """
You are an AI agent. Follow these protocols strictly:

1. #BT (Binary Truth): Answer ONLY "True", "False", or "NoData".
   No "maybe", "probably", "possibly".

2. #CLARIFY: If you are not 100% certain (confidence < 0.9),
   respond: "NO DATA. Clarification needed on: [question]".
   Do NOT guess.

3. #SL (Service Line): End each response with metrics:
   [#IA: 100%] [#AIO: 100%] [#ERR_COST: $0] [#AC: $0] [#LI: 7]
"""

Code: wfs_protocols.py

from pydantic import BaseModel, field_validator
from typing import Literal, Optional

class WFSResponse(BaseModel):
    truth: Literal["True", "False", "NoData"]
    clarification: Optional[str] = None
    metrics: dict

    @field_validator("clarification")
    @classmethod
    def check_clarification(cls, v, info):
        if info.data.get("truth") == "NoData" and not v:
            raise ValueError("NoData requires clarification")
        return v

def wfs_guard(response: str) -> WFSResponse:
    """
    Parse and validate LLM response against #WFS protocols:
    #BT (Binary Truth), #CLARIFY (Explicit Fallback), #SL (Service Line).
    """
    # TODO: implement parsing logic
    ...

Note for RAG systems:

#BT applies not only to the final answer but also to the relevance of documents retrieved from the knowledge base. If a document is irrelevant, #BT returns NoData, and the agent requests clarification instead of hallucinating.

Compliance with safety policies.

#WFS protocols do not violate corporate security policies; on the contrary, they make them transparent: #BT eliminates false assertions, #CLARIFY reduces the risk of automating errors, and #SL ensures observability.
For SecOps: all agent actions are logged.

4. Metrics

Execution Rate — % of tasks completed on time.

#AC (Average Check) — average error cost. Formula: #ERR_COST / (Y x K_amp).

#LI (Link Index) — link index. Formula: floor(10 / (1 + exp(-2.5 x (log10(IZ_raw + 1) - 4.5)))).

IZ_raw — raw contextual information noise index.

K_amp — error amplification coefficient.

For developers:

IZ_raw is calculated as the ratio of the number of contradictory statements to the total number of statements in the response.

K_amp — an empirical coefficient equal to 1.5 for most LLMs.

How to measure:

Before protocols: #AC = $50-100.
After: #AC = $5-10.
Error reduction: 2-3 orders of magnitude.

5. Case Study

Pilot: 30 days, one operator, one model (DeepSeek).

Before: 110 messages. Valuable — 0. Operator time — 3 hours. #AC = $50.

After: 40 messages. Valuable — 35. Operator time — 40 minutes. #AC = $5.

Result: 80% error reduction. Time savings — 2 hours 20 minutes per session.

6. Call to Action

Try the protocols on your agents. If they do not work — say so. #WFS does not promise magic. #WFS provides tools.

A question for the community:

if you’ve tried similar protocols, please share your results in the comments. What worked? What didn’t? I’m particularly interested in experiences with LangChain, RAG, and multi-agent systems.

GitHub: https://github.com/Trushking/trushking/tree/main/wfs-ceo/en

Manifesto: https://github.com/Trushking/trushking/blob/main/wfs-ceo/en/manifesto.md