Application governance assumes a behaviour can be verified once, because the same input produces the same output. An agent takes different paths through the same task on different runs, and both paths can be correct, so there is no “the” behaviour to review, and every control built on design-time verification is measuring something that no longer exists.

The mechanism

Agents differ from other computational systems in exactly two ways, on the cleanest definition available: they interact with the world, and they adapt to under-specified instructions. Everything else on this page follows from those two properties.

Agenticness is a degree, not a category; three unrelated bodies converge on this. The visibility literature defines agency as the degree to which a system acts directly in the world toward long-horizon goals with little human specification of how. OpenAI decomposes “degree of agenticness” into goal complexity, environmental complexity, adaptability and independent execution, and states outright that there is no clear line along which to draw a binary distinction between agents and systems like GPT-4. OWASP puts autonomy on a spectrum too. So a governance rule keyed on the word “agent” will be argued about forever; a rule keyed on a threshold will not.

The most defensible threshold in the literature is an inclusion criterion from a peer-reviewed index of 30 deployed systems: write access plus tool choice, operationalized as at least three autonomous tool calls from a high-level task specification given without step-by-step instructions, plus the ability to handle under-specified input. That is a policy-grade trigger: it can go into a document and someone can apply it.

The property that breaks the stack is variability. The same agent, on the same task, takes different paths on different runs, and that variability is the flexibility that makes agents useful rather than a defect. There is no single behaviour to verify at design time. Code review verifies an artifact; the artifact is now a policy for generating behaviour rather than the behaviour itself. Change management gates a release; the system changes between releases. Static permissioning grants a fixed capability set; the agent chooses which tools to call, when, and in what order.

Kolt supplies the reason discretion is unavoidable rather than sloppy. Instructions are inevitably incomplete: “take this $100,000 and turn a profit” cannot be fully specified, so the agent must interpret. Deterministic software has no analogous gap, because everything it does was written down. (That last step is our inference; Kolt’s point is about the interpretation requirement.)

Two more properties compound it. The boundary between instructions and data disappears: in an agentic pipeline, retrieved content sits in the same channel as the builder’s instructions, and that is the architectural fact underneath prompt injection. And self-modification is emerging: an agent that writes its own helper function to send email has altered its capability set after review. That last one is a constructed example from a research paper which itself notes the property is emerging rather than universal, and that most deployed enterprise agents lack unconstrained code execution, so it should not be presented as something that happened at a firm.

The scale of the difference is now measured rather than asserted. Matched on near-identical requests from the same users, an agent ran about 26 minutes of autonomous work per session against about 33 seconds for an assistant, roughly a 48× gap, with medians of 9 minutes against 14 seconds. That is the unsupervised-execution window, and it is the number to put in front of anyone who thinks a chatbot policy covers this. (Perplexity employees studying Perplexity products; the authors say to cite the direction, not the magnitude, and this is a direction claim.) Tool reach differs the same way: 7.9% of agent sessions invoked at least one connector against 1.8% for assistants, a 4× gap in incidence, and 1.19 mean connector calls per session against 0.10, a 12× gap. Those are two different ratios and get conflated constantly. In OpenAI’s own telemetry, 60.3% of Codex turns invoked an external tool against 21.9% of ChatGPT turns.

Kolt’s one-liner is the version to use with a board: a language model can describe a phishing campaign; an agent can run it. Agents inherit every language-model risk and add action risk on top.

The governance consequence has a name that is becoming standard vocabulary across several vendors: the shift from a software development lifecycle, which assumes discrete deterministic releases, to an agent development lifecycle for living systems that change after deployment. Use the mechanism rather than the acronym: several firms use “ADLC” for the same idea, so it signals nothing about whose material a firm has read.

What to do

Score agenticness at intake rather than arguing about the label. Four questions, from OpenAI’s decomposition: how complex is the goal, how complex is the environment, how much does it adapt, how much executes without a human. A score routes the build to a risk tier; the word “agent” routes nothing.

Adopt the write-access-plus-tool-choice trigger as the policy line. Three autonomous tool calls from an under-specified instruction is a bright enough line to write into a standard, and it is defensible because someone published it against 30 real systems.

Move the verification point from the artifact to the runtime path. If behaviour is generated rather than written, the thing to constrain is what the agent may reach and what it may do when it gets there; see runtime guardrails and three-zone architecture.

Replace release-gated change management with lifecycle management anchored on a registry entry, because there is no release to gate. See agent inventory and registry review.

Apply least-agency as a design default, which is OWASP’s framing: agentic behaviour beyond what the task requires expands the attack surface without adding value. Most tasks that get built as agents would work as a script with a model call in the middle, and that version is governable with the stack a firm already owns.

How you’d know it’s working

Governance findings appear at runtime or at a promotion gate on builds that passed classic review. If the SDLC gates still catch everything, the firm is governing scripts and calling them agents.

Someone can state the firm’s agenticness threshold from memory and apply it to a borderline case without escalating. A definition nobody can apply counts for nothing.

Two different execution traces can be produced for the same agent on the same input. Where they cannot, either nobody has looked or there is no agent here.

What this doesn’t solve

Knowing why the old governance fails supplies no replacement. This page is diagnosis; the controls live in controls/, the architecture in patterns/, and the operating cadence in operation/. Reading only this page leaves a reader correctly worried and unequipped.

Low-agenticness builds still carry every classic citizen-development failure — undocumented, unowned, unmaintained. Scoring a build as barely agentic exempts it from this page and not from quality debt.

The strong version of the argument is contested, and this page declines it. Some model-risk-management writing holds that agents are complex rather than merely complicated systems and are therefore “impossible to regulate or govern” by traditional means. That is the authors’ wording and it is stronger than the evidence: existing MRM frameworks assume static, one-time validated algorithms and clearly strain, which is different from being useless, so treat MRM as insufficient, not inapplicable.

And the split-ownership problem is real but narrower than it is usually quoted. The observation that a deployed enterprise agent is a joint product of platform vendor and business user with mutual blindness comes from a discussion of one specific platform, and the same authors note the asymmetry can produce better solutions, so it belongs in the record as an observation about agent platforms rather than a general indictment.

See also

• Risk tiers — what an agenticness score routes into.
• Runtime guardrails and policy enforcement — the control that replaces static review of an artifact.
• Agent inventory and registry — the lifecycle anchor a CMDB built for releases cannot provide.
• Quality debt and orphaned apps — the classic failure class that persists regardless of agenticness.
• Cross-session delayed detonation — a failure only variable-length, persistent execution makes possible.
• The problem — why this is arriving through citizen builders rather than through IT.