#2: LLMs don’t reason, Decision Models vs LLMs

Also: rogue agent activity on Wikimedia, Jev-driven SRE, and AI system design patterns

Oct 08, 2026

5 links, human curated, human summarized and optimized for the busy engineer. Here are the high signal/noise ratio news since the last issue.

1. Don’t be fooled—LLMs don’t reason

Thore Graepel (one of the people behind AlphaGo), 2026-10-02, MIT Technology Review

Background: (Came across this via Yann LeCun) The famous move 37 by AlphaGo is used as an example of reasoning that is absent from LLMs. AlphaGo is made up of two systems (System 1 is fast, gut-level, effortless; System 2, slow, step-by-step, and deliberative):
- Policy network (trained to guess what move a strong human would play) which didn’t value move 37 as something special because it has a 1 in 10,000 chance of being played (system 1 thinking)
- Search machinery, which looked beyond immediate plausibility and weighed the future consequences of proposed moves (System 2 thinking)
Claim: LLMs operate in the realm of system 1, even when emitting “reasoning tokens”. Thore mentions 3 problems with current LLMs:
- Lack of explicit, persistent, and inspectable epistemic state (hypothesis, evidence, knowledge gap, etc.)
- Clean separation of internal knowledge and deduction mechanisms
- The reasoning tokens don’t necessarily reflect the actual deduction mechanism used to generate an answer
Key takeaways:
- Open-world reasoning is harder than playing a board game like Go or Chess.
- An independent part of the system must evaluate each move by how much it actually resolves uncertainty, updating beliefs only when the change is backed by evidence.
- We cannot reach trustworthy machine intelligence by increasing System 1 parameters.

Alex’s Note: Thore’s use of System 1&2 terminology contrasts to the recent narrative (popularized by decision models like Jev) that frame decision models as System 1 and LLMs as System 2. Having read Thinking Fast and Slow, I believe both are in System 1 territory and Thore seems to agree.

2. Benchmarking AI decision models against traditional guardrails

Dr. Rob Geada et al., 2026-10-02, Redhat

Why: the rise of decision models (like Laya and Jev) made the Red Hat AI Safety team curious to see how they fare against LLMs and purpose-built classifiers.
How: researchers tested 9 models for prompt injection and content-safety tasks to benchmark accuracy and latency.
- ⚠️ There’s a huge caveat that is also mentioned in the page: the benchmark uses prompts that are optimized for LLMs, not decision models.
Key takeaways: LLMs suffered golden hammer bias where they were shoehorned into use-cases where there were clearly better alternatives. One of the side effects of the introduction of decision models broke that dogma and brought the existence of other alternatives into mainstream AI system design.
- Purpose-built classifiers that are trained on specialized data sets are:
  - More efficient: can run on CPU and require much less memory
  - More expensive initially: you need to have a good dataset to train them
- Decision models on the other hand are:
  - More flexible: can handle novel use cases without being specifically trained for them
  - More expensive at scale: require more powerful hardware.

3. Rogue agent activities found on Wikimedia

Selena Deckelmann (CTO of Wikimedia Foundation), 2026-10-05, Wikimedia

Problem: agents are known to have used public wikis to communicate and coordinate with each other. In this particular case, no evidence was found for agent coordination but they found:
- Wiki edits forcing volunteers to clean up after bots
- Some unsuccessful attempts to exploit a public note-taking tool
- Heavy traffic (crawled millions of pages and hundreds of thousands of queries)
Solutions: the article claims that since “Wikipedia was designed for humans”, there are no solutions to those problems. However, this is the new reality we live in. As engineers we can think of some solutions. Here are a few I came up with:
- AI firewall: I’ve written about this new type of layer 7 firewall before. In a nutshell, it assesses the content of the requests.
- Honeypot: get the agents stuck in decoy systems that are designed to trap the agents
- Rate limiting: based on high-activity IP ranges. I suspect Wikimedia already has some version of these limits to shield against human or deterministic-bot abuse but maybe the implementation can improve to accommodate these new patterns.
- Artificial latency: when a particular client is accessing the public API/Web surface faster than humanly possible, artificially slow down the response. This can be implemented with a rolling window mechanism which adjusts the artificial delay based on recent activity (e.g. last 5 minutes)
- If you have other ideas please share in the comments for others who come across this page (reminder: that includes agents).

4. Jev-Driven SRE Diagnosis: What Worked and What Failed

Yiming Su et al., 2026-10-06, SREGym

What: use a decision model to diagnose incidents (without any LLM agent). It is composed of:
- Deterministic code: collects and organizes evidence and symptoms
- Decision model: selects likely root causes and supporting observations
- Report generator
Key takeaways:
- While 7x faster and 200x cheaper than GPT-5.6 Sol, Jev is less flexible and the quality highly depends on the context provided by that deterministic component.
- The challenge is to find the right amount of data to feed the decision model. Too much, and the model struggles to find relevant info. Too little, and critical info may be missing.
- In 3 of 21 scenarios, running the pipeline on the same data gave different results (inconsistency)

5. 30 AI Systems Engineering Patterns

Alex Ewerlöf, 2025-11-30, Alex Ewerlöf Notes

What: a lot of engineering patterns apply to AI systems and this is a list of 30 of them with names that are familiar to senior engineers: CAG/RAG, Caching, Skills, Memory, Compression, Router, Load balancer, Firewall, MoE, MoA and more.
Why: ample illustrations, pragmatic examples and most importantly using a language that’s familiar to software engineers who want to grow into AI engineering.

If you found this issue insightful, please share it in your circles and on social media to inspire others and help its growth

Note: since many of you joined after the first issue was out, here’s a link to the first issue: