Most systems we call “AI agents” are not really agents in the deeper sense. They are powerful workflows wrapped around LLMs.

I recently came across the Critique of Agent Model paper that gave me a cleaner vocabulary for something many developers already feel when building agents.

A lot of “agents” are impressive.

• They call tools.
• They browse.
• They write code.
• They open pull requests.
• They search docs.
• They summarize logs.

Some can even coordinate with other agents.

But after you strip away the product language, many of them look like this:

while task_queue:
    task = task_queue.pop()

    plan = llm.generate(
        prompt=f"Plan how to solve: {task}",
        tools=available_tools,
        memory=memory.read()
    )

    action = router.choose_tool(plan)
    result = action.run()

    memory.write(task, plan, result)

    if evaluator.accepts(result):
        break

This is useful engineering. I have no issue with it.

The problem is the name.

Calling this whole thing an “agent” can hide where the intelligence actually lives.

In many systems, the LLM is not maintaining its own long-term goals.

It is not revising its own identity.

It is not deciding when to learn.

It is not regulating its own planning depth.

The surrounding harness does most of that work.

That is the core argument of the paper.

The authors distinguish between agentic systems and agentive systems.

Agentic systems complete tasks through engineered workflows, tools, prompts, and control loops.

Agentive systems derive more of their behaviour from internal structures - persistent goals, adaptive identity, decision-making, self-regulation, and self-directed learning.

That distinction matters because it changes how we evaluate the current “AI agent” wave.

The Word “Agent” Is Doing Too Much Work

Today, almost anything can be called an agent.

• A script that checks a website every hour is an agent.
• A chatbot with tool access is an agent.
• A browser automation loop is an agent.
• A coding assistant that edits files is an agent.
• A robot dog with a task planner is an agent.

The paper argues that this broad usage blurs an important difference - a system can look goal-directed from the outside while having very little internal agency.

Take a classical bot. It observes a condition and executes fixed logic. It has a goal only because a programmer wrote one into it.

Take an LLM wrapper. It may look more flexible because natural language sits in the middle.

But the workflow is still usually designed by humans - plan, call tool, inspect result, retry, summarize, stop.

Take a multi-agent framework. It may create a “researcher,” “planner,” “critic,” and “writer.”

But if a developer assigned the roles, fixed the communication protocol, and wrote the stopping rules, the society did not emerge. It was staged.

Again, none of this makes the software useless.

In fact, these patterns are some of the most practical ways to build with LLMs today.

But it does mean that the system’s “agency” often belongs to the software architecture around the model, not to the model itself.

Agentic vs Agentive

The paper’s most useful move is the language.

An agentic system can act toward a goal, but the structure of its behaviour is mostly external.

1. Humans provide the objective.
2. Engineers define the tools.
3. The workflow decides when to plan, when to call a tool, when to stop, and when to retry.

An agentive system internalizes more of those structures. It does not just receive a task; it maintains and decomposes goals. It does not just follow a system prompt; it evolves a self-model.

It does not just run a fixed chain-of-thought; it decides when deeper reasoning is worth the cost. It does not just get retrained by engineers; it learns from real and simulated experience.

The paper analyzes agency across five dimensions:

1. Goal
2. Identity
3. Decision-making
4. Self-regulation
5. Learning

This framing is useful because it stops the debate from becoming vague.

Instead of asking, “Is this an agent?” we can ask better questions:

1. Does it maintain long-term goals?
2. Does it decompose those goals into subgoals without being hand-held?
3. Does it know what it can and cannot do?
4. Does it decide when to think harder?
5. Does it learn after deployment?
6. Does it improve from simulated experience?

Most current LLM systems fail several of these tests. They may be agentic, but not agentive.

Why Short-Term Instructions Are Not Enough

Many current agents are driven by short-term instructions.

• “Fix this bug.”
• “Find flights under $500.”
• “Summarize these documents.”
• “Open a PR.”

That is fine for bounded tasks. But real autonomy often requires goals that persist across time.

The paper gives the idea of moving from step-by-step instruction to hierarchical decomposition. Instead of supplying every subgoal manually, a stronger agent should be able to receive a long-term objective and break it into ordered, revisable subgoals.

That sounds abstract, so let’s make it practical.

A current coding agent may handle:

Refactor this controller into a service class.

A more agentive engineering system would handle:

Reduce checkout failure rate over the next quarter without hurting conversion.

That larger goal requires investigation, prioritization, code changes, experiments, monitoring, rollback planning, and learning from production feedback. No single prompt captures the whole trajectory.

The difference is not just task length. It is where the decomposition happens.

If a human product manager, tech lead, QA engineer, and platform engineer keep breaking the work down, the AI is a powerful assistant.

If the system can maintain the objective, form subgoals, revise them as evidence changes, and decide when to escalate, it begins to look more agentive.

Identity Is Not Just a System Prompt

The paper’s section on identity is one of the most interesting parts.

In most LLM applications, identity is a prompt:

You are a senior backend engineer.
You write secure, maintainable Java code.
You have access to these tools.
Never modify production files directly.

This is useful, but it is static.

A real agent needs a self-model that changes with experience. It should know what it is good at, where it is weak, which tools it can use, what risks it tends to miss, and how its relationships with other agents or humans are changing.

The authors call this adaptive identity. They argue that current systems usually define identity externally through prompts, configuration files, tool descriptions, and harness engineering.

For developers, this exposes a weakness in many production agents.

We spend a lot of effort telling agents what they are allowed to do. But we rarely give them durable mechanisms for discovering what they are actually capable of doing.

A useful engineering agent should be able to say:

{
  "known_strengths": ["unit test generation", "API migration", "log summarization"],
  "known_weaknesses": ["ambiguous UI bugs", "database deadlock analysis"],
  "recent_failures": ["missed null case in payment retry flow"],
  "confidence_policy": "ask for review before modifying billing logic"
}

That is closer to a self-model than a role prompt.

It is still not “consciousness.” It is engineering discipline. A system that tracks its own limits is easier to supervise than one that performs confidence on demand.

Planning Should Not Always Be On

Another strong point in the paper is self-regulation.

Current agents often fall into two extremes.

1. Some rely on unconstrained reasoning. The model thinks for as long as the inference setup allows, and we hope the extra tokens help.
2. Others use fixed workflows. Always plan first. Always call a critic. Always run three agents. Always use model-predictive control. Always reflect after every action.

Both approaches are crude.

The paper argues for a learned configurator, a kind of System III, that decides when the agent should act directly, continue an existing plan, create a new plan, revise goals, or enter learning mode.

This makes intuitive sense.

• A human pilot does not run a full strategic planning routine before adjusting a control surface in turbulence.
• A surgeon does not hold a committee meeting before every hand movement.
• A senior engineer does not write a 20-step plan before renaming a variable.

But in high-stakes or unfamiliar situations, deeper planning matters.

That is the missing control layer in many agent systems. We do not just need better reasoning. We need systems that know when reasoning is worth it.

The World Model Is the Simulator, Not the Agent

The paper also insists on a separation between an agent model and a world model.

The world model predicts what will happen. The agent model decides what to do.

That distinction sounds simple, but it is easy to blur. If one model is trained both to predict reality and to maximize reward, the prediction side can become distorted by the action objective. The authors argue that the world model should be trained separately for next-state prediction, while the agent model uses it for planning.

For developers, the analogy is straightforward. Do not confuse your simulator with your policy.

In software terms:

class WorldModel:
    def predict(self, state, action):
        """What is likely to happen next?"""
        ...

class AgentModel:
    def choose_action(self, state, goal, identity):
        """What should I do next?"""
        ...

The first object should be optimized for fidelity. The second should be optimized for goal-directed behaviour.

When the two are mixed carelessly, debugging becomes harder.

Did the system fail because it wanted the wrong thing, predicted the wrong consequence, chose the wrong plan, or executed badly?

Separate components make failure analysis less mystical.

Why This Paper Matters Now

The timing of this paper is really good.

The AI industry is moving quickly from chatbots to agents.

HackerNoon is full of articles about coding agents, workflow agents, agent security, agent memory, production world models, and guardrails. That reflects the real shift happening in software teams - agents are becoming part of engineering workflows, not just demos.

But the vocabulary is still messy.

When every tool is an agent, the word stops telling us much.

This paper gives builders a stricter test. It does not dismiss today’s agents.

It simply says: be honest about what you built.

• If your system’s goal is supplied at every step, call it a task runner.
• If its identity is a system prompt, call it a configured assistant.
• If its learning stops at deployment, call it a frozen model inside a workflow.
• If its reasoning depth is hard-coded by the developer, call it a scaffolded pipeline.

Those are all valid systems. They just are not full agentive systems.

The Practical Takeaway

I do not read this paper as saying, “Current agents are bad.”

I read it as saying, “Current agents are mislabeled.”

That is a healthier interpretation.

The next generation of agents probably will not be created by adding more tools to the same loop forever. It will require models that internalize more of the machinery we currently write around them.

The five questions I would now ask before calling anything an agent are:

1. Does it maintain goals beyond a single prompt?
2. Does it update a self-model from experience?
3. Does it use a world model to simulate consequences?
4. Does it regulate when and how deeply to reason?
5. Does it decide when and how to learn?

If the answer is mostly no, I would still build it. I would just call it what it is: an agentic pipeline.

That small naming correction matters.

Because once we stop confusing pipelines for agents, we can start building systems that deserve the name !