Mind Over Modules: How Smart Agents Learn What to See—and What to Be

TL;DR for operators

Agentic AI is not only a model-selection problem. It is an environment-design problem.

Two recent papers make that point from opposite ends of the stack. One studies LLM agents in a controlled repeated routing game and shows that the way history, rewards, and peer actions are represented can significantly change behaviour.¹ The other proposes SwarmAgentic, a framework that automatically generates and optimises agent roles, execution policies, and collaboration structures using a language-based version of particle swarm optimisation.²

The useful operator lesson is simple, if slightly inconvenient: more context is not always better, more agents are not always smarter, and more collaboration can become beautifully formatted confusion unless it is measured against an objective.

For business teams building AI copilots, workflow agents, customer-service automations, planning agents, or internal decision-support systems, the practical question is not merely, “Which LLM should we use?” It is:

What should the agent see, what feedback should it receive, what role should it play, and how should the whole system revise itself after failure?

That is where the real architecture lives. The model is the engine. The state representation, feedback loop, role design, and collaboration flow are the road, dashboard, traffic rules, and maintenance manual. Naturally, vendors prefer to sell the engine.

The problem: agents do not “remember” the world unless we build the memory

LLMs are not stable decision-makers by default. They are stateless text processors wrapped in application logic. Every “agent” system must therefore decide how to translate the world into a prompt, tool call, memory object, workflow step, or structured summary.

That translation is usually treated as implementation detail. It is not.

In a production system, the agent may receive previous customer messages, CRM fields, tool logs, policy documents, task outcomes, error messages, supervisor feedback, calendar constraints, or the results of earlier agent decisions. Each of those can be exposed in many forms: raw transcript, compact table, score, exception list, ranking, regret signal, checklist, or narrative summary.

The first paper asks what happens when that representation changes in a controlled strategic environment. The second asks how entire agentic systems might be generated and optimised rather than hand-crafted one role at a time. Together, they point toward a useful conclusion:

Agentic AI performance depends on designing the information environment around the model, then iteratively improving that environment through measurement.

This is not as glamorous as claiming the agents have “emergent organisational intelligence”. It is also more likely to survive contact with an accounts payable workflow.

Paper one: the agent’s “state” is not neutral

The first paper, The Effect of State Representation on LLM Agent Behavior in Dynamic Routing Games, studies GPT-4o agents playing repeated selfish routing games. The setting is deliberately controlled: multiple agents repeatedly choose routes through a congestion network, and the authors can compare the agents’ behaviour with known game-theoretic equilibrium predictions and prior human-subject evidence.

The important move is not the traffic metaphor. It is the experimental design.

The authors vary the natural-language state representation along three axes:

They test combinations of these choices across repeated games and evaluate behaviour using route choices, payoffs, regret, switching behaviour, and convergence toward equilibrium.

The headline finding is almost rude to fashionable prompt design: summarised representations generally produce behaviour closer to equilibrium than full chat histories. The paper reports that summarised prompting reduces regret and produces more stable behaviour across the routing games. In other words, giving the agent the whole conversation can make it worse, not wiser.

This should surprise no one who has watched a model confidently over-interpret the last thing it read. But it is useful to see the pattern tested in a structured setting.

The second finding is that regret feedback can outperform raw payoff feedback, especially where there is a meaningful distinction between better and worse actions. Raw payoff tells the agent what it received. Regret tells the agent how far it was from a better choice. That difference matters because it turns feedback into a directional signal.

The third finding is more counterintuitive: seeing only one’s own actions tends to reduce instability. More visibility into everyone else’s behaviour can invite anticipatory reasoning, but the model may then make poor inferences or chase noisy patterns. Apparently, “everyone’s actions” is not always operational intelligence. Sometimes it is just gossip with a table header.

What this paper shows

The paper shows that LLM agent behaviour can be materially shaped by how history and feedback are encoded. In this experiment, compressed summaries, regret-style feedback, and narrower peer-action visibility often made the agents more stable and more equilibrium-like.

What it does not show

It does not prove that summarisation is always superior, regret is always the best feedback, or limited information is always optimal. The environment is a stylised repeated routing game with known equilibria and a specific model setup. The business interpretation should therefore be cautious: representation choices should be tested, not copied blindly.

Still, the lesson is sharp. When an agent fails, the culprit may not be “the model”. It may be the dashboard we gave it.

The bridge: state design becomes system design

The routing-game paper is a microscope. It isolates how the agent’s view of history changes behaviour. But business systems rarely contain one agent making one choice in a clean game.

Real agentic systems involve roles, workflows, tools, memory, validation steps, escalation rules, and task-specific policies. A customer-support agent may need a triage role, a policy-checking role, a refund-calculation role, and a final-response role. A planning agent may need constraints, candidate generation, verification, exception handling, and repair. A finance agent may need evidence retrieval, calculation, risk review, and approval routing.

Once we accept that representation matters, the design space explodes. We are no longer tuning a prompt. We are deciding:

This is where the second paper enters. It takes the larger system-design problem and asks whether agentic architectures themselves can be generated and refined automatically.

Paper two: SwarmAgentic turns agent design into a search problem

SwarmAgentic: Towards Fully Automated Agentic System Generation via Swarm Intelligence proposes a framework for generating agentic systems from scratch and improving them through a language-driven adaptation of particle swarm optimisation.

The paper’s core idea is to represent each candidate agentic system as a “particle”. Each particle contains an agent set and a collaboration structure. Each agent has an identifier or role, a responsibility, and an execution policy. The collaboration structure defines how the agents execute steps and coordinate.

Instead of optimising numerical vectors, SwarmAgentic performs structured language transformations. The system begins by generating a diverse population of candidate agentic systems from only a task description and objective function. It then evaluates performance, identifies flaws, and updates candidate systems using three forms of guidance:

The authors evaluate SwarmAgentic on six open-ended or structured tasks, including TravelPlanner, Natural Plan tasks, creative writing, and MGSM. They report that SwarmAgentic outperforms baselines across the evaluated tasks, including a reported 261.8% relative improvement over ADAS on TravelPlanner. Their ablations also suggest that failure-driven adjustment, agent-level adaptation, collaboration-structure reconfiguration, more iterations, and larger particle counts all contribute to performance.

The case study is especially useful. On TravelPlanner, the system improves by introducing a Quality Assurance Specialist, adding verification for accommodations, and then refining that role to enforce budget compliance. In plain English: the system learned that “make a plan” was insufficient. It needed a verifier. Then it needed a verifier with sharper constraints.

That is not magic. That is organisational design, automated badly enough to be research and well enough to be interesting.

What this paper shows

SwarmAgentic shows a plausible path for automatically searching over agent roles, policies, and collaboration workflows. It treats agent-system design as an optimisation process rather than a one-off act of prompt craftsmanship.

What it does not show

It does not eliminate the need for grounded evaluation. The paper itself notes limits around hallucinations, error propagation through optimisation cycles, and the fact that SwarmAgentic operates in text-based environments rather than embodied, sensor-rich real-world settings. Its strongest evidence is on benchmarked planning, scheduling, creative, and reasoning tasks—not on messy enterprise systems with legacy software, incomplete records, compliance exposure, and human politics. The glamorous phrase “fully automated” should therefore be read with the usual enterprise translation: “promising, provided someone defines the objective and checks the damage.”

The complementary logic chain

These papers are best read not as two separate summaries, but as two links in one design argument.

Step 1: LLM agents need constructed state

Because LLMs rely on supplied context, every agentic system must encode history, feedback, constraints, and task state in some representation. That representation is an architectural choice, not a formatting choice.

Step 2: State representation changes behaviour

The routing-game paper demonstrates that alternative state representations can produce meaningfully different agent behaviour in a repeated strategic setting. Summaries, regret feedback, and narrower action visibility can improve stability and equilibrium-like outcomes in that controlled environment.

Step 3: Representation is only one part of the design surface

Once state matters, so do roles, responsibilities, collaboration structures, validation steps, and feedback loops. An agent’s performance depends not only on what it sees, but also on what it is supposed to be.

Step 4: System design can be searched

SwarmAgentic proposes that agentic systems can be generated as candidate structures and refined through population-based, feedback-guided search. It automates part of what human AI engineers currently do manually: invent roles, arrange steps, test failures, and revise the workflow.

Step 5: Production agent systems need instrumentation, not vibes

The combined conclusion is operational: agentic AI should be built as an experimental system with explicit objectives, logged failures, state variants, role variants, workflow variants, and measurable evaluation.

The wrong lesson is “let the agents self-improve and go for lunch.”

The right lesson is “define the objective, structure the feedback, test the representation, search the workflow space, and keep humans in the loop where the cost of being wrong is non-trivial.” Less catchy, admittedly. Also less likely to ruin your quarter.

The operator’s framework: what to tune before blaming the model

When an agent underperforms, business teams often jump straight to model replacement: move from one frontier model to another, increase context length, add retrieval, add another agent, add a supervisor agent, add a debate loop, add a committee, add a small village.

The two papers suggest a better diagnostic sequence.

The point is not that every business system needs swarm optimisation. Most do not. Many first need basic logging, evaluation datasets, and a definition of success more precise than “make the output better”.

But once those basics exist, the search space becomes worth exploring. You can test whether agents should see raw transcripts or summaries. You can test whether feedback should be KPI-based, regret-based, rule-based, or exception-based. You can test whether a planner needs a verifier, whether a verifier needs domain rules, and whether a workflow needs three agents or one agent with a checklist.

This is how agentic AI becomes engineering rather than theatre.

What changes for business AI strategy

The practical business implication is that agentic AI projects should be managed like operating systems.

An operating system has memory, scheduling, permissions, feedback, error handling, and monitoring. So should serious agentic workflows. A model call wrapped in a cheerful persona is not an operating system. It is a chatbot wearing a lanyard.

For managers, the shift is from “deploy an agent” to “manage an agent environment”.

That means:

1. Define state deliberately. Decide what the agent sees, in what format, at what level of compression, and over what time horizon.

2. Design feedback as a learning signal. Raw success/failure logs are useful, but directional feedback is often more actionable. In business workflows, this may mean showing the agent which constraint it violated, which alternative would have worked, or how far the output was from a target.

3. Treat roles as hypotheses. A “planner”, “reviewer”, “researcher”, or “compliance checker” is not inherently useful. It is useful only if it improves measured outcomes.

4. Optimise collaboration, not headcount. Adding agents is easy. Making handoffs coherent is the hard part. Multi-agent systems can fail like badly run meetings: everyone speaks, nobody owns the outcome.

5. Run controlled variants. Test state format, feedback type, role design, and workflow order. Keep the variants that improve the metric you actually care about.

6. Respect the boundary conditions. The evidence here supports disciplined experimentation. It does not prove that autonomous agent factories are ready to run procurement, claims handling, audit review, or trading without strong controls.

This is especially relevant for companies moving from simple AI assistance to delegated execution. Once an agent can send emails, approve refunds, schedule work, alter records, or trigger downstream actions, the cost of bad state representation rises. The agent is no longer merely wrong in a chat window. It is wrong inside the business process.

That is a different sport.

The misconception to avoid

The obvious misconception is that more is better.

More context. More agents. More collaboration. More self-reflection. More loops. More orchestration diagrams with arrows that imply competence.

The routing-game paper pushes against this by showing that compressed summaries can outperform full chat histories, and that less visibility into others’ actions can reduce instability. The SwarmAgentic paper also pushes against naïve complexity, although from another direction: extra structure helps when it is evaluated, refined, and selected against a clear objective.

So the better principle is not “add more intelligence”. It is:

Add only the structure that improves measured behaviour.

A small, well-instrumented agent with the right state and feedback can beat a large, theatrical agent team that confuses conversation with coordination. This will disappoint people who enjoy drawing boxes. They will recover.

Where this leaves agentic AI

The next generation of practical agent systems will not be defined only by larger models or longer context windows. It will be defined by better state design, better feedback design, and better automated search over workflows.

The first paper gives us the warning: the way an agent sees the world changes how it behaves. The second gives us the scaling idea: the way an agent system is organised can itself become an optimisation target.

Together, they move the conversation from “Can the model reason?” to “Have we designed the conditions under which reasoning becomes useful?”

That is the question operators should care about. Not because it is glamorous, but because it is where most real failures hide.

In enterprise AI, the agent’s “mind” is not just inside the model. It is distributed across the prompt, memory, feedback, tools, roles, workflow, evaluation function, and human governance around it. Change those, and you change the agent.

Mind over modules, then. But also metrics over mythology.

Cognaptus: Automate the Present, Incubate the Future.