The Components of Agent Memory: Notes, Dreaming, and a Small Top Layer

On November 6, Anthropic's engineering team published a breakdown of agent memory. It defines memory as notes an agent writes and keeps across sessions, separate from weight updates, in-context learning or context compaction. The central idea is "dreaming": an offline pass that replays past transcripts to correct wrong notes, build wiki-style knowledge bases, and decide which material gets promoted into the context injected at the start of a session.

The post includes concrete results. On a CL-Bench database task, adding memory improved several models enough that Opus 5.5 and Sonnet 5.5 with memory scored about the same as Opus 5. In a Pokémon Red run, a note corrected through dreaming got Claude past a one-way ledge that the uncorrected note had repeatedly led it to fall off. In a test building a wiki from the Stainless corpus, graded criteria met rose from 13% to 48% as dreaming scaled from 2 to 128 sessions.

For engineers building long-running agents, the main design rule is that the top memory layer must stay small. Put everything into injected context and the agent gets worse. Keep a compact, curated core and push detail into searchable lower tiers. Correcting memory should also be a scheduled background job, not something that happens only during a live session.

Read more — Anthropic

Google: Stale TODOs Cause "Agent Distraction" and Inflate Coding-Agent Costs

Google engineers published findings, covered by InfoQ on November 10, on agent distraction: coding agents getting pulled off task by stale TODO/FIXME comments that reference bugs. Across traces from thousands of internal engineers, about 13% of agent sessions exposed the agent to inline TODO references, and in 6% of those the agent started working on the referenced bug. Of those detours, 41% targeted tickets that were already closed and 57% targeted open bugs outside the scope of the request.

The cost was large: according to Google's regression analysis, detoured sessions used 70% more steps, 77% more tokens and 105% more wait time. Google's fix was to treat technical debt as agent-environment hygiene. It deployed scanner agents that remove obsolete TODOs, and humans accepted more than 95% of the resulting cleanup PRs over six months.

The takeaway generalizes: comments, docs and stale references in a codebase are now part of the agent's prompt. Cleaning up dead TODOs, outdated READMEs and misleading comments directly reduces agent cost and errors.

Read more — InfoQ

Google Open-Sources AQuA for Diagnosing Production Agent Failures

On November 13, Google open-sourced the Ambient Quality Agent (AQuA), a reference implementation that runs alongside a production agent on Google Cloud. It reads telemetry from Cloud Trace, Cloud Logging or BigQuery, outside the request path, so it adds no latency. Each run samples up to 1,000 sessions and works through a pipeline of sampling, review, clustering, verification and issue tracking.

To find root causes, its diagnosis agent compares failing sessions against an immutable snapshot of the deployed source and cites specific file and line ranges. In a controlled replay of 32 sessions from a multi-agent travel app, prompt changes guided by AQuA cut seat-selection bypasses from 15 sessions to 2 and dietary-preference omissions from 7 to 0. Google is clear about the limits: sampling can miss rare failures, replays may not reproduce external state, and AQuA does not apply fixes or open PRs on its own. It fits the emerging pattern of agents that monitor agents, with humans still applying the fixes.

Read more — InfoQ

Safe & Secure AI Agent Practices

GitHub Agentic Workflows GA: Read-Only Agents, Firewalls and Budget Caps

GitHub made its open-source Agentic Workflows generally available. Covered by InfoQ on November 11, the feature runs coding agents inside GitHub Actions for tasks such as issue triage and CI-failure analysis. Its security model is a useful reference design: agents start with read-only permissions, and proposed changes are applied by separate jobs that hold their own write tokens. Agents run in a sandboxed container behind an Agent Workflow Firewall, and a threat-detection job scans proposed changes before they are applied.

Cost controls are on by default: each run is capped at 1,000 AI Credits (about $10), with an organization default of 5,000 credits per day. InfoQ points out gaps teams should know about. The protections do not automatically cover direct write permissions or custom jobs that authors add, and ARC Docker-in-Docker runners run as privileged containers by default. One engineer quoted in the article said that telling an agent to ignore instructions in issue text does not by itself protect a workflow from prompt injection. Real isolation comes from the permission split, not the prompt.

Read more — InfoQ

Anthropic: How to Build Safety Evaluations That Hold Up

On November 13, Anthropic published guidance on designing, running and reporting safety evaluations, using examples from its system cards. For cyber evaluations, it says runs should happen in a sandbox with no internet access and be monitored in real time, because capable models may probe boundaries and take unintended actions if they escape. Anthropic says it has hardened its own eval environments, paused many evals that give models internet access, and added real-time monitoring to web-search evals.

For behavioral evals, it recommends multi-turn scenarios scored as an appropriate-response rate, with automated graders validated against human labels. One example shows how much the deployment context matters: a system prompt change raised the appropriate-response rate on a self-harm eval from 60% through the bare API to 94% in claude.ai. Teams evaluating their own agents should test the full deployed stack, including system prompt, tools and guardrails, not just the base model.

Read more — Anthropic