Heuristics, Meet Your Agents: How Role-Based LLMs Rewire Optimization

Trucks do not care whether your routing algorithm is elegant.

They care whether the vehicle arrives, whether the route violates capacity, whether the dispatch plan survives a late order, and whether the whole thing can be recomputed before someone in operations starts calling the system “that AI toy.” Optimization has always lived in this unglamorous place: close enough to mathematics to look pure, close enough to reality to be messy.

That is why heuristics matter. For many combinatorial optimization problems—routing, packing, scheduling, assignment, resource allocation—the exact optimum may be too slow, too expensive, or simply too brittle to chase every time. So practitioners use heuristics: practical rules that produce good solutions without pretending to solve the universe.

The paper “RoCo: Role-Based LLMs Collaboration for Automatic Heuristic Design” asks a timely question: if large language models can write code and reason about algorithms, can they help design better heuristics automatically?¹ More specifically, can a group of role-specialized LLM agents do this better than a single LLM repeatedly asked to mutate and improve candidate rules?

The answer is cautiously interesting. RoCo does not prove that agent swarms are the future of all optimization. Please do not assemble twelve chatbots, give them job titles, and expect your warehouse to become enlightened. What the paper does show is narrower and more useful: within selected automatic heuristic design workflows, role-based collaboration can improve the generation, refinement, and stability of heuristics across several benchmark combinatorial optimization problems.

The key contribution is not “more agents.” It is structured division of cognitive labor inside an evolutionary search loop.

That is where the paper becomes business-relevant.

The hard part is not solving once; it is designing the rule that keeps solving

Automatic Heuristic Design, or AHD, is the effort to generate heuristics automatically rather than relying entirely on human experts to craft them by hand. The paper frames AHD as a search problem over a heuristic space. A candidate heuristic is represented not just as an idea, but as an executable Python function with a score. That score measures how well the heuristic performs over problem instances.

This matters because many business optimization problems are not one-off puzzles. They repeat.

A delivery company does not solve “the routing problem” once. It solves thousands of related routing problems under changing demand, vehicle capacity, fuel cost, driver constraints, traffic assumptions, and service-level promises. A cloud platform does not schedule compute jobs once. It repeatedly decides what to place where, under fluctuating load and hardware availability. A factory does not pack, assign, sequence, or allocate once. It does it every day, and the edge cases are where the spreadsheet goes to die.

Traditional meta-heuristics—genetic algorithms, ant colony optimization, guided local search, simulated annealing, tabu search—give practitioners useful search frameworks. But they often still depend on human-designed operators, scoring rules, penalty functions, or local heuristics. The human expert decides what patterns matter. The machine searches within that design.

LLM-based AHD changes the interface. Instead of merely tuning parameters inside a human-defined heuristic, the model can propose new heuristic code. Earlier methods such as FunSearch, EoH, ReEvo, HSEvo, and MCTS-AHD already explored this direction: use an LLM inside an evolutionary program search loop, evaluate candidate programs, keep the better ones, and repeat.

RoCo’s complaint is that many of these systems still use the LLM as a single general-purpose improver. It may explore, refine, critique, and recombine—but without explicit role separation. That is cognitively convenient for the system designer and cognitively overloaded for the model. The model is being asked to be the wild inventor, the careful engineer, the skeptical reviewer, and the committee chair. A familiar corporate structure, sadly.

RoCo’s alternative is to split those jobs.

RoCo is an add-on to evolutionary heuristic search, not a standalone optimizer

The mechanism is easiest to understand if we begin with what RoCo does not replace.

RoCo is built on top of the Evolution of Heuristics framework. At each generation, the system maintains a population of heuristic candidates. Standard EoH-style operators create new candidates through exploration and modification. RoCo then adds a collaborative multi-agent module that works on selected elite candidates and contributes improved heuristics back into the candidate pool.

In simplified form:

Current heuristic population
        ↓
Standard EoH exploration and modification
        ↓
Elite pair selected for RoCo collaboration
        ↓
Explorer + Exploiter + Critic + Integrator interact over several rounds
        ↓
Short-term reflections become role-specific long-term memory
        ↓
Memory-guided elite mutations generate more candidates
        ↓
All candidates are merged and top performers survive

This is important. RoCo is not saying, “Ask a multi-agent LLM system to solve vehicle routing directly.” It is saying, “Use role-specialized LLM agents to generate better heuristic functions that plug into established optimization frameworks.”

That difference saves the paper from the usual agentic-AI fog machine.

In business terms, the solver remains the adult in the room. The LLM agents are not trusted with final operational decisions. They are used as a search-and-design layer that proposes heuristic code, receives objective feedback, and evolves better rules under evaluation. The result is closer to automated R&D for heuristics than autonomous operations research cosplay.

The four agents separate novelty, refinement, judgment, and synthesis

RoCo uses four role-specialized agents.

The point is not that these roles are philosophically deep. They are useful because heuristic search has an old tension: exploration versus exploitation.

Explore too little, and the system converges on familiar but weak patterns. Explore too much, and it produces charming algorithmic nonsense. Exploit too aggressively, and local improvements trap the search. Critique without generation becomes academic theater. Integration without evidence becomes committee sludge.

RoCo’s architecture tries to make this tension operational. The explorer is pushed toward global diversity. The exploiter is pushed toward incremental efficiency. The critic connects changes in objective value to reflection. The integrator compares and combines outputs based on their scores.

The system also stores reflections across rounds and generations. After several collaboration rounds, the critic’s feedback is distilled into long-term, role-specific memory. That memory is later used to mutate elite candidates. So the loop is not merely “generate, score, forget.” It becomes “generate, score, explain what likely helped or failed, then use that explanation in later mutations.”

That memory layer is one of the paper’s more practically meaningful ideas. In many business contexts, the bottleneck is not the first heuristic; it is accumulating reusable design knowledge across repeated optimization attempts. A system that forgets every failed route-scoring rule is not learning. It is just speed-running trial and error.

The experiments test whether role division improves heuristic generation

The paper evaluates RoCo on five combinatorial optimization problems:

These are standard benchmark families, not messy enterprise deployments. That is fine. Benchmarks are useful when we remember what they are: controlled tests of mechanism, not proof that a factory scheduler will behave nicely next quarter.

The experiments use two main optimization frameworks.

First, under Ant Colony Optimization, RoCo designs heuristic measures that guide solution construction. The paper tests both white-box and black-box prompt settings. In the white-box setting, the LLM receives explicit structural information, such as distance matrices. In the black-box setting, the model has more limited structural access, with information encoded more abstractly.

Second, under Guided Local Search, RoCo evolves penalty heuristics for TSP and embeds the best generated heuristics into KGLS, a strong local-search baseline.

The paper also includes ablation tests. These are not decorative. They answer the important question: is the system better because of role-based collaboration, or because the authors added more LLM calls and machinery?

The main result is competitive breadth, not universal domination

In the white-box ACO setting, RoCo performs strongly across the five problem families. The paper reports that it achieves the best result in 10 out of 15 problem-size combinations among the compared LLM-based AHD methods. It also beats traditional ACO across the reported settings and surpasses DeepACO in most cases.

That is a meaningful result, but the wording matters. It is not “RoCo wins everything.” For example, in white-box TSP at larger size, MCTS-AHD is very strong; in some MKP and BPP settings, other methods are close or better depending on the objective direction. RoCo’s advantage is best described as broad competitiveness plus strong performance across diverse problem types, rather than a clean sweep.

The black-box setting is more interesting for business interpretation. Real systems often have partial, messy, or abstracted access to the full problem structure. The paper’s black-box table does not show RoCo winning every column. ReEvo remains very strong on several TSP and MKP settings. MCTS-AHD is competitive in parts of CVRP. HSEvo is close in BPP. RoCo’s claim is more subtle: it remains strong across problem types and, according to the paper’s Figure 3, shows smaller standard deviations across multiple runs under black-box prompting.

That is the result worth paying attention to. In enterprise optimization, average performance matters, but variance is where trust goes to die. A heuristic generation system that occasionally produces brilliant rules and occasionally produces chaos is not a tool; it is a liability with a demo video.

The paper’s black-box results suggest that role-based collaboration may stabilize heuristic generation when the LLM cannot directly inspect the full problem structure. That is exactly where structured roles and memory should help: when raw prompt intelligence is not enough.

The GLS test asks whether RoCo transfers beyond one template

The Guided Local Search experiment has a different purpose from the ACO tables. It is not merely another scoreboard. It tests whether RoCo-generated heuristics can be useful inside a second optimization framework.

Here, the authors embed RoCo-generated penalty heuristics into KGLS and evaluate TSP optimality gaps across sizes. The most notable result is on TSP200, where KGLS-RoCo reaches an optimality gap of 0.188%, better than KGLS-MCTS-AHD at 0.214%, KGLS-ReEvo at 0.216%, KGLS alone at 0.284%, and EoH at 0.338%. At smaller sizes, several methods already hit or nearly hit zero gap, so the larger instance is the more informative comparison.

This supports a narrower but useful inference: RoCo is not only producing ACO-compatible scoring rules. It can also generate penalty heuristics that improve a strong local-search pipeline, at least for TSP in this experimental setup.

That does not yet prove broad framework portability. One GLS test on TSP is not a passport to every mixed-integer, continuous, stochastic, multi-period planning system. But it does suggest that the role-based collaboration mechanism is not completely tied to one toy interface.

The ablations reveal where the architecture earns its keep

The ablation table is the paper’s most useful section for readers who build systems rather than collect benchmark trophies.

The authors test RoCo variants on TSP under white-box and black-box prompting. They remove the explorer, exploiter, integrator, elite mutation, and multi-agent coordination. They also vary the number of collaboration rounds.

A few patterns matter.

First, removing components generally hurts. Under black-box prompting, removing the integrator is especially damaging: the objective becomes 8.641 ± 0.428, compared with full RoCo at 8.256 ± 0.014. That is not a tiny cosmetic difference. It suggests that fusion is not just administrative glue. When the model has limited structural information, combining exploratory and exploitative trajectories may be central to keeping the search stable.

Second, removing the exploiter hurts black-box performance more than removing the explorer in this table. The “w/o Exploiter” variant reaches 8.400 ± 0.103, while “w/o Explorer” is 8.269 ± 0.005. One interpretation is that under limited information, disciplined local refinement becomes more valuable because exploration has less reliable structural grounding. Creativity without enough map data is just wandering with better adjectives.

Third, removing elite mutation is more damaging in white-box than black-box in the reported TSP ablation. The “w/o Elite Mutation” score is 8.381 ± 0.080 in white-box and 8.266 ± 0.016 in black-box, compared with full RoCo at 8.256 ± 0.023 and 8.256 ± 0.014. That suggests memory-guided mutation helps, but its role may depend on how much structural information is available and on the problem tested. This is a good example of why ablation tables should not be read like religious doctrine.

Fourth, collaboration rounds matter, but only up to a point. One round performs poorly in black-box prompting: 9.341 ± 1.428. Two rounds improve substantially: 8.608 ± 0.512. Three rounds reach 8.254 ± 0.017, essentially matching or slightly beating the full RoCo row in that table. Four and five rounds offer no meaningful additional benefit. The paper interprets three rounds as a balance between performance and efficiency.

That is a very practical finding. More agent conversation is not automatically better. At some point, deliberation becomes expensive prompt theater.

What each experimental block actually supports

This table is the difference between reading the paper as engineering evidence and reading it as a press release. The first is useful. The second is how organizations buy agent platforms and later discover that “multi-agent collaboration” sometimes means “four models confidently sharing the same blind spot.”

The business value is solver augmentation, not replacement

The cleanest business pathway from this paper is not “LLMs will replace operations researchers.” It is this:

1. Many companies already use optimization solvers, meta-heuristics, and rule-based planning systems.
2. Those systems often depend on hand-crafted heuristic components.
3. RoCo-like systems could act as a heuristic discovery layer that proposes, tests, critiques, and mutates candidate rules.
4. Human experts and existing solvers remain responsible for validation, safety, constraints, and deployment.
5. Over time, the system may reduce the cost of heuristic R&D and improve adaptability across repeated planning contexts.

That pathway is less cinematic than autonomous AI, but more commercially plausible.

For logistics, RoCo-like systems could help generate route construction heuristics or penalty functions for local search variants. For warehouse operations, they could explore packing or batching rules under capacity constraints. For scheduling, they could test dispatching or prioritization heuristics. For cloud and compute allocation, they could generate placement or load-balancing rules. For manufacturing, they could propose sequencing heuristics that are later evaluated against simulation or historical data.

The ROI case would not begin with “model intelligence.” It would begin with three measurable frictions:

The important phrase is candidate selection. A production workflow should treat generated heuristics as proposals, not policy. They need sandbox evaluation, regression tests, constraint checks, runtime profiling, and domain review. The fact that a heuristic improves a benchmark objective does not mean it respects labor rules, cold-chain constraints, customer priority tiers, or the CFO’s sacred spreadsheet.

The misconception to avoid: role-based agents are not magic teamwork

The tempting takeaway is that multi-agent LLM collaboration is inherently superior to single-model prompting. The paper does not establish that.

It establishes that, in this AHD setting, with GPT-4o-mini, a population-based EoH-style loop, selected COP benchmarks, ACO and GLS templates, 400 evaluation budget settings, and three collaboration rounds, RoCo is competitive or superior across many tests and shows useful robustness patterns.

That is already enough. It does not need to become mythology.

The stronger interpretation is architectural: when an LLM is used inside an iterative search process, explicit role separation can shape the distribution of generated candidates. The explorer increases diversity. The exploiter sharpens promising ideas. The critic converts score differences into reflection. The integrator prevents the two generation modes from drifting apart. Memory-guided mutation carries lessons forward.

This is not proof that any team of LLM agents will outperform any single LLM. It is evidence that role design can be a control surface in LLM-assisted optimization.

That is a much more useful lesson for builders.

Boundaries before deployment: benchmarks are not factories

The paper is careful enough to give us useful results, but several boundaries matter for business use.

First, the benchmarks are standard and controlled. They are valuable for measuring mechanism, but they do not contain the full mess of enterprise constraints: legal restrictions, human preferences, data latency, exception handling, and conflicting objectives.

Second, RoCo mostly operates within established templates. It designs heuristic measures for ACO and penalty heuristics for GLS. That is a strength for engineering reliability, but also a boundary. The paper is not demonstrating end-to-end autonomous optimization system design from raw business context.

Third, the experiments use GPT-4o-mini and fixed role-specific temperature settings. The explorer uses a higher temperature, the exploiter a lower one, and other roles default to 1.0. These design choices may matter. Different models, budgets, prompts, or evaluation sandboxes could change results.

Fourth, LLM call cost and evaluation cost are not peripheral. The paper reports a cap of 400 LLM API calls per generation and a population size of 10. In a business environment, the economic question is not merely whether the final heuristic is better. It is whether the improvement justifies model calls, solver evaluations, engineering integration, and governance overhead.

Finally, generated code must be treated as untrusted until tested. A heuristic can be mathematically plausible and operationally harmful. It can overfit training instances, exploit benchmark quirks, or introduce runtime behavior that fails under edge cases. Optimization systems are one of the least forgiving places to confuse a clever candidate with a deployable rule.

What Cognaptus would take from RoCo

The practical lesson from RoCo is not “build more agents.” It is “separate the kinds of thinking your system needs, then attach each kind to measurable feedback.”

For optimization-heavy businesses, that suggests a useful design pattern:

Existing solver or meta-heuristic
        +
LLM-generated candidate heuristics
        +
Role-specific critique and memory
        +
Sandbox evaluation across scenarios
        +
Human-supervised promotion into production

This is a sober architecture. It respects what LLMs are good at—generating, recombining, explaining, and mutating symbolic ideas—while keeping objective evaluation and operational validation outside the model’s imagination. Very rude to the model. Very healthy for the business.

RoCo’s broader significance is that it pushes agentic AI away from theatrical conversation and toward structured experimental loops. The agents are not valuable because they talk. They are valuable because their roles produce different candidate distributions, their outputs are scored, their failures are remembered, and their contributions can be ablated.

That is the standard enterprise AI should be held to: not “does the workflow look intelligent?” but “which component improves which measurable outcome, under which boundary?”

RoCo gives a promising answer for automatic heuristic design. It does not solve operations research. It offers a better way to search for the rules that help operations research systems solve.

And for businesses drowning in routing, packing, scheduling, and allocation problems, that may be quite enough.

Cognaptus: Automate the Present, Incubate the Future.