INQUIRING LINE

Could a simple rulebook and an AI agent ever be judged fairly on the exact same scoreboard?

Can rules engines and LLM agents be compared by performance metrics?

This explores whether a traditional rules engine (hand-written if-then logic) and an LLM agent can be fairly scored against each other on the same performance numbers. The corpus has no direct head-to-head study, but it says a lot about why a single score misleads when one of the two systems is an agent.


This explores whether you can put a rules engine and an LLM agent side by side and judge them on the same scoreboard. The collection doesn't include a study that runs that exact comparison, so I won't pretend it does. What it does show is that the usual metric, task success rate, is the wrong yardstick for agents. That changes how any comparison should be set up.

The main problem is that two systems with identical success rates can behave very differently underneath. How should we measure agent system performance beyond task success? argues that a single success number hides differences in efficiency, reliability, cost of checking the work, and readiness for real deployment. A rules engine and an agent might both reach 90%, but the engine fails the same way every time, while the agent can fail differently from one run to the next. That gap matters more than the headline number. The agent's failures are also of a kind a rules engine simply can't have. Why do autonomous LLM agents fail in predictable ways? lists four: role flipping, throwaway 'flake' replies, infinite loops, and drifting off-topic. They happen because LLMs don't hold a stable goal or identity. A fair comparison has to count these failure types, not just the wins.

What the reader may not expect is that the most reliable agents increasingly contain rules-engine-like parts. Where does agent reliability actually come from? finds that agent reliability comes less from a bigger model and more from moving memory, step-by-step skills, and structured protocols into a 'harness' around the model. Much of that harness is deterministic structure. Can you turn an LLM into an agent by just fine-tuning? makes a similar point: whether an agent's actions are grounded or made up depends on the surrounding system, not only on the model. So 'rules engine vs. LLM agent' is often a false choice. Real systems are hybrids, and the useful question is how much of the work should be fixed rules and how much should be model judgment.

That also changes what you'd measure. Can language models build and maintain their own agent harnesses? shows that the same harness can perform very differently depending on which model runs inside it. That means you can't credit a result to 'the agent' or 'the rules' without testing each part separately. Are LLM and agent benchmarks really measuring different things? adds that a model's plain-text abilities and its tool-using abilities are two operating modes that need separate checks. On cost, Can small language models handle most agent tasks? finds that most agent work is repetitive and well defined, which is exactly the territory where rules engines have always done well. Small models handle it at 10 to 30 times lower cost than large ones. A fair comparison therefore needs to include cost per task and how consistent the results are, alongside accuracy.

So yes, the two can be compared, but only with several metrics: success, consistency across repeated runs, failure types, cost, and how hard the output is to verify. Measured that way, the comparison often tells you less about which one wins and more about which parts of your workflow belong to each.


Sources 7 notes

How should we measure agent system performance beyond task success?

Single task-success metrics obscure how agents achieve results across memory, context, and verification layers. Research shows identical success rates can mask enormous differences in efficiency, reliability, and deployment readiness—requiring harness-level benchmarks that measure trajectory, memory hygiene, and verification costs.

Why do autonomous LLM agents fail in predictable ways?

Research identifies role flipping, flake replies, infinite loops, and conversation deviation as LLM-specific failures in multi-agent cooperation. These occur because LLMs lack persistent goal representation and stable role identity.

Where does agent reliability actually come from?

Research shows reliable LLM agents externalize three cognitive burdens—memory (state persistence), skills (procedural components), and protocols (structured interaction)—into a harness layer rather than relying on model scale alone. The harness unifies these externalities and eliminates the need for the model to solve the same problems repeatedly.

Can you turn an LLM into an agent by just fine-tuning?

Converting LLMs to action-capable systems requires four distinct stages: curating action-environment-user datasets, training for action grounding, integrating agent infrastructure with memory and tools, and rigorous safety evaluation. The surrounding system and harness determine whether actions are grounded or hallucinated.

Can language models build and maintain their own agent harnesses?

Research shows that LLMs vary sharply in building harnesses across domains, struggle to retain useful intermediate updates during evolution, and produce harnesses whose performance shifts dramatically with different executors—demonstrating that harness quality cannot be inferred from downstream task scores alone.

Show all 7 sources
Are LLM and agent benchmarks really measuring different things?

DELEGATE-52 shows that LLM benchmarks and agent benchmarks test the same model under different operating conditions—completion mode versus tool-using mode—not separate artifacts. Honest evaluation requires assessing both modes to characterize actual capability.

Can small language models handle most agent tasks?

SLMs handle the repetitive, well-defined language tasks that constitute most agent work at 10–30× lower cost than LLMs, making heterogeneous architectures (SLMs by default, LLMs selective) the economically rational design pattern.

Papers this line draws on 8

The research behind the notes this line reads — ranked by how closely each paper relates.