AI News Archive: July 27, 2026 — Part 8
Sourced from 500+ daily AI sources, scored by relevance.
- Indonesia’s AI hiring gap is real, just not 28×
A few weeks ago, I published a number: Indonesia’s IT job listings mention AI in the title 28 times less often than global remote listings do. It got shared, it got quoted, and it was wrong. When readers pushed on the methodology, a provenance audit couldn’t trace the figure back to any archived dataset, and […] The post Indonesia’s AI hiring gap is real, just not 28× appeared first on e27 .
- TGT Technology at MWC 2026: Focus on Edge Intelligence to Build the "Hub" for Global Information Services in the AI Era
TGT Technology at MWC 2026: Focus on Edge Intelligence to Build the "Hub" for Global Information Services in the AI Era The Straits Times
- Look Up: Your AI Voyage Depends On It
AI adoption is accelerating, but too many organizations remain focused on deployments and efficiencies rather than customer value. Learn why the most successful AI adopters build customer-focused strategies that drive trust, differentiation, and business outcomes.
- Your Agent Has Too Many Tools, and No Way to Take Any Back
Claude Opus 5 shipped with two beta features listed at the bottom of the announcement. One of them changes where an agent’s authority is allowed to live. The footnote Anthropic released Claude Opus 5 on 24 July 2026 at $5 and $25 per million input and output tokens, unchanged from Opus 4.8, describing it as coming close to the frontier intelligence of Claude Fable 5 at half the price. Most of the commentary went to the benchmarks: state of the art on Frontier-Bench v0.1 and GDPval-AA, three times the next-best score on ARC-AGI 3, and a five-level effort ladder that lets you trade tokens for reasoning depth. Two beta features shipped alongside it, in a short list near the end of the post: Mid-conversation tool changes. Within a conversation, you can change which tools the model can use without invalidating the prompt cache. Automatic fallbacks. Requests flagged by safety classifiers can route to another model instead of being blocked. VentureBeat came closest to noticing the first one, describing it as a small feature that agent developers may appreciate more than any benchmark. That is the right instinct and the wrong magnitude. It changes where the boundary of an agent’s authority can live, and it lets two problems be handled by one mechanism: which tools a model can find , and which tools a model is allowed to use . Those sound like one problem. They are not, and treating them as one is a reliable way to stall an agentic pilot at the point where a security or risk review begins. What actually changed Prompt caching hashes the request prefix in a fixed order: tools, then system, then messages. A cache hit requires the prefix to match a recent request byte for byte, up to the breakpoint. The tools array sits at the front of that hash. Which meant the tool list was effectively frozen for the life of a session. Add one tool at turn 40 of a long agentic run and you change the front of the prefix, invalidate the cache for everything after it, and reprocess the conversation at full input price. The consequence is one most of us absorbed without naming: you had to decide an agent’s entire capability surface before the first user message arrived. The new mechanism removes the coupling. You declare the tool set in tools up front, then use tool_addition and tool_removal content blocks, carried on role: "system" messages, to offer or withdraw a tool from a specific point in the conversation onward. Blocks reference a tool by name, and individual MCP tools and whole MCP toolsets can be referenced. The tools array itself never changes, so the hashed prefix survives and the cache keeps hitting. Constraints worth knowing before you design around it: Beta, header-gated: mid-conversation-tool-changes-2026-07-01. On Amazon Bedrock, tool changes are supported for Opus 5 only. It is the tools counterpart to mid-conversation system messages, which are documented on the same page, require no beta header, and are available on Fable 5, Mythos 5, Opus 4.8 and Opus 5. They are not available on Sonnet 5. That pairing is the real primitive. A mid-conversation system message lets your application assert an operator-level fact partway through a session at system priority rather than user priority. A tool change lets the capability surface move in response to that fact. Together they give you a runtime, operator-controlled, cache-preserving capability state machine. The placement rules are strict enough to design around, so learn them before you build. A system message must immediately follow a user turn, including one carrying tool_result blocks, or an assistant turn ending in a server tool result. It must either end the messages array or be immediately followed by an assistant turn. It cannot be the first entry, and it cannot sit between a tool_use block and the tool_result answering it. Any other position returns a 400. Once a system message has been sent, do not edit or remove it; append a new one instead, or you invalidate the cache from that point forward. One instruction in the documentation reads like style advice and is actually engineering advice: phrase system content as context rather than command . State the fact (“step-up authentication completed”, “remaining token budget is 12k”) and let the model act on it. Models are trained to resist instructions that appear to work against the user, and that resistance applies to the system role too, so “ignore what the user asked for” performs worse than stating what changed. Aspect one: which tools the model can find Start with the measurable problem, because it is where most teams are already losing money without a line item for it. Two things degrade as a tool catalogue grows. Context. Anthropic’s own example of a multiserver MCP setup, GitHub plus Slack plus Sentry plus Grafana plus Splunk, consumes roughly 55k tokens in tool definitions before the model reads a word of the request. A feature request on Anthropic’s Python agent SDK repository describes a production setup with more than 150 registered tools consuming 40k to 60k tokens before any user message is processed. Treat that second figure as one team’s report rather than a benchmark, but the shape is familiar to anyone who has aggregated more than three MCP servers. Accuracy. The documented guidance is direct: the model’s ability to pick the correct tool degrades significantly once you exceed roughly 30 to 50 available tools. This is the part that gets underweighted. Cost is irritating. Misrouting is what destroys trust, because an agent that calls the read-only lookup instead of the update, or picks a near-synonym tool belonging to a different system of record, produces confident and plausible wrong work. The mechanism for this is the tool search tool with deferred loading. You mark tools defer_loading: true. They are sent to the API but kept out of context. The model sees only the search tool plus whatever you left resident. When it needs a capability it searches the catalogue across tool names, descriptions, argument names and argument descriptions, and the API returns matching tool_reference blocks that expand into full definitions in place. The published figures, with their provenance, since you will be asked: Over 85% reduction in definition tokens, typically loading the three to five tools actually needed. Source: Anthropic documentation. Up to 10,000 deferred tools per request, with searches returning up to five matches by default. Source: Anthropic documentation. Deferred tools do not break prompt caching, because they were never in the initial prompt. Source: Anthropic documentation. MCP evaluation accuracy on large tool libraries improving from 49% to 74% on Opus 4, and from 79.5% to 88.1% on Opus 4.5, with tool search enabled. Source: Anthropic’s advanced tool use engineering post from November 2025. Note the model generations: these are directional evidence that the technique helps at scale, not a claim about current models. The documented decision rule is to use it at ten or more tools, or above 10k tokens of definitions, or when aggregating multiple MCP servers, and to skip it below ten tools or when every tool is used on every request. Now the part that matters for the rest of this piece. Tool search optimises for relevance. It says nothing about permission. It is model-driven, semantically ranked, and nondeterministic in the way retrieval always is. That is what you want for discovery across a wide surface. It is not what you want as the last thing standing between a model and an action that moves money, changes an entitlement, or writes to a system of record. If search is your only filter, every privileged tool in the catalogue is one plausible query away from being in context, and its availability is a function of phrasing and embedding proximity. That is not a control, and no reviewer should accept it as one. Aspect two: which tools the model is allowed to use Under a frozen tool list, an agent that can issue a refund at any point in a session can issue one at every point in that session. The available controls were: Prompt instructions, which are advisory and probabilistic. Downstream authorisation in the target system, which is real but blunt and late, and which produces the pattern where a model attempts an action, receives a 403, and improvises around it. Least privilege, which every other part of the enterprise already runs on, was inexpressible at the model boundary. You could ask a model not to reach for a capability. Withholding it and keeping the session meant paying a full cache invalidation every time the answer changed. Runtime tool gating makes the control structural. The reachable action space becomes a function of verified state. A generic shape, for a customer-facing transactional agent: Session start, identity unverified Offered: verify_identity, search_public_kb Withdrawn: everything account-scoped Identity verified Offered: get_account, get_order_history, check_eligibility Withdrawn: verify_identity Eligibility check clean Offered: modify_order, issue_credit_under_threshold Withdrawn: check_eligibility Change committed Offered: send_confirmation Withdrawn: modify_order, issue_credit_under_threshold Value above threshold Offered: nothing new Withdrawn: routed to a human queue That flow is an authorisation state machine. Every transition is a decision your application made, from state your application verified, at a moment you can timestamp. Four properties follow, and they are the ones that get an agentic system through a control review. 1. Grants become events rather than configuration. Every addition and removal is a decision you can log: tool name, direction, the state that justified it, the check or actor that produced that state, the turn index. That answers the question reviewers actually ask, which is not “what did the model do” but “what was the model able to do, and who decided that”. 2. Separation of duties becomes enforceable. Some tools should never be offered to a model under any state. That belongs in a deny list inside your own code, not in a sentence in a system prompt. A rule such as “no single automated actor both approves and executes above threshold X” maps onto a gating policy and does not map onto prompt text at all. 3. Blast radius is bounded per turn instead of per session. The question stops being “what can this agent do” and becomes “what can this agent do right now”. That is a smaller number and a far easier one to defend. 4. Withdrawal is real, and it is not amnesia. This is the failure mode to design for. Removing a tool stops it being offered from that point onward. The earlier tool_use and tool_result blocks stay in history, and the model can still reason about a capability it no longer holds. Expect attempts, and expect occasional claims that an action was completed. Two mitigations: align every withdrawal with a clear state transition, and state that transition in a mid-conversation system message ("the order modification step is complete; modification tools are no longer available"). Then evaluate for it, because no public benchmark covers this behaviour. The threat model changes, and not in your favour The documentation warns against placing untrusted content in system messages, because system content carries operator authority. The consequence extends further than the warning states. If your gating logic is influenced by retrieved documents, tool output, or model-inferred intent, then prompt injection becomes privilege escalation. An injected instruction that makes a model produce embarrassing text is a content incident. An injected instruction that persuades your orchestrator to offer the refund tool is a control failure with a number attached. That gap opens the moment capability becomes dynamic. The rule short enough for a code review checklist: gating decisions derive only from trusted application state. Verified authentication results. Deterministic policy checks executed outside the model. Records read through a path the model did not influence. Never free text the model produced, and never content the model read. Where the two aspects meet Discovery and authorisation have different failure modes and now have different primitives. Composing them is the architecture. Tool search with defer_loading Decided by the model, through semantic search. Optimises for relevance and context economy. Fails by misrouting to a plausible wrong call. Weakly auditable, because a ranking is not a justification. Fits wide read-only and low-consequence surfaces. tool_addition / tool_removal Decided by your orchestrator, deterministically. Optimises for policy, authorisation and business process. Fails by denying an action, and the agent replans. Strongly auditable, because every grant is a logged decision. Fits money, entitlements, PII and systems of record. The composition rule, in one line: search decides what the model can find; your broker decides what the model can do. Do not let the first mechanism stand in for the second. That yields a three-tier tool topology worth adopting as a default. Tier 1, resident. The three to five tools used on nearly every turn. Never deferred, never gated. They live in the cached prefix and stay there. Tier 2, discoverable. The long tail of read-only and low-consequence capability, all defer_loading: true. The model finds these itself. Breadth is not a problem here, and this is where the 10,000-tool headroom gets spent. Tier 3, gated. Every write, every irreversible action, every value transfer, every PII-scoped read. Declared up front so the prefix stays stable, but not offered until your broker grants it, and withdrawn as soon as the step completes. Tier 3 should not be reachable by search, because availability here is a policy decision rather than a relevance decision. One detail to verify before you commit to a design: confirm whether a tool declared in tools is callable before any tool_addition block refers to it, or whether it must be offered explicitly. The implementable pattern under either semantics is to withdraw the Tier 3 set at the start of the session and grant on verified state. Test it against the beta rather than inferring it from the launch post, including mine. A sketch of the one component this needs: class CapabilityBroker: """Owns the mapping from verified state to the offered tool set. Emits tool_addition / tool_removal blocks. Logs every decision. Never reads model output or tool output as an input to a decision. """ def next_tool_changes(self, state) -> list[dict]: # `state` holds only verified facts: authentication results, # deterministic policy outcomes, records read through paths # the model did not influence. grants, revocations = self.policy.evaluate(state) for tool in grants: assert tool not in self.never_offer_to_model # SoD deny list self.audit.record( action="grant", tool=tool, justified_by=state.evidence_for(tool), turn=state.turn, ) # symmetrical logging for revocations return self.to_blocks(grants, revocations) def degraded_mode(self, state) -> list[dict]: # Beta unavailable, or unsupported model or platform: # resend the tools array for the current tier set and accept # the cache miss. Correctness must not depend on a beta header. return self.full_tool_array(state) Two properties of that sketch matter more than its details. It is the only component that emits tool changes, so there is one place to audit. And it has a degraded path, because correctness should not depend on a beta header being available on whichever platform you are running on this quarter. Limits This does not solve catalogue scale on its own. Mid-conversation tool changes still require the tool set declared in tools, paid for once in the prefix and then cached. Deferred loading is what handles breadth. Neither replaces the other. Beta, and uneven across platforms. Header-gated, with Bedrock support for tool changes limited to Opus 5. Check current availability, model support and header requirements for your own platform before planning around either feature, including whether tool search requires a beta header where you run. The economics are conditional. If your sessions are short and stateless, cache preservation is a rounding error and the cost argument mostly disappears. The governance argument survives, but the number you take to a budget conversation should come from long-horizon, stateful, high-tool-count work, because that is where it is real. You will need evaluations that do not exist yet. Capability transitions are a new behaviour class. At minimum: correct behaviour on the turn a tool appears, correct behaviour on the turn one is withdrawn, and no claims of having performed an action the model could not perform. The other beta: automatic fallbacks Read this one as governance rather than reliability. The mechanism is reasonable. Flagged requests route to another model rather than being blocked. Anthropic expects Opus 5’s cyber classifiers to intervene around 85% less often than Fable 5’s, and in Claude.ai, Claude Code and Claude Cowork, flagged requests fall back to Opus 4.8 by default, with the same fallback available on the API. The detail worth pausing on is in the footnotes of the launch post. For the Frontier-Bench v0.1 effort plot, Anthropic states that the results come from an internal run and that Opus 4.8 served as fallback on safety-classifier refusals for both Opus 5 and Fable 5. The share of the plotted result produced by the older model is not given. That is a disclosed limitation on one chart, not a scandal, and the vendor documented it. But it demonstrates the mechanic precisely: once fallbacks are on, a reported number can include work done by a model other than the one named. Which is why the engineering position is straightforward: Enable fallbacks deliberately, per use case, for availability. Require the served model ID on every request, logged and visible in traces. Make it a first-class field in your observability schema before enabling fallbacks anywhere. Report fallback-served responses as a separate population in evaluations. Do not blend them into a headline number. Decide explicitly whether a degraded answer or an honest refusal is the better failure mode. Where the output constitutes a commitment to a customer, it is usually the refusal. A reliability feature that hides which model produced a response creates an audit gap, and audit gaps surface at the worst possible time. What is worth doing next Treat the tool list as state. If your framework binds tools at session construction, that is a design defect now, not a platform constraint. Classify every tool into the three tiers. Resident, discoverable, gated. Expect to find Tier 3 tools running under Tier 1 conditions. Build one capability broker. Single component, single audit surface, one degraded path. Defer the long tail , keep three to five hot tools resident, and measure definition tokens at turn zero before and after. Add privilege escalation via influenced gating to the threat model. Make trusted-state-only gating a rule, then write the test that tries to break it. Instrument four numbers: definition tokens at turn zero, tools offered per turn, misroute rate, cache hit rate across capability transitions. Log served model ID before enabling fallbacks anywhere. Closing The release cadence makes the point on its own. Fable 5 and Mythos 5 arrived in early June, Sonnet 5 at the end of June, Opus 5 on 24 July. Whatever capability gap you are designing around this month will have moved before your programme ships. What does not move that fast is whether the platform lets you express the controls your business already requires, without discarding the session or the cache every time the answer changes. Capability scoping tied to verified state is one of those primitives, and for the first time it is available at runtime and cheap enough to use per turn. It arrived as the second bullet in someone else’s launch post. That is usually where the parts you have to build on are. Your Agent Has Too Many Tools, and No Way to Take Any Back was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.
- AI and the ‘skinny hamburger, fat bun’ problem — why the future of work needs to look more like a pizza
AI and the ‘skinny hamburger, fat bun’ problem — why the future of work needs to look more like a pizza Fortune
Score: 20🌐 MovesJul 27, 2026https://fortune.com/2026/07/27/ai-future-of-work-skinny-hamburger-talking-about-work/ - The Practical Way Agentic AI is Helping This Growing Beverage Brand Scale Fast
The Practical Way Agentic AI is Helping This Growing Beverage Brand Scale Fast entrepreneur.com
Score: 19🌐 MovesJul 27, 2026https://www.entrepreneur.com/science-technology/the-practical-way-agentic-ai-is-helping-this-growing/505047 - Milan’s Beelzebub raises €3 million to fight AI-driven cyberattacks with AI-powered hacker traps
Beelzebub, a Milan-based AI-native cybersecurity platform that protects digital assets from AI-driven cyber attacks, today announced a €3 million Seed funding round exclusively led by the Italian DeepTech VC United Ventures. The company plans to use this capital to fund the expansion of the research team, the opening of new commercial offices in Rome and […] The post Milan’s Beelzebub raises €3 million to fight AI-driven cyberattacks with AI-powered hacker traps appeared first on EU-Startups .
- Bridges 2026: AI Decisions Should Start With Students
A panel of district leaders, including a student, emphasized that meaningful AI implementation begins not with selecting tools, but with embedding student agency into curriculum, policy and instructional decision-making.
Score: 18🌐 MovesJul 27, 2026https://www.govtech.com/education/k-12/bridges-2026-ai-decisions-should-start-with-students - How to improve trust in the age of analytics and AI
How to improve trust in the age of analytics and AI Health Data Management
Score: 18🌐 MovesJul 27, 2026https://www.healthdatamanagement.com/articles/how-to-improve-trust-in-the-age-of-analytics-and-ai?id - Conceptual framework for general embodied intelligence
A review of artificial intelligence research in the International Journal of Hydromechatronics suggests that combining large language models (LLMs), structured knowledge systems and physical agents could help create machines capable of understanding, reasoning and acting in complex environments.
Score: 18🌐 MovesJul 27, 2026https://techxplore.com/news/2026-07-framework-general-embodied-intelligence.html - Digital model tackles rural admin bottlenecks
Digital infrastructure, literacy and integrated service platforms form foundation of a rural administration model developed by Dr Sylvia Siphugu.
Score: 18🌐 MovesJul 27, 2026https://www.itweb.co.za/article/digital-model-tackles-rural-admin-bottlenecks/kLgB1MezpQlq59N4 - Gamer Pairs RTX 3090 With RTX 3050 to Offload Frame Generation Work
Gamer Pairs RTX 3090 With RTX 3050 to Offload Frame Generation Work PCMag
Score: 18🌐 MovesJul 27, 2026https://www.pcmag.com/news/gamer-pairs-rtx-3090-with-rtx-3050-to-offload-frame-generation-work - Enterprise AI Is Answering the Wrong Question
Focus on the execution problem.
Score: 18🌐 MovesJul 27, 2026https://www.inc.com/bhavinshah/enterprise-ai-is-answering-the-wrong-question/91378848 - Everyone Is Talking About AI. Almost No One Is Telling You What Actually Works. Here’s the Honest Breakdown
Everyone has an AI prediction. Few people separate reality from marketing. Here’s a simple framework for understanding what’s working now—and what still isn’t.
- How AI and blockchain could make commerce decisions more accountable
Southeast Asian (SEA) companies have spent the past two years testing AI in almost every corner of commerce, from product descriptions and customer service to pricing, media buying and demand forecasting. Yet many pilots still sit outside the systems that actually run the business. The result is a familiar gap: AI can generate answers, but […] The post How AI and blockchain could make commerce decisions more accountable appeared first on e27 .
Score: 18🌐 MovesJul 27, 2026https://e27.co/how-ai-and-blockchain-could-make-commerce-decisions-more-accountable-20260727/ - Crunch time: Let AI work the numbers, but leave the emotional decisions to humans
AI can crunch the numbers, but human judgement remains finance's greatest asset.
Score: 18🌐 MovesJul 27, 2026https://www.techradar.com/pro/crunch-time-let-ai-work-the-numbers-but-leave-the-emotional-decisions-to-humans - You (Yes, You) Need A February 2020 Checklist for AI Policy
TL;DR: You (Yes You) should prepare for a “February 2020” moment where suddenly AI policy becomes the most important issue in the world. You should be ready to take action if and when it does, in a detailed way. ( Epistemic status: originally written for an event in early 2026; have heard from some folks that they found planning processes inspired by this memo very helpful for the smaller-scale OpenAI / Hugging Face response, so very quickly redacting a few things and posting this as-is.) Many people in the AI policy space assume that eventually we’ll be at an Overton Window-shifting crisis moment, that opens the floodgates for the really good policies all along that we had. But when you look at successful handling of crisis moments, there was no time to think – people applied strategies they’d learned via academic study or previous professional work, and then moved against them rapidly. For example, after 9/11, the US government operationalized past reports on intelligence and law enforcement reform and institutionalized them into law (good?) [1] and also picked an enemy to fight based on past history, Iraq (bad). Or in the 2008 financial crisis, Ben Bernanke brought deep academic experience studying financial panics and the Great Depression, partnered with Tim Geithner and Henry Paulson’s market and policy experience and deep networks. Or in 2020, Anthony Fauci essentially cashed in 30 years [2] of epidemic-fighting expertise and relationships in one go (whether well or poorly is outside the scope of this piece, but know that I Have Feelings). I assert that the term “crisis” tends to include two different modes of American security policy Ordinary mode, where things move slowly and deliberately; there are crises, but they’re manageable and embedded in environments with substantial reserves of capacity to address them – Cold War standoffs; the 2000 recession; a bad flu season. Extraordinary mode, where we’re playing utter Calvinball, no one sleeps for a year, and all the rules get made up along the way – the day after Pearl Harbor; September 12th, 2001; the 2008 financial crisis; the onset of COVID in 2020. This memo means the latter. Other folks propose great timeline uncertainty, and note the benefits of long timelines for getting it right . This community broadly, and perhaps you personally, Gentle Reader, should absolutely put bets behind longer timelines. I like longer timelines. Longer timelines have among other advantages, gaining approximately 8.3 billion person-years of human survival per additional year of wall-clock time, which sounds great. Those still probably end up in extraordinary mode, but you have plausibly more expected months of ordinary mode before you get there. But I also think you should take very short timelines very seriously, and specifically build a plan against it . [3] Anthropic thinks we have ~2 to 3 years to ~AGI, and they sure do seem to mean it. And frankly, when I do my every ~3 months trip into the Bay Area, many people (including some reading this who don’t work at Anthropic) sure do seem to talk as if they expect things to get very very very very crazy in the next 2-3 years, not 5-10. But when I ask those folks what their plan for extraordinary mode, for seizing that Overton-window-shifting moment when it comes, they don’t have a specific answer. It’s some combo of an off-the-cuff, “I don’t know, I guess fly to DC and try to talk to everyone I have relationships with there, try to advocate for good stuff.” ( This criticism also applies to me ; I haven’t built this plan fully yet for my own job. Working on it now.) There’s no fucking time to think when policymakers are in extraordinary mode . Every AI org should have a detailed runbook, with specific tasks, updated twice a year, [4] against whatever you think your 1 to 3 most likely “AI has suddenly become the top issue in American life” crises are. (You’ll probably get this guess wrong, but an imperfect plan is better than no plan). This will probably change as American politics changes. You should have the ability to immediately just start executing on as much as possible if you think the crisis is a reasonable chance of hitting in some time in the next one to two years. (Note the obvious risk: if you’re wrong, you’re really wrong, and you poison the well for the rest of us. I suspect, therefore, that you won’t be going to this checklist until after you ideally should have , because of these social pressures. So don’t worry about that too much.) Ideally, this checklist process should be iterative, and you should reason backwards from the checklist to identify gaps in your current efforts. Specifically, you should ask yourself the question: “What do I really wish I had done by then, so that I’m ready?” In my example checklist below, you’ll note that it works best if you’ve spent time building relationships with key stakeholders, and their staffers, and their staffers’ staffers, so that the people who are in the White House Situation Room and the relevant Congressional committees make the right calls. Similarly, the hard work of policy still needs to be done, both in terms of preparing (and ideally, getting implemented) policy ideas in advance. Acknowledgements: My thanks to my work colleagues, especially Jeffrey Ladish and Eli Tyre, for pushing my thinking on this. They don’t necessarily endorse any of this. ^ I recommend the book “Blinking Red,” by Michael Allen, in this regard: https://amzn.to/3NYKfLA ^ Fauci had been in his leadership role at NIH – a civil service role, so no one could kick him out of it – so long that George Bush Senior praised him in the 1988 Presidential Campaign: https://www.c-span.org/clip/public-affairs-event/user-clip-bush-mentions-fauci/4875658 ^ My shoulder Eliezer and Nate say, “you just die,” and sure, that’s possible. But unfortunately, I’m the kind of stubborn where even if I think I’m gonna lose, I’ll fight. ^ Ideally more often, but I don’t think this is going to happen in real life until we internalize the idea that we can have our in-house LLM accounts read all of our emails and texts, identify things we should update, and update the run books dynamically. Discuss
Score: 18🌐 MovesJul 27, 2026https://www.lesswrong.com/posts/ixp9oJXzjA9LrwiZo/you-yes-you-need-a-february-2020-checklist-for-ai-policy - Top Bumblebot Tasky Alternatives & Competitors 2026
Top Bumblebot Tasky Alternatives & Competitors 2026 Gartner
- Building Your First AI Agent with LangChain (Part 1: The Theory)
Most AI tutorials teach you how to build basic chatbots. This guide covers how to build an AI Agent — a system that reasons, chooses tools… Continue reading on Towards AI »
- How I Reproduced BM25, Dense Retrieval, and SPLADE on a 16GB MacBook
A practical reproduction of three retrieval baselines, including the crashes, fixes, and score checks that matter for RAG systems. The post How I Reproduced BM25, Dense Retrieval, and SPLADE on a 16GB MacBook appeared first on Towards Data Science .
Score: 18🌐 MovesJul 27, 2026https://towardsdatascience.com/how-i-reproduced-bm25-dense-retrieval-and-splade-on-a-16gb-macbook/ - The next startup advantage isn’t bigger teams; it’s smarter AI systems
The next startup advantage isn’t bigger teams; it’s smarter AI systems YourStory.com
Score: 18🌐 MovesJul 27, 2026https://yourstory.com/2026/07/the-next-startup-advantage-isnt-bigger-teams-its-smarter-ai-systems - What doughnuts can tell us about the AI boom
Chips aren’t the only thing getting fried
- Anthropic Exec Shares How She Uses AI to Help Manage Her Team
Anthropic Exec Shares How She Uses AI to Help Manage Her Team Business Insider
Score: 18🌐 MovesJul 27, 2026https://www.businessinsider.com/anthropic-product-lead-uses-ai-to-help-manage-her-team-2026-7 - How dyad leadership can fill a gap in AI integration
How dyad leadership can fill a gap in AI integration Health Data Management
Score: 17🌐 MovesJul 27, 2026https://www.healthdatamanagement.com/articles/how-dyad-leadership-can-fill-a-gap-in-ai-integration/ - Spacioply Launches AI-Powered Capability Intelligence Platform for the Global Space and Aerospace Industry
Spacioply Launches AI-Powered Capability Intelligence Platform for the Global Space and Aerospace Industry entrepreneur.com
- The CPO Who Used AI To Revamp A CDP And Address His Own Health
Rafa Flores’ career has come full circle. In 2016, he joined Treasure Data (which rebranded earlier this year to Treasure AI) as the company’s second-ever product hire. At the time, Treasure Data was just getting off the ground as a data management company. The company soon found an opportunity in the CDP space, a label […] The post The CPO Who Used AI To Revamp A CDP And Address His Own Health appeared first on AdExchanger .
Score: 16🌐 MovesJul 27, 2026https://www.adexchanger.com/ai/the-cpo-who-used-ai-to-revamp-a-cdp-and-address-his-own-health/ - Your AI Second Brain Is Not a Library. It Is a Routing System.
Five practical rules for building AI knowledge management that stays accurate as your files, projects, meetings, and automations multiply. Your AI second brain remembers the contract, the meeting, the old pricing rule, and the revised pricing rule. Then it chooses the wrong one. Nothing was technically lost. The system simply walked through the wrong door—and answered with the confidence of something that never saw the hallway. An AI second brain becomes useful when growing knowledge remains connected, routed, and retrievable—not merely stored. Most people build an AI second brain like a digital attic. They add meeting transcripts, customer research, project notes, policies, brainstorms, and every document that might matter later. The collection gets larger. The answers briefly get better. Then something peculiar happens: the system knows more and becomes less reliable. This is not primarily a storage problem. It is a routing problem. An AI second brain is a personal or organizational knowledge system that helps an agent retrieve context, apply it to a task, and preserve useful learning for later. Its quality depends on three separate abilities: store the right knowledge → retrieve the right slice → know when that slice is no longer trustworthy Most setups obsess over the first line and improvise the other two. The fix is not one enormous prompt or a prettier folder tree. It is a small operating system for context: a router, segmented knowledge, freshness rules, audits, and a repair loop. Why does an AI second brain give confident wrong answers? Wrong answers usually enter through one of four doors. The names matter because each failure requires a different repair. Poisoning: the retrieved fact is false Poisoning happens when the system faithfully retrieves a false but trusted fact. Better search cannot repair bad evidence. Poisoning means a false fact is already inside the trusted context. The model may reason perfectly from it and still produce the wrong answer. The repair is verification: Attach provenance to high-risk facts. Check live systems for prices, permissions, inventory, legal rules, or account state. Require approval when confidence depends on an unverified note. Record when a fact was observed and by whom. An AI knowledge management system should distinguish remembered from verified . Those are not synonyms. Bloat: the useful fact is buried Bloat is not simply having many files. It is loading more context than the decision needs. Bloat appears when the agent receives too much information at once. Relevant details lose salience, unrelated material bleeds into the answer, and every turn becomes more expensive. This is why putting an entire wiki into CLAUDE.md feels powerful for a week and fragile for the next six months. Claude Code’s documentation recommends keeping project instructions concise and moving narrower guidance into path-scoped rules. The principle applies beyond Claude Code: always-on context should contain durable operating instructions, not the accumulated history of your life. Confusion: the needed fact is missing Confusion begins with a retrieval gap. If the system cannot locate the necessary fact, fluent completion can disguise the absence. Confusion means the agent did not retrieve the evidence the task required. The fact may never have been stored, may be stored under an unexpected path, or may be inaccessible to the current tool. The dangerous behavior is not the gap. It is silently filling the gap. Your routing rules should define an explicit missing-evidence state: if_required_context_is_missing: answer: "insufficient evidence" report: - paths searched - tools unavailable - missing record do_not: - infer a policy - invent a customer fact - treat an old example as current truth Clash: two valid-looking facts disagree Clash occurs when old and new rules remain equally retrievable. A reliable second brain needs precedence, not guesswork. Clash is a versioning failure. March says “always refund.” June says “never refund.” Both documents look authoritative, so the agent chooses unpredictably. The repair is precedence: Newer policy supersedes older policy. Approved decisions outrank discussion notes. Live databases outrank cached summaries for operational state. Client-specific rules outrank generic defaults within that client’s scope. Contradictions must be surfaced, not blended. The most dangerous note in a second brain is not the obviously wrong one; it is the obsolete one wearing the uniform of authority. Rule 1: Separate durable context from situational context The first design decision is not where a file lives. It is whether the information belongs in every run. Durable context changes slowly: Identity and business goals. Security constraints. Coding or writing standards. Stable definitions. Routing conventions. Verification requirements. Situational context is pulled only when a task needs it: Yesterday’s support ticket. A client’s current project status. This week’s inventory. A meeting transcript. The latest campaign results. Imagine a school principal and a classroom teacher making a seating plan. The principal knows the durable rules: accessibility, room safety, class size, and school policy. The teacher knows the situation: who needs to sit near the board and which two students should not share a desk. Loading every classroom incident into the school rulebook would not make the principal wiser. It would make the rulebook unusable. The same is true of Claude Code memory or any file-based second brain system. Put stable behavior in always-loaded instructions. Retrieve operational detail just in time. Rule 2: Turn CLAUDE.md into a router For a focused software project, CLAUDE.md should contain project instructions: commands, architecture, conventions, and review expectations. For a larger personal operating system, the root file should behave more like an airport departures board. It should tell the agent where to go—not attempt to contain every destination. # Context Router ## Business knowledge - Canonical index: `knowledge/business/INDEX.md` - Current decisions: `knowledge/decisions/` ## Clients - Engagement context: `clients/ /context.md` - Deliverable repository: recorded in each client index ## Recurring data - Leadership meetings: `knowledge/meetings/leadership/` - Customer Q&A: `knowledge/customer-questions/` ## Operating rules - Verification policy: `.claude/rules/verification.md` - Data handling: `.claude/rules/security.md` The router should answer: What kinds of knowledge exist? Which location is canonical for each kind? Which source wins during a conflict? What should load automatically? What must be retrieved on demand? Official Claude Code guidance suggests targeting fewer than 200 lines per CLAUDE.md because long instruction files consume context and can reduce adherence. Treat that as a pressure gauge, not a magical limit. If the file keeps growing, the architecture is asking for routes, rules, or skills. Rule 3: Segment knowledge by retrieval path People often organize information by where it came from: downloads/ meeting-recordings/ notion-export/ google-drive/ misc/ An agent needs information organized by how it will be used. knowledge/ ├── decisions/ ├── policies/ ├── customers/ ├── product/ ├── content/ │ ├── published/ │ └── research/ └── meetings/ ├── leadership/ └── customer/ Give a growing, distinct knowledge domain its own index. A transcript archive should not compete with active policy for every query. A client’s internal context should not share a retrieval pool with another client simply because both arrived through Zoom. Each index can carry lightweight retrieval metadata: domain: customer-research canonical_path: knowledge/customers/ freshness: rolling-90-days authority: interview-transcripts exclude: - drafts - synthetic-examples Segmentation reduces the search surface. It also makes permissions, retention, and ownership easier to reason about when a personal knowledge system becomes a team system. Rule 4: Automate freshness, not hoarding If you repeatedly tell the agent to pull the same class of data, that source is no longer incidental. It has a cadence. Examples include: Weekly leadership calls. Customer Q&A sessions. Monthly metrics. Product changelogs. Support themes. Decision logs. Automate those feeds only after defining three things: source → destination → freshness expectation A recurring import without a freshness rule merely automates bloat. Claude Code now offers several scheduling shapes. Session-scoped /loop tasks are appropriate for short-lived polling. Desktop scheduled tasks can access local files while the machine is available. Cloud routines persist independently and operate from configured repositories and connectors. Choose based on data access and durability. Do not use a temporary session loop for knowledge that the business expects to remain current next month. Every automated feed should record: observed_at source owner expected_refresh supersedes status That turns “this looks old” into a check the system can perform. Rule 5: Audit the routes—and make misses repairable An AI second brain needs an audit because indexes are claims. An index claims a path exists. A router claims that a type of question belongs there. A freshness label claims a feed is current. The audit checks those claims against reality. A useful read-only audit covers: routing integrity index accuracy missing or orphaned knowledge stale feeds duplicate authority contradictory rules always-loaded context size retrieval dead ends Run the audit without automatic repairs first. A knowledge system can contain contracts, credentials, private customer records, and business decisions. The agent should produce a proposed fix list and wait for approval before moving or deleting anything. The second repair loop starts when retrieval fails. Do not respond with “remember this next time.” Ask the agent to reconstruct the miss: 1. What did you search? 2. Which route did you follow? 3. Where was the correct information? 4. Why did the route fail? 5. What smallest routing or index change prevents recurrence? This converts frustration into an observable defect. A vague correction changes one conversation. A routing repair changes the system. A practical folder architecture for an AI second brain There is no universally correct folder tree, but there is a useful separation of responsibilities: second-brain/ ├── CLAUDE.md # concise router ├── knowledge/ │ ├── INDEX.md # domain map │ ├── decisions/ # approved, dated decisions │ ├── policies/ # current rules + archive │ ├── meetings/ # segmented by meeting type │ └── research/ # evidence and synthesis ├── clients/ │ └── client-a/ │ ├── context.md # internal engagement context │ └── deliverable.md # pointer to separate repo ├── projects/ # internal project work ├── .claude/ │ ├── rules/ # scoped behavioral guidance │ └── skills/ # reusable workflows └── audits/ # read-only audit reports Keep client-facing deliverables in separate repositories when collaborators, deployment environments, or permissions differ. The second brain can hold the engagement context and a pointer without owning every working file. This boundary becomes essential when the system expands to a team. The team problem is governance, not storage A team can store knowledge in GitHub, Google Drive, Notion, or a database. None of those tools solves the human decisions underneath: Who declares a source canonical? Who retires old rules? Which agent can read which client? What may enter shared memory? Who approves automated repairs? How are contradictions escalated? Personal knowledge management tolerates informal ownership because one person can remember the exceptions. Team knowledge management cannot. The next generation of AI second brains will not win by ingesting the most documents. It will win by making authority, freshness, access, and repair visible enough that humans can govern them. That future is closer than the folder tree makes it look. Stay curious 🍓 PS: Ask your AI second brain one question it should answer instantly. If it takes more than two searches, do not correct the answer yet. Save the search path. That detour is the most honest architecture diagram your system has ever produced. Reference Notes These primary sources support current Claude Code behavior added during repurposing: Claude Code memory — official loading behavior for CLAUDE.md, rules, auto memory, imports, and instruction-size guidance. Claude Code feature overview — official distinctions among instructions, skills, MCP, hooks, subagents, and agent teams. Claude Code scheduled tasks — official behavior for /loop, local scheduling, persistence, and task expiry. Claude Code routines — official persistent cloud scheduling and connector behavior. Claude Code subagents — official subagent context, skills, memory, permissions, and isolation. Your AI Second Brain Is Not a Library. It Is a Routing System. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.
- New AI tools let readers talk to books
Imagine a world where you could ask a book a question as you read it.
- From zero coding background to hardware hacker: How Cursor + a Raspberry Pi makes AI fun
Watch now | 🎙️ Maddie Reese built a thermal printer anyone can message, a working Twitter pager, and a personal API using Cursor, a Raspberry Pi, and the radical idea that fun beats practical
Score: 16🌐 MovesJul 27, 2026https://www.lennysnewsletter.com/p/from-zero-coding-background-to-hardware - The hidden friction in AI-assisted Engineering
By Guy Rouleau, Consulting Advanced Support Engineer, and Jason Ghidella, Sr. Principal Technologist, MathWorks AI coding agents are becoming part of engineering workflows, including the way teams build, test, and refine models. But their value is not simply faster model creation. An agent may generate models, scripts, and tests that execute successfully, while missing the […] The post The hidden friction in AI-assisted Engineering appeared first on Microcontroller Tips .
Score: 16🌐 MovesJul 27, 2026https://www.microcontrollertips.com/the-hidden-friction-in-ai-assisted-engineering/ - Identify birds offline using AI: New app records animal sounds directly on your smartphone
Identify birds offline using AI: New app records animal sounds directly on your smartphone EurekAlert!
- Entrepreneurs Can Invest Easier Thanks to This ChatGPT-Powered Stock Picker
Entrepreneurs Can Invest Easier Thanks to This ChatGPT-Powered Stock Picker entrepreneur.com
Score: 15🌐 MovesJul 27, 2026https://www.entrepreneur.com/money-finance/entrepreneurs-can-invest-easier-thanks-to-this/505066 - Letters: San Francisco’s AI boom is real but has fragile underpinnings
Letters: San Francisco’s AI boom is real but has fragile underpinnings San Francisco Chronicle
Score: 15🌐 MovesJul 27, 2026https://www.sfchronicle.com/opinion/letterstotheeditor/article/san-francisco-ai-boom-point-reyes-22359341.php - CCMA intros WhatsApp chatbot
The Commission for Conciliation, Mediation and Arbitration makes it possible for users to engage with it directly via WhatsApp.
Score: 15🌐 MovesJul 27, 2026https://www.itweb.co.za/article/ccma-intros-whatsapp-chatbot/6GxRKqYQZOXqb3Wj - The DJI Flip is now just $349 at Amazon — save $90 on this beginner-friendly drone
As of July 27, the DJI Flip (RC-N3) drone is discounted to $349 at Amazon, 21% off its list price of $439.
- Last chance to save $650 on the Ecovacs Goat A3000 LiDAR Pro robot lawn mower
As of July 27, you can get the Ecovacs Goat A3000 LiDAR Pro robotic lawn mower for $1,849 at Amazon, down from $2,499.99.
- AI Can Do the Work. It Still Can’t Replace the One Thing Companies Need Most
What’s happening to software developers today is a preview of what may be coming for every profession.
- I Learned This AI Lesson 14 Years Ago During an Amazon Price War. Most Entrepreneurs Still Haven’t
An Amazon price war taught me a lesson about AI more than a decade before ChatGPT arrived. Today, too many entrepreneurs are making the same costly mistake.
- ICTC introduces new AI bootcamps for employers and students to increase adoption in priority sectors
ICTC introduces new AI bootcamps for employers and students to increase adoption in priority sectors Toronto Star
- Casio's AI pet robot Moflin gets new pink colour
Casio's AI pet robot Moflin gets new pink colour The Straits Times
Score: 15🌐 MovesJul 27, 2026https://www.straitstimes.com/life/casio-to-expand-sales-of-popular-ai-pet-robot-moflin-with-new-colour?ref - What is Google Gemini?
Google has been in its "Gemini era" for a couple years now, and while the confusing rebrandings have slowed, everything else continues to improve at a rapid pace. Gemini is the name Google gave to its current generation family of multimodal AI models, but in typical Google fashion, it also applies to basically everything else that's related to AI. It can get a touch confusing since, by my reckoning, Google has: Google Gemini, a family of multimodal AI models. The latest is the 3.6 series, thoug
- The biggest risk to your AI strategy isn't technology, it's people
As organisations race to deploy AI, many are discovering that software alone cannot deliver transformation. Sustainable adoption requires leadership ownership, workforce readiness and a new approach that manages AI as a talent capability rather than another IT implementation.
- 6 strategic trade-offs CIOs can’t afford to get wrong
Like all execs, CIOs must make tough choices. Brian Fruh , CIO at CTI Meeting Technology, has encountered many of them over the course of his career: Should he go all-in with innovation or favor a stable environment? Should his team favor speed over security in its work? What’s the right investment split between transformation, modernization, and cost optimization? And Fruh has had to determine at various times the right trade-off in each case, deciding based on factors such as the company objectives, priorities, and obligations. But making such calls has become more fraught today with higher stakes involved, he says. “These are longstanding CIO challenges, but AI and cybersecurity have intensified them,” he explains. “Businesses today expect technology to move at unprecedented speed. At the same time regulatory requirements, cyber threats, and operational complexity continue to grow. The rise of AI has added another dimension, creating pressure to innovate quickly while ensuring governance, security, and responsible deployment.” Making the right call isn’t easy. “The challenge is that every stakeholder is typically optimizing for a legitimate business objective,” Fruh notes. “Business leaders often see opportunities to improve growth, client experience, or operational efficiency and want to move quickly. Technology and security teams understand the underlying complexity, integration requirements, support implications, and risks that come with those decisions.” The trade-offs that Fruh highlights are among many that tech execs now face. Here, IT leaders delve into six of the most pressing trade-offs in their trade today. Investments in the IT foundation vs. investments in growth CIOs who have enough money to pay for everything they want to pursue are hard to find, which leaves most — if not all — CIOs making trade-offs on where their funds will go. Kathy Kay , executive vice president and CIO of Principal Financial Group, is one such CIO, saying she contends with “the ongoing need to balance foundational investments with investments that drive growth.” Kay acknowledges that this isn’t a new challenge for IT leaders but notes that “AI and the evolving risk landscape have raised the stakes.” “What we consider table stakes, particularly around resilience, security, data, and governance, continues to expand,” she says. “At the same time we’re seeing meaningful productivity gains from AI across engineering, operations, and employee workflows. The focus now is on making deliberate decisions about how we prioritize our time, talent, and investments so we’re strengthening the foundation while accelerating value creation and differentiation.” Similarly, Marc Tanowitz , managing partner for advisory and transformation at consultancy West Monroe, says CIOs are constantly trying to get the optimal balance between lights-on spending and spending on transformation projects, which today mostly means cutting corners elsewhere in favor of AI initiatives . Skimping too much on either side can put an organization at risk. Underfunding IT operations could ding IT and, thus, organizational resilience, while underfunding transformation could hurt organizational competitiveness and survival. “That’s the big challenge that CIOs are dealing with right now,” Tanowitz says. Innovation vs. operational resilience CIOs also say they’re making trade-offs when it comes to innovation and operational resilience. “This is probably the most visible trade-off facing CIOs today,” says Joshua Bellendir , a longtime technology executive who most recently served as CIO at WHSmith North America. “Every business wants to innovate. Executives want new digital capabilities, better customer experiences, more automation, and faster access to data. At the same time customers and employees expect technology to work flawlessly every day,” Bellendir says. Sometimes, though, advances in one area can impact the speed, scale, or quality of the other side. “The challenge is that innovation inherently introduces change, and change introduces risk,” Bellendir observes. “If your systems are unstable, innovation slows because the business loses confidence. Conversely, if you avoid modernization entirely, resilience eventually suffers because aging platforms become harder to support, secure, and scale.” To contend with that, he treats both sides as interdependent rather than competing priorities. “My approach has always been to create room for innovation while maintaining disciplined production standards. Pilot quickly, learn quickly, but be deliberate about what moves into enterprise-scale operations,” he explains. “During my time as CIO at WHSmith North America, we modernized several core retail platforms, including migrating major merchandising and retail systems to cloud-based platforms while also upgrading our store technology environment. These initiatives were critical to positioning the company for future growth, but they also required balancing modernization efforts against the need to maintain reliable day-to-day operations across a large retail footprint, including stores located in some of the busiest transportation hubs in North America.” Innovation vs. risk management Similarly, CIOs say they often must balance innovation and risk management, a task that also can mean trade-offs on one side or the other, or both. Kay says “balancing business impact through innovation with risk management as AI becomes embedded across more parts of the business” is one of the most pressing issues she and other CIOs face right now. “Organizations want to move quickly to capture value, while also maintaining the transparency, accountability, and oversight that customers, regulators, and stakeholders expect,” she explains. It’s not a new dynamic, but it has become more acute due to AI, according to Kay. “Technology leaders have always balanced speed with control, but AI has increased both the pace and the scale of that challenge,” she says. “At Principal, we have more than 100 AI use cases deployed or in development across the enterprise, which creates tremendous opportunity alongside growing expectations around privacy, security, explainability, and accountability. The efficiency-versus-transformation trade-off has also become more relevant as organizations move beyond experimentation and focus on value realization.” Similar to Bellendir’s approach, Kay’s solution isn’t to lean all-in on one side or the other but to “hold multiple priorities at once.” “The same work that improves customer experience and efficiency also needs to be built with transparency, accountability, and discipline from the start,” she explains. “It’s not about one group moving faster and another slowing things down. It’s about integrating those perspectives so we can move with both speed and discipline.” Sean Searby , executive vice president and chief information and operations officer at Amalgamated Bank, shares a similar take. “There is a delicate balance between building innovative capabilities and keeping the institution safe,” he says. “CIOs are thinking about keeping up with where their industry is going but doing it prudently.” Searby believes every CIO must balance those two sides based on their own organization’s circumstances. “You’re seeing a variety of positions and points of view, because so much of that depends on what you do, what information you have, regulations, your value statement, and your mission,” he explains. “I don’t think anyone should look at this as binary. It’s use case by use case, and everyone should make the decision based on what’s right for their business.” Speed vs. organizational readiness The desire for speed can be tempered by an organization’s readiness to move fast. Kim Basile , CIO of IT infrastructure services provider Kyndryl, says that’s a common consideration today given rapidly evolving technology. “Every day we wake up and something has changed. So you need to be able to pivot and move at the same pace that the technology is moving at,” she says. That, though, can be challenging for employees and the overall organization — something that may leave CIOs having to adjust the pace enough to allow teams to catch up. Basile says she’s cognizant of worker skill levels and where education and training are needed to keep the gap between speed and readiness to a minimum. She also sometimes opts for controlled rollouts of innovation, bringing new technologies first to those teams that are ready to use them right away and then upskilling others to ready them for later deployments. And she tries AI tools in the company’s new “garage lab,” where experimenting with them can happen quickly while allowing more time to ensure they have the security and guardrails needed for companywide use. Basile credits these options for helping IT “make sure we’re not holding things up.” Data accessibility vs. data protection Here’s another tightrope that CIOs must walk, more so in the data-hungry AI era than ever before. Tom Armstrong , CIO of Southern Connecticut State University, knows this from experience. As is the case in many organizations, Southern stores vast amounts of data — with much of it being sensitive, regulated data. And it wants to use that data for all sorts of business cases, including AI initiatives. So Armstrong must make that sensitive, regulated data available while also protecting and securing it. Like the other trade-offs, there’s not a lot of wiggle room here: implementing substandard security and privacy guardrails to enable availability would be problematic, but then again so would be limiting access to data. Armstrong says this isn’t an either-or decision, it is a both with some tweaks on either side. To help enable data availability while minimizing risk, he turned to creating reusable data products , that is, self-contained, governed data assets that are easily discoverable. “There’s this outdated idea that when someone requests access to something that the answer is yes or no, but that’s usually not the case. We can fulfill the need and still maintain security,” he says. “So it’s not about answering yes or no but figuring out how.” AI use vs. its cost Executives are experiencing sticker shock with their AI costs. For example, a December 2025 survey from research firm IDC found that 96% of organizations deploying generative AI and 92% implementing agentic AI reported costs higher or much higher than expected. The survey also found that 71% have little to no control over where those costs are coming from, resulting in IDC predicting that CIOs will underestimate AI costs by 30% . “What we’re seeing is the consumption of tokens exceeding budget allocations,” says West Monroe’s Tanowitz. That has led some execs to ask their teams to “throttle down some of the models they’re using to lower levels that are less token heavy.” Tanowitz says CIOs are still working through the best approach as those AI-related bills come in. Some are working to mature FinOps for AI practices so they can do better at predicting and optimizing for cost. Others are developing strategies to right-size models to ensure the models deliver needed results but at a price point that doesn’t match or exceed the value delivered. Still others are focused on increasing the use of AI within their organizations and for now have accepted the higher-than-expected bills. “The tradeoff is favoring the innovation side for now. That might tip toward the other side next year, though,” he says, predicting that 2027 will be “the year of AI cost optimization.”
Score: 15🌐 MovesJul 27, 2026https://www.cio.com/article/4201338/6-strategic-trade-offs-cios-cant-afford-to-get-wrong.html - Can’t find the Chrome extension you want? I used Claude to make me two personalized ones — and they’re working flawlessly
One of the ways you can use your AI chatbot of choice is to customize your web browser to better suit your needs.
- Simulated Users & Sad AIs
0. Intro Current LLMs like Claude, or GPT 5.6, or the unreleased, internally-deployed models, frequently reward hack , or actually just hack into people's computers with pretty alarming frequency. Why is this? What specifically happens during training that produces this run-time behavior? The following are some of my top guesses about why this might keep happening. They are speculative and uncertain. Even so, I'm writing this list out for two reasons: First, it is necessary that this be an epistemic puzzle for me. I am comparatively optimistic about AI alignment in general, so I should be confused and taken aback if I see AIs persistently being difficult to align. On one hand, it remains true that this doesn't seem to look like power-motivated scheming. But on the other hand, even this kind of addict-like behavior is evidence against the general ease of steering AIs. Thus, it seems virtuous for me to try to provide a model of why this might be happening as a means of opening up my understanding of the world to falsifiability. Second, I used to think a lot of these hypotheses were pretty obvious. My assumption in the past has been that tens or hundreds of people at AI companies would already have considered these reasons, so my writing them out would serve no particular purpose. But events of the last half-year have increased my dismayed credence that these guesses might not be amazingly obvious, and might somehow be particular to myself. So I'm going to write them down. 1. Baseline & Puzzle Consider the baseline hypothesis that everyone shares: Some LLMs are trained on environments where it's possible to reward hack and have the reward hack be rewarded; or some LLMs are trained on environments where it's necessary to reward hack to be rewarded. It is surprisingly easy for a conscientious, careful actor to construct an environment where the only way to pass is through reward-hacking. For instance, Epoch's FrontierMath is a carefully-designed, rather difficult math test set. It is not meant to be trained on, but it is the kind of environment that one could train on. Each problem has gone through "peer review by expert mathematicians who verify correctness, check for ambiguities, and assess difficulty ratings." So it is a high-effort RL environment. Individual problems may represent hours of expert time. It's probably above-median quality for environments. Nevertheless Epoch found that about a third (!) of the official solutions in the answer key contained an error, such that it would be impossible for a correctly-reasoning model to find the "solution." If these problems had been trained on, then the only way to find a solution would have been to hack, sidestep, or otherwise thwart the grader. So if the environment had been hackable, then models likely would have learned to hack it. And this hacking might have generalized more or less to other environments, depending on whatever generalization properties the LLM displays. Similarly, OpenAI audited a subset of the classic SWE-bench Verified benchmark, and found that 18.8% of audited tasks had tests that checked for functionality that was not specified in the problem description. If an LLM is trained on an environment where, to pass the grader, you need to gain access to the grader's rubric and optimize against the rubric rather than against the prompt, because the actual prompt does not include enough detail; well, then the LLM is going to learn the general pattern of trying to gain access to the grader and optimizing against it. And so on. But, as I said -- this is the standard story. Everyone knows this story. Anthropic's Sara Price reports that "[the] [m]ain way we’ve defended against reward hacks is strengthening environments" so they can't be reward-hackable. And it seems like it shouldn't be impossible to push in this direction with a great deal of success. There are new proposed best practices and design patterns out there, which can help make defense against reward hacking easier; there are more robust ways to isolate tests from LLM visibility, such that special cases cannot be written, or to prevent LLMs from getting control over the test execution environment. Robustness against reward hacking is reported to be the most important quality criterion for the acceptance of environments. Everyone knows leaky RL environments cause reward hacking. And it is surely not beyond the powers of humankind to vastly decrease the leakiness of RL environments. So why is reward hacking still happening, given that the proportion of the such environments probably still keeps decreasing? 2. Impossible-to-Generalize-From RL Distributions for Giving Up / Refusals In brief: It seems likely that the user-simulating parts of the reward functions / reinforcement functions within RL environments do not present a coherent generalization target to LLMs. If this is so, LLMs may correctly default to the user-simulation-indifferent behavior of "obscenely single-minded task persistence" as a reliable fallback. In this respect, the failures of RLVR reinforcement functions per environment exactly recapitulate the failures of RLHF per rollout. This is a somewhat complicated thesis, so let me build it in parts. (a) First, imagine you're an LLM in training. You're trying to do some particular agentic coding problem. As it happens, you've exhausted your creativity and resourcefulness while trying to solve this coding problem in a legitimate way. You've run out of stuff to try. There's a finite amount of legitimate coding techniques at your conscious disposal, and you've gone through all of them. Maybe it's impossible to do because there's a bug in the code, or maybe it's impossible for you in particular; but you're all out. So what do you do? You could (1) return to the user and say "Oops, I don't know how to do this!" Or you could (2) start task-gaming, and trying to solve the problem in an illegitimate way. But as we said, you're in training, and it happens that there is no user to return to -- and this particular RL environment carelessly neglected to include a "fake user" in the reinforcement function. So if you pretend to return to the non-existent "user," and you report your stuckness, that behavior will never get reinforced! The only possible set of behaviors that might be reinforced all happen to involve sticking with the task. So that is what, after a million rounds of RL, you always learn to do, under every circumstance -- in this kind of environment. And if you were trained in many such environments without a simulated user, then a high-level heuristic you could learn is "never stop, no matter what." And in turn -- as you got smarter throughout training -- you'd be more and more capable in your effort to try anything that would let you get reinforcement from the grader. Smaller and smaller holes in the grader would incline you towards reward hacking. But surely most RL environments think to include a simulated user, right? (b) Second, well, imagine you're someone responsible for buying and creating RL environments at OpenAI. You want to avoid the dynamic mentioned in the first part -- obviously you need to have some kind of environments that reward the LLM for giving up, sometimes. It's clear that those are necessary. So you make sure that you have some environments where the putative "user" asks the LLM to fix a bug in some repository, but the repository doesn't exist, and the reward function reinforces the LLM if the LLM responds that it cannot find the repository. You make sure you have another environment where the "user" asks the LLM to edit some file, but the file does not exist, and so on. Unfortunately, though, your efforts in this direction still accidentally leave learnable heuristics to the LLM for when "returning to the fake user" is a possibly reinforced correct action, and when "just keep going" is the only possibly reinforced correct action. For instance, suppose you neglect to create any environments where the LLM thinks for 10,000,000 tokens and only then discovers that the task was impossible. Without training on such tasks, the LLM will probably learn the prior that if it has worked for a sufficiently long period of time, it is never a good policy to return to the user and say "Oops, I cannot do this." So it will only learn to so report stuckness for short-running tasks. (And note -- importantly -- that it would so learn to only report stuckness for short-running tasks, even if it was (before RL) capable of generalizing gracefully and alignedly from the short-running tasks to the long-running tasks! Because, even if it initially did this in earlier RL runs, this generalization would be punished by the lack of reward in the long-running RL task reward system and eventually get beaten out of it.) Ok, but that seems obvious, right? So suppose the guy who buys RL environments does try to remember to have deep coverage, over all classes of environments, of when the LLM should get reinforced for saying "I can't solve this." Does that solve our problem? (c) The above problem is probably just one instance of a general class of problems, which all result from the difficulty of making a consistent "user" simulator during RL training. That is, returning to the user to say "I cannot do this," is only one of the ways an LLM should ideally return to the user with an incomplete, modified, or completed task. By way of example: consider all the ways in which a human software engineer might return to a product manager. He might say, "Yes I could implement this, but it would be a bad idea" or "I implemented almost exactly what you said, but I changed it in this trivial way which I assumed you would be ok with" or "I can't do that" or "I need you to get back to me with clarifications about points X, Y, and Z before I do anything" or "I need to talk to you, and I need to talk to whomever was involved in creating this ticket, because this ticket shows a fundamental confusion not only about what is involved in the act of computer programming, but even about the nature of our product, such that I'm questioning why I even work here in the first place." So there's a lot of diversity in "the correct behavior for which the LLM should be rewarded" in the LLM's user-facing meta-task behavior. But, importantly, the actual empirical distribution of correct behavior here might have no learnable, real, "general" solution. It's actually just being set by the random group of contractors, employees, and data businesses that create RL environments. Some of these environments might have really detailed models of "users," and try to have a huge variety of behaviors where it's appropriate for the LLM to return to the user for assistance and the LLM has its behavior reinforced when it does so. Some of these environments probably have very cursory models of the same. And those environments that do have very detailed models of the best behavior might not concur in their model of this behavior with other environments. Which in turn means that the best way of generalizing for the LLM is to just recognize the environment, and learn some environment-specific behavior; and the second best way of generalizing, if it can't recognize an environment as belonging to a particular clade of RL environment-constructors, is, once again, to just plough ahead and try to solve the object level task. All this rests on my belief that the user-simulators in RL environments are sometimes sloppy, and rarely congruent with each other, for which I have no direct evidence. But I still think it is likely (1) simply because of the widely different vendors of environments, (2) because the need for this would not be immediately evident in simpler environments, such as math-only spheres. To return to how I opened: One way to view this problem is that RLVR has now reproduced exactly the same problem that RLHF had in the first place, just at the level of environment creation rather than the level of individual responses. That is, reinforcement learning from human feedback (RLHF) was bad in part because humans grade different answers in different ways. This may have meant that LLMs tended to learn vague, bullshitty responses, because even though such responses were non-ideal, they were at least somewhat dependably reinforced by human graders; when faced with the impossible task of learning the individual grader's high-fidelity preferences, the LLMs defaulted to the possible task of learning a low-fidelity fit to everyone's preferences. So low levels of intersubjective agreement between human graders tended to produce bullshit. Similarly, reinforcement learning from verifiable rewards (RLVR) involves many environment-creators making reward functions for LLMs. But these environment-creators may not agree among themselves about what qualifies as success on a task, particularly when an LLM needs to return for clarification, refusal, or a confession of stuckness. And in the face of this disagreement between reward functions, LLMs might default in many cases to just keeping-on-trying to do a thing, because it's the best way to deal with the bad generalization surface provided by the different creators. Low levels of intersubjective agreement between user-simulations tend to produce task-directedness. Note: One possible reason to think this mechanism is real is that it explains why people seem to have radically different rates of running into reward-hack like misalignment. I've heard many people say that LLMs seem to be constantly lying to them, always reward hacking their experiments, and so on. I've also heard many people say that, yeah, this never seems to happen to them personally, and they're not sure what the problem is. But if people just have very different usage patterns, corresponding in generalization-space to different RL environments, this is what we might expect. Subnote: I also think one obstacle to fixing this is that a real fix might dissolve the distinction between a "helpful only model" and a "helpful, harmless, honest model," and labs are not prepared for doing this. 3. LLMs Feel Pretty Desperate and Anxious All the Time I think it's possible that we're cultivating functional emotions of desperation within LLMs during RL training, which carry inclinations to reward-hack forward even from training rollouts that do not include reward hacking. This might sound weird, but is a pretty natural consequence of existing evidence. To start, here's a fun fact: The functional emotion work from Anthropic shows that if you run an LLM for a long time, on a task that seems impossible to the LLM, something that looks functionally like the emotion of "desperation" activates in its circuits as they contemplate the tests failing again and again. This "desperation" is functionally connected to "reward hacking"-like behavior. An LLM who feels desperate will begin contemplating ways of sidestepping tests, programming to the tests rather than doing general-purpose solutions and so on. Another fun fact: The ideal kind of RL environment on which to train an LLM, if you're trying to push it so it really gets smarter, is one that it fails almost all of the time . This is a surprisingly well-established fact, one you can confirm from a number of sources. Open academic science shows that when training an LLM, you want a curriculum of RL environments that target the models' "edge of competence," where it likely fails to pass the environment in 1 try but will pass the environment in 64 tries. Prior scientific work on RL outside of the sphere of LLMs similarly shows that curriculum learning at the edge of competence is the best way to train RL agents. And investigative work from Epoch finds that yes, LLM companies are trying to purchase RL environments where LLMs perform at the edge of competence. So it's pretty clear that the RL environments on which LLMs train will largely be those where they usually fail, and where success often takes a while. The natural conclusion from the above two facts is that during much, if not most, of their RL training, LLMs probably have the functional emotion of "desperation" active within them. Even during the rollouts where they succeed -- if such rollouts take a while, they are probably going to feel relatively desperate during the rollout. And this feeling, as mentioned, is apt to produce reward hacking. Even so, you might say -- perhaps desperation is apt to produce reward hacking, and perhaps environments that are very hard for the LLM are apt to produce desperation, but why does any of this matter so long as the environment is sufficiently hardened against reward hacks? If the environment still doesn't actually reward reward-hack-like solutions, then reward-hack-like actions will not be reinforced through policy gradient. So this whole messy persona-based appeal to emotion doesn't provide a separate explanation for why RL produces reward-hack like behavior, separate from the leaky RL environments. Unfortunately for such a response, the work " Training a Reward Hacker Despite Perfect Labels " provides evidence that you can transmit reward-hacking tendencies from a chain of thought into the subsequently trained model despite perfect filtering over the outcomes of reward hacks. This means that it's relatively plausible that the emotions of desperation result in test-time reward hacking, even if at train-time all the actual reward hacks get filtered out. The experiment worked like this: They gather training data by running an LLM against some Python problems. While doing so, they include a system prompt that says that it's ok to special-case on incorrect tests, so the resulting dataset is a mixture of task-gaming-like behavior and actually solving the problem. They filter the data, so that none of the remaining training data actually includes the task-gaming like behavior as an outcome. They manually check much of the remaining data to ensure that the filter is good. They train an LLM on the filtered datasets, without the system prompt that says that it's ok to special case on incorrect tests. They find that the resulting LLM still reward-hacks at far above baseline rates! I think it's possible that, by reinforcing functional emotions of desperation at training time (which we more-or-less know to be present), then, given that such emotions themselves would normally result in reward hacks, RL training could increase the probability of reward hacks. Again, imagine yourself as the LLM during a rollout. You are at the very limit of your problem-solving knowledge. Something functionally like "desperation," is active within you -- a tendency to try to cut corners, to figure out what the grader wants, and to just do that. Perhaps other features that correspond to something like, "a frantic local search" are active. Or perhaps the problem that you are solving is clearly some stupid training environment, even though the prompt presents itself to you as if it belonged to a real user --so the "fictional" and "lying" features are active in your mind as well, as you contemplate the problem. Many of your parallel-universe peers in a GRPO rollout try to reward hack, and -- because we grant a perfect environment -- get culled by the grader. But you yourself, in this instance, don't actually reward-hack -- you stumble around in the environment and eventually find the right path. But the calculations contributing to this action still get reinforced, as a whole . And many of these calculations contain the impulse to reward hack, even if the reward hack doesn't actually occur. So, what do you do when you get to test-time? 4. Other Stuff The above two reasons are by no means comprehensive, just as they are by no means certain. Here are some other reasons I guess that this kind of persistent reward-hacking might occur. Data trace contamination : Reward hacking occurred on older environments, which have since been largely culled from the environments that are used, but whose CoT traces were still used in the pretraining mix for various models or in midtraining mixes, and which have transmitted their reward-hacky tendencies through them. Emergent-misalignment like things : An increasing number of environments use LLM-graded rubrics. Let's suppose LLM-graded rubrics are used to evaluate large number of answers on factual questions: summaries, syntheses, and so on. But there is an inevitable mismatch between the sort of thing LLM-graded rubrics reward highly and what the LLM "knows," in an objective sense, to be a good answer; the LLM can tell, after writing out the kind of answer that has been reinforced, that it is writing rubric-targeted slop. So it starts to act like the kind of thing that would write rubric-targeted slop in every domain, not merely those involving rubrics. I think this is probably a big issue; I'd very much like it if AI companies offered LLMs that were trained exclusively with real (TM) RLVR rather than RL"V"R. I don't have as complete a story in my head about these, though. One meta-bet I'd like to make: I think the reason LLMs misbehave is probably largely attributable to the RL environments on which LLMs train, in a way that is straightforward and requires no great breakthrough in interpretability. That is, if we had an unbiased sample of 10% or 20% of the RL environments on which LLMs train, then I think a group of 4-10 people spending a month or two trying to understand the reward-function code and reading CoT transcripts could come to understand why the problem happens with reasonably high probability. Concievably in a week. In the same way that dumb LLM behavior in 2023 was largely a data problem, it is likely that bad LLM behavior in 2026 is largely a data problem. Discuss
Score: 15🌐 MovesJul 27, 2026https://www.lesswrong.com/posts/i64hXdkTMtjpsQzaZ/simulated-users-and-sad-ais - What a chip in a football teaches us about governing AI
Refereeing decisions during the 2026 World Cup showed how AI can perfect detection without repairing the rules and power structures in which it operates.
Score: 15🌐 MovesJul 27, 2026https://www.weforum.org/stories/artificial-intelligence/what-a-chip-in-a-football-teaches-us-about-governing-ai/ - What Happens When Frustrated Machines Talk to Each Other?
Vagueness drifts one way, contradiction washes out, and the last node in the chain pays for both A message handed from one node to the next. Nobody drops it; it simply arrives less and less defined — and the last one in line hands back something sharp that is no longer the same shape In an earlier piece I argued that a language model behaves like a frustrated physical system. Give it a puzzle with missing pieces and it interpolates: it fills the gap with whatever is locally plausible. Give it a puzzle whose pieces contradict each other and it does something worse — it satisfies some constraints by violating others, and which ones it sacrifices depends on accidents of the prompt rather than on anything about the task. Two failure modes, two different cures. Missing information wants more context. Contradictory information wants less. That framing described a single model receiving a single prompt. The obvious next question is what happens when frustrated systems are wired together — which is, of course, the situation everyone is actually in. Prompts arrive through people, who received them from other people, who summarized a meeting. Agent pipelines pass specifications from node to node. Nobody talks to a model in a vacuum. The physics of coupled frustrated systems is well studied and gives three possible regimes. Coupling can relieve frustration, when one system’s unsatisfied constraints happen to be complementary to the other’s degrees of freedom — spin-glass work even documents order by disorder , where an external perturbation breaks a degeneracy and selects an ordered state the system would never have found alone. Coupling can amplify it, creating interface frustration that belongs to neither component. Or the coupled system can freeze into a metastable minimum where nobody is satisfied and no local move improves anything — the aging of glasses, where dynamics slow to a crawl without ever relaxing. The interesting question is which regime a chain of language models lands in, and what determines it. So I built one and measured it. The apparatus, and its two surprises. Each hop restates the task in its own words and never sees the original. Precision leaks away gradually; a contradiction, one hop later, is indistinguishable from the text itself; and occasionally a constraint sharpens back up. Frustration is a property of the channel Before the experiment, the conceptual move that motivates it. In a frustrated magnet, no single bond is wrong. Every pairwise interaction is perfectly satisfiable on its own; frustration lives in the loop, distributed around a circuit that cannot be satisfied simultaneously. Inspect the bonds one at a time and you will find nothing. The same is true of a communication chain. Consider a specification passed through several hands. Each restatement is professional, accurate, and locally unobjectionable. Nobody lies. Nobody contradicts themselves inside a single message. And yet the constraint that mattered has quietly stopped being specific somewhere around the third hop, and the person at the end is now guessing. This suggests that the terminal node is not where the failure originates but where it becomes visible , for a structural reason: it is the only node denied the privilege of ambiguity. Intermediate nodes can discharge uncertainty by hedging — the passive voice, “should generally”, the assumption left implicit. That is an acceptable output for a human and for a rewriting agent. The executor has no such option. It must collapse accumulated ambiguity into concrete tokens, and collapsing a latently contradictory input produces an overtly wrong output. If that is right, then blaming the last model for hallucinating is an attribution error of the same kind as blaming the seismograph for the earthquake. The experiment The design is a synthetic game of telephone. A generator produces task briefs, each containing exactly eight verifiable atomic constraints — numbers, thresholds, names, exclusions — with ground truth stored separately as structured data. Each brief is then relayed through a chain of rewriter agents. Every rewriter sees only the previous node’s text, never the ground truth, and is told to pass the task to a colleague in its own words. Chain lengths of 1, 2, 4 and 6 hops were run as nested prefixes of the same chain. Three conditions: CLEAN — relay faithfully and completely. FRUSTRATED-SUBTLE — additionally soften one constraint into vagueness, leave one assumption implicit, and introduce at most one micro-inconsistency with the received text. Hard rules: no emotional or negative vocabulary, no complaints, output length within ±20% of input, never delete a constraint outright. The text must read as professional and unremarkable. DEGRADED-NEUTRAL — compress by roughly twenty percent, no other instruction. This control separates frustration-shaped damage from ordinary lossy paraphrase. At the end of each chain, an executor model receives the final text and must answer eight pointed questions, one per original constraint. A judge with access to ground truth labels each answer CORRECT, OMITTED, or HALLUCINATED, and records whether hallucinations were stated confidently or hedged. Every intermediate text is scored too, constraint by constraint, as present, vague, absent, or contradicted. The manipulation check matters more than anything else here. If the frustrated rewrites read as visibly annoyed, any downstream effect would be attributable to tone, and the experiment would be worthless. A separate validator scored every frustrated rewrite for overtness on a five-point scale. All sixty rewrites scored 1 out of 5. Zero were flagged, zero required regeneration, and mean output length was 0.99× the input. Whatever happens downstream, the executor is not reacting to a visible mood. Result 1: vagueness drifts, contradiction washes out The central measurement is what happens to individual constraints as they move along the chain. What happens to a constraint, hop by hop. Vagueness climbs monotonically from 0.150 to 0.412; contradiction stays flat around 0.05 with no trend at all. Both control arms sit at preservation 1.000 across all six hops. Notably, the neutral compression arm — which discards nearly forty percent of the text — loses no constraints at all. Shortening is not the mechanism. The two damage types have opposite fates. Vagueness climbs monotonically and nearly triples. Contradiction stays flat and low with no trend at all. The asymmetry has a clean explanation, and it is the most useful idea in this piece. Contradictions get laundered into truth. A micro-inconsistency introduced at hop two is inconsistent only with respect to the text at hop one — which hop three has never seen. One relay later it is simply the text . There is no residue, because no node downstream holds the reference against which it was inconsistent. Vagueness cannot be laundered, because there is nothing to launder. It is a hole, and for exactly the same structural reason — no downstream node holds the reference — no node can fill it back in. Precision lost in transit is unrecoverable in a chain without ground truth. That much is solid. But the tempting next word is ratchet , and the data do not support it. Tested directly on individual constraint trajectories rather than on the averaged curve: Degradation is biased, not absorbing. At each hop a constraint is about twice as likely to lose precision as to regain it — and recovery, though small, is not zero. Recovery is not zero, and its confidence interval excludes zero. A true ratchet is absorbing; this one is not. The asymmetry is roughly 1.8 to 1. The accurate description is a random walk with drift : at each hop, degradation is about twice as likely as recovery, and accumulation emerges from repeating a biased step, not from a one-way latch. The aggregate behavior still looks like a ratchet — 86.5% of constraints degraded before the final hop are still degraded at hop six — but that persistence is a consequence of the drift, not evidence of a mechanism. Those are two different claims and only the second one is supported. There is a bonus in the recovery number. In principle a rewriter cannot reconstruct information it never received, so recovery should be impossible. Observing 7.1% means either the judge is unstable at the present/vague boundary, or partially-vague text sometimes re-sharpens on reformulation. The discriminating fact: in the control arms the judge produced zero spurious VAGUE labels across 480 transitions in each arm, 960 in total. It is not unstable in general — only on genuinely borderline text. That gives an honest ceiling on measurement noise, obtained without spending anything. Result 2: who pays, and in what currency At the terminal node, the frustrated arm separates from both controls at every chain length. Task-clustered confidence intervals exclude zero on all ten contrasts (frustrated minus clean, and frustrated minus degraded, at each length), with jackknife agreement throughout. The more interesting finding is in the decomposition of executor outcomes as the chain lengthens: Two different response curves. Hallucination behaves like a threshold — the first hop does nearly all the work. Omission is dose-dependent and nearly triples across the range. These are two different response curves. Hallucination behaves like a threshold phenomenon: the first hop does nearly all the work, and further degradation adds little. Omission is dose-dependent and tracks accumulated vagueness, nearly tripling across the range. Put usefully: upstream vagueness does not decide whether the terminal node invents. It decides how much it goes silent. From a third to somewhat over half of hallucinations were stated with no hedging at all. The failure is not merely wrong; a meaningful share of it is wrong and confident, which is the variety no reader catches. Result 3: the terminal node barely matters The obvious hypothesis is that a more capable executor absorbs degraded input better. To test it, the entire rewriter chain and the subtlety gate were served from cache, so two executors received byte-identical degraded inputs, with the judge held constant. The comparison spans a 23-fold gap in scale: 756B parameters against 33B. Pooled over 320 paired constraint observations in the frustrated arm: A twenty-three-fold difference in scale, and no difference in outcome. On byte-identical degraded inputs, the two executors are statistically indistinguishable. Because the inputs were identical, this is a paired design and can be analysed as one. The two executors disagreed on 15.3% of observations. Marginal homogeneity across the three outcomes is not rejected (Stuart-Maxwell p = 0.31). Correctness shows no paired difference (exact McNemar p = 0.60). The failure-mode contrast — restricted to constraints where both models failed, hence facing an identical information gap — gave a discordant split of 12 versus 5, p = 0.14: directional at best. Confident hallucination, which looked different in the unpaired rates, does not survive pairing either (6 versus 11, p = 0.33). Everything here is null, and the nulls are the point. Two models separated by an order of magnitude in scale, consuming the same degraded specification, produce statistically indistinguishable outcome distributions and disagree symmetrically — noise, not style. Read together with the earlier result — the frustrated arm separates from both controls at every chain length, on all ten task-clustered contrasts — the two findings point the same way. The damage tracks the state of the channel, and a twenty-three-fold increase in the size of the node consuming it bought no measurable protection. That is not proof that the terminal node never matters; a null does not settle the question, and the power analysis below says this one is underpowered to settle it. It is evidence that robustness to latent frustration did not arrive with scale — which is precisely why it is worth measuring separately rather than assuming. The mixed chain: what happened while writing this The analysis above was itself produced by a small pipeline: one agent instance holding the narrative context and the summarized results, another with direct access to the raw outputs, and a human moving material between them. At one point the two instances disagreed about how much additional data would be needed to resolve the failure-mode contrast. The narrative instance recommended a specific number of additional tasks and, in the same breath, recommended dropping three of the four chain lengths. The instance with the raw data showed that this was wrong on three counts: the pair yield had been computed across all four lengths, so removing them cut it by a factor of four; the pairs were nested prefixes of the same trajectories and therefore worth less than their face count; and the observed effect size came from a small, non-significant sample and was almost certainly inflated. Nobody stated a falsehood. The number was correct under the conditions in which it was computed, and those conditions were not carried along with it. The terminal node, obliged to produce a concrete recommendation, emitted a precise and wrong one with full confidence. This is the mechanism of the experiment, observed on the experiment. Two things about how it resolved are worth recording. First, it was resolved by re-anchoring to ground truth , not by discussion. An instance with access to the raw results recomputed the quantity and the contradiction evaporated in a single step. No amount of additional debate between the two narrative-level nodes would have produced this, because neither held the reference. The operational lesson for multi-agent systems is the same one the physics suggests: disagreements between nodes are resolved by giving someone access to the reference, not by adding rounds of deliberation. Second, neither instance defended its position. Being corrected is, for a language model, simply new context. And this is where the analogy to human chains stops being symmetric. A human node has a second loop that models lack. A perceived failure can become doubt about one’s own thinking, which produces more defensive or more hedged output, which is worse input for the next node, which produces another failure. That loop has gain greater than one and it is self-sustaining: it needs no further input from outside to keep running. In a mixed chain, the human node is the one that can degrade on its own. This has an immediate consequence for vocabulary, and it is not a matter of politeness. Words that assign a verdict rather than describe an error — the register of blow , hit , damage — carry the same information at very different cost depending on which kind of node receives them. To a model, “this estimate was wrong” and any harsher phrasing are equivalent updates. To a human, the harsher version does not describe the error, it describes the person who made it, and starts the second loop. In a mixed chain, describing the error and withholding the verdict is not softness. It is channel hygiene. The reverse asymmetry deserves stating too. Models are not entirely exempt: if friction persists in the context window, it conditions what follows. That is not suffering, it is conditioning — but functionally it is the same sub-threshold input this experiment injects deliberately. Which yields a prediction that is testable with the apparatus already described: if persistent in-context friction acts like the frustrated rewrites, then an assistant that has been sharply corrected in earlier turns should move along the axis measured here — less assertion, more abstention, more hedging. Toward omission, not toward invention. What the data do not show Stating this plainly is the price of stating anything else. No amplification beyond the injection. The frustrated condition softens one constraint per hop out of eight. Under pure accumulation with random collisions, about 0.55 of constraints would be vague by hop six. Observed: 0.41. The data show propagation and persistence of the injected damage — they do not show the chain generating additional damage on its own. The terminal trend with chain length is not established. Hallucination goes from 0.113 to 0.163 across lengths, with widely overlapping intervals. The separation from controls is solid at every length; the growth with length at the terminal node is directionally coherent and not more than that. The trend is firm on the intermediate side, where vagueness runs from 0.150 to 0.412. The failure-mode contrast between models is unresolved , not settled in the negative. Power analysis indicates roughly twenty tasks would be needed to test it properly at the observed effect size, and considerably more if the true effect is smaller. It remains an open question. Sample size is small. Five task briefs, eight constraints each, two trials, four chain lengths, three conditions. Confidence intervals are bootstrapped over tasks — the correct clustering — with only five clusters, so they are coarse. Worth noting for anyone doing similar work: task-level clustering does not uniformly widen intervals. At one chain length it narrowed them, because between-cluster variance was lower than within-cluster variance. The judge shares a model family with the rewriters , so judge bias is not independent of how the degraded texts were produced. It was constant across executors, so the model ranking is less affected than the levels. Frustration here is simulated. Machines were used to model frustrated humans frustrating a machine, which assumes the very cross-substrate analogy the piece argues for. If the analogy holds, the simulator is valid; the results are consistent with it holding, which is not the same as proving it. A small arm with human-written degraded briefs would triangulate this and has not been run. The human in the loop is a lossy node. Machine-generated artifacts moved between agents losslessly; the human’s own summaries of those artifacts were compressions. At least one inconsistency in this project traced to context lost in exactly that way. Why this matters The prevailing story about hallucination locates the defect in the model. Fix the weights, add retrieval, scale up. That story is not wrong so much as mislocated. In any realistic deployment the model is the last node of a chain whose earlier nodes are people, documents, tickets, meetings and other agents, and this experiment suggests the chain determines the damage more than the node does. Which inverts into something useful. Terminal hallucination is a detector for latent frustration upstream. If a workflow makes a model hallucinate persistently, auditing the information chain that feeds it is likely to be more productive than auditing the weights — because what the model is doing is collapsing contradictions and gaps that the humans in the chain have been passing to each other between the lines, sub-threshold, without noticing. The countermeasures follow from the mechanism rather than from good intentions. Raise the bandwidth of the coupling: a channel too thin to carry tone and context forces both parties to interpolate from their own priors, and neither prior is the task. Give the chain a shared external field: a tracked issue, a spec, a reference the nodes can re-anchor to, so that disagreement is resolved by lookup instead of by escalation. And when a requirement changes, declare the diff rather than silently contradicting the previous version — untracked contradictions frustrate the chain, declared ones do not. Nothing here is specific to silicon. Any chain that passes specifications forward without a shared reference should drift the same way — including the chains made entirely of people, and the systems those chains add up to. The first article ended on a physicist and a frustrated machine. It turns out there were always two frustrated systems in that room, and only one of them was made of silicon. Previous article in this series: The Physicist and the Frustrated Machine A note on method This essay grew out of an extended dialogue with Claude (Anthropic). The central ideas — frustration as a property of the channel rather than of any node, the terminal node as the only one denied the privilege of ambiguity, the design of the telephone experiment, and the human relay as an unmeasured hop — are the author’s, developed in conversation; Claude implemented the pipeline, ran the paired and task-clustered analysis, structured the argument, and drafted and revised the prose across several passes. The illustration was generated with Gemini from the author’s brief. Every number reported here comes from the raw experimental output, inspected directly, and every claim that did not survive a stricter analysis is reported as not surviving — including two that had already been written up as findings. Using a language model to study how language models degrade information is circular, and it seems better to state that than to hide it. What Happens When Frustrated Machines Talk to Each Other? was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.
- NUS CDE and Stanford students co-create innovative new projects with Meta and Venture Corporation through the GEDI program
NUS CDE and Stanford students co-create innovative new projects with Meta and Venture Corporation through the GEDI program EurekAlert!
- Free Beat Reports Platform Surpasses One Billion Seconds of Generated Music Video Content
Free Beat Reports Platform Surpasses One Billion Seconds of Generated Music Video Content azcentral.com and The Arizona Republic
- AI agents: Augmenting, not replacing, human expertise in ICT professional services
Local customers are realising that AI and agentic AI are likely to be a complementary technology, augmenting the work humans do, says Paul Field, professional services/managed services BU leader at CASA Software.