Your agent probably isn't an agent. What genuine agency requires.
MBZUAI and CMU distinguish agentic systems (competence in scaffolding) from agentive systems (capabilities from internal organization). The GIC architecture proposes what genuine agency requires.
TL;DR: A new paper from Xing et al. (MBZUAI + CMU) argues that most systems labeled agents today are better described as agentic — their competence lives in external scaffolding, not internal organization. The paper draws a precise boundary between agentic and agentive systems across five dimensions, proposes the GIC architecture for building genuinely agentive systems, and argues that modular, inspectable architectures are inherently safer than monolithic ones.
I read the Critique of Agent Model paper because the title was provocative. “Critique of Agent Model.” I expected a survey of what works and what doesn’t in current agent systems. What I got was something more uncomfortable: an argument that most things called agents today should not be called agents at all.
Not because they don’t perform useful work. They do. Claude Code ships features. AutoGen orchestrates research teams. Cursor completes repository-level refactors. These systems are genuinely valuable.
But the paper’s core claim is that their competence lives outside the model. In the harness code. In the prompt templates. In the predefined workflows and tool definitions. The system performs tasks, but it doesn’t own its own decision-making.
This distinction matters because it determines what breaks when something goes wrong and what you need to build to fix it.
Key takeaways:
- The agentic vs agentive distinction separates systems whose competence lives in scaffolding from systems whose capabilities arise endogenously
- Current agent systems are overwhelmingly agentic . Their goals, identity, decision-making, and learning are externally prescribed
- The GIC architecture proposes six components that together internalize the five dimensions of agency, paired with a separately trained world model
- Separating the agent model from the world model is the critical architectural choice — conflating them undermines the reliability of both planning and simulation
- Modular, inspectable architectures make safety manageable: every failure mode maps to a specific component that can be diagnosed and fixed independently
What did the paper actually find?
The paper surveys the current landscape of systems labeled as agents and classifies them into five tiers by how much of their behavioral organization is internalized:
- Program-based systems (thermostats, Selenium scripts) . All behavior externally prescribed
- LLM wrapper systems (Claude Code, Cursor, AutoGen, OpenClaw) — flexible reasoning inside a rigid scaffold. Goals, identity, and planning live in the harness
- LLM-centered systems (DeepSeek V4, OpenAI Operator) . More reasoning internalized, but goals and identity are still externally specified
- Model-less physical systems (industrial robots) . High physical competence, but task logic is external
- Embodied-model systems (Figure Helix, physical intelligence π-series) . Closest to internally organized agents, but still missing goal decomposition, identity evolution, and self-directed learning
The pattern across all five tiers: the structures that produce goal-directed behavior are overwhelmingly external to the model. The label “agent” conceals this fact.
The paper organizes its critique around five dimensions of agency. For each, current practice is described and the limitation is diagnosed:
| Dimension | Current practice | Limitation |
|---|---|---|
| Goal | Short-term instructions at every step | Cannot pursue long-term objectives autonomously |
| Identity | Fixed system prompts and config files | Adaptation requires external re-engineering |
| Decision-making | End-to-end black-box policies | No mechanism to verify or correct internal reasoning |
| Self-regulation | Emerges from unconstrained RL or fixed workflows | No learned allocation of deliberation effort |
| Learning | Human-scheduled training pipelines | Learning terminates at deployment |
What is the agentic vs agentive distinction?
This is the paper’s most useful contribution.
Agentic systems have their competence in external scaffolding. The harness code defines how goals are decomposed, what identity the system adopts, how decisions are made, when to deliberate, and how learning happens. The model inside provides flexible reasoning and instruction-following, but it’s a component in an engineered workflow, not the seat of agency.
Agentive systems have capabilities that arise endogenously. The system internalizes goal decomposition, identity evolution, simulative decision-making, self-regulated deliberation, and self-directed learning. The model doesn’t follow a workflow — it generates one.
The distinction isn’t about how capable the system is. An agentic system can be more capable in narrow domains than any existing agentive system. The distinction is about where the competence lives and what happens when the environment shifts outside the engineered workflow.
Kitchen analogy: An agentic system is a line cook following a recipe card. The recipe tells them what to do at every step, what ingredients to use, and when the dish is done. The cook provides the execution. An agentive system is a chef who decides what to cook, plans the menu, adjusts for what is fresh at the market, and learns from last night’s service. Both produce food. One produces what they’re told. The other decides what to make.
What is the GIC architecture?
GIC (Goal-Identity-Configurator) is the paper’s proposal for what an agentive architecture looks like. It has six components, organized into three systems:
System I — Actor (α): Handles reactive, routine decisions where deliberation costs outweigh benefits. The pilot’s instinctive stall recovery. The driver’s automatic brake when a child runs into the street. Fast, cheap, pattern-based.
System II — Simulative Planner (πf): When planning is needed, the simulator proposes candidate actions, queries the world model f for predicted consequences, evaluates goal progress through the critic, and selects the best plan. This is explicit counterfactual reasoning grounded in a predictive model of the world.
System III — Configurator (κ): The meta-controller. Decides how and how much to deliberate for each situation. Act directly? Plan carefully? Re-plan an existing course? Retreat into learning and practice? This is the self-regulation mechanism that current systems lack entirely.
The other three components support these systems:
| Component | Function | Training signal |
|---|---|---|
| Belief Encoder (h) | Maps observations to belief state | Self-supervised on sensory data |
| Goal Decomposer (δ) | Breaks long-term goal into subgoals | Goal-oriented trajectory data |
| Identity Evolver (ι) | Updates self-model from experience | Performance feedback |
Why must the agent model be separate from the world model?
This is the paper’s sharpest architectural claim.
The world model f predicts what will happen next. It’s trained on next-state prediction — a self-supervised signal. The agent model decides what to do. It’s trained on goal-directed feedback — a reward signal.
These are fundamentally different tasks with fundamentally different training signals. Conflating them — as recent joint world-action generators do — means the same parameters are simultaneously optimized for prediction accuracy and reward maximization. The result is that the model learns to predict reward-maximizing outcomes rather than actual world dynamics, undermining the reliability of both planning and simulation.
The two models can share activations in an end-to-end system. But their parameters must be disjoint. No gradient from the agent’s reward objective flows into the world model’s parameters. This separation is what makes diagnosis possible when something goes wrong: is the agent making bad decisions, or is the world model making bad predictions? With separate parameters, the answer is unambiguous.
Is this architecture actually safe?
The safety section is worth reading carefully because it inverts the standard concern. Most safety arguments treat autonomous agents as inherently riskier because they have more capability to cause harm. The GIC paper argues the opposite: modular, inspectable architectures are safer because they make failure modes diagnosable.
Every component produces explicit outputs:
- The goal decomposer outputs explicit subgoals. A harmful subgoal is a training error in δ, not emergent misalignment from an opaque model.
- The configurator outputs an explicit regulation decision. Selecting an unsafe action is a training error in κ, not a value alignment problem.
- The world model outputs explicit predictions. An inaccurate prediction is a training error in f, not a sign of deceptive behavior.
The paper’s closing argument: “The relevant question isn’t whether risk exists during learning, but whether the architecture makes it manageable and decreasing. The alternative of forgoing autonomous agent models is unrealistic, as the capabilities they offer are genuinely useful, and the aspiration to build them is as old as the field itself. The choice is whether they’re developed within transparent architectures where failures can be isolated and corrected, or within opaque ones where they cannot.”
Tradeoff: The GIC architecture sacrifices the simplicity of end-to-end training for the auditability of modular components. This is a real cost. Training six specialized components with disjoint parameters and different training signals is harder than training one big model end-to-end. The paper argues this cost is worth paying because it makes the system inspectable, debuggable, and improvable. Whether this tradeoff holds at scale is the open question the companion papers [23, 24] are designed to answer.
What does this mean for how you build agents today?
The practical takeaway isn’t that you should drop everything and build a GIC system. The practical takeaway is that you should know where your agent’s competence actually lives.
If you use Claude Code, the model provides flexible reasoning but the competence for repository-level coding lives in the harness — the file editing protocol, the test-running loop, the lint-fix cycle. If you use AutoGen, the orchestration graph provides the multi-agent structure. If you build a RAG pipeline, the retrieval + prompt template provides the domain adaptation.
Understanding that your system is agentic, not agentive, tells you where to invest:
- Improving the harness often produces larger gains than upgrading the model
- Adding explicit verification of each step (like the C-A-F loop from the companion paper) compensates for the lack of internalized feedback
- Planning for distribution shift means your static workflows will need redesign when tasks change
The paper doesn’t offer a build-it-today recipe. It offers a direction. Agentive systems that internalize their own goal decomposition, identity, self-regulation, and learning are the right target. Current systems will evolve toward them, and the architectures that win will be the ones that make that internalization possible without losing the practical capability that today’s scaffolded systems already deliver.
FAQ
What is the difference between agentic and agentive systems? Agentic systems have their competence in external scaffolding . Tools, prompts, predefined workflows, harness code. The system performs tasks but doesn’t own its own decision-making. Agentive systems have capabilities that arise endogenously — the system has internalized goal decomposition, identity, decision-making, self-regulation, and learning. Claude Code, Cursor, and AutoGen are agentic. Truly agentive systems barely exist yet.
What is the GIC architecture? GIC stands for Goal-Identity-Configurator. It’s a six-component architecture that separates the agent model from the world model. The six components are: belief encoder, goal decomposer, identity evolver, configurator (System III), simulative planner (System II), and actor (System I). The agent model decides what to do; the world model predicts what will happen. They are trained separately on different signals.
Why should the agent model and world model be kept separate? Because they serve fundamentally different purposes and should be trained on fundamentally different signals. The agent model is shaped by goal-directed feedback (reward signals, task success). The world model is shaped by fidelity-driven next-state prediction. Collapsing both into one model, as joint world-action generators do, conflates reward-driven action selection with prediction accuracy, undermining the reliability of both planning and simulation.
Is the GIC architecture safe? What about instrumental subgoals and alignment? The paper argues GIC is structurally safer than monolithic systems because every component is explicit and inspectable. A harmful subgoal is a training error in the goal decomposer, not emergent misalignment. Reward hacking traces to a misspecified reward function. Unsafe exploration traces to an undertrained configurator. Each failure mode is diagnosable at the component level. The paper’s closing argument: building agents with the right architecture is itself a safety intervention.
Who should care about the agentic vs agentive distinction? Anyone building or deploying AI agents in production. If you use Claude Code, Cursor, AutoGen, or any scaffolded agent system, you are working with an agentic system. Understanding where your system’s competence actually lives — in the harness code and prompts, not in the model’s internal decision-making — is essential for knowing what can break and how to fix it. The agentive benchmark gives a direction for what comes next.
Related Posts
- Loop engineering: production agent loop patterns. The 8 canonical patterns for agent orchestration. Most are agentic patterns by the paper’s definition — knowing this helps you decide when they apply and when they don’t.
- Claude Code harness architecture: 98% isn’t the model. Research showing 98.4% of Claude Code’s codebase is harness, not AI logic. A concrete example of the agentic thesis.
- Your agent finished. That doesn’t mean it worked.. Why trajectory-level evaluation matters more than task completion — and how modular architectures make this evaluation possible.
This article was published on Agentic Up (https://agenticup.dev): practical guides for developers and founders building with AI agents. Reach me at [email protected]
