Field notes / agentic AI

What is actually changing, and what it changes about the way you build.

The field moves faster than any curriculum can be rewritten, so this is where the reading gets published rather than claimed. Every finding below is dated, carries the primary source, and is read before it appears here — a preprint is labelled a preprint and a vendor's research is labelled a vendor's.

7 current findings · last updated 15 August 2026 · nothing older than 90 days

Sourced from
01 / 2 findings

Reliability & evaluation

Where agentic systems fail in ways a token count or an eyeballed summary will not show you.

Compressing system-side control context has a sharp, non-linear reliability cliff

"Control Under Compression" (arXiv 2608.01056, 2 Aug 2026) targets agent control contexts — the persistent system-side instructions specifying tools, arguments, policies, execution protocols and recovery — rather than conversation history. Across a 15,525-run environment-verified benchmark, retaining 75% of context held success near the full-context baseline (92.7% and 92.4% versus 93.8%), but between 50% and 35% the methods diverged sharply, dropping to 47.0%, 39.0% and 19.9% at 35% depending on compression method. Failures appeared mainly as tool-execution and action-parsing errors, and reliability varied enough between control contexts that the authors argue universal compressor rankings are inappropriate and each context needs its own qualification. This reframes tool and policy prompt trimming as a runtime-reliability decision requiring per-context executable testing, with a safe-looking zone that ends abruptly.

arxiv.org agentic-aitool-designcontext-managementreliability

Context compaction shows up as a reliability failure, not just a cost lever

A preliminary empirical study (Min et al., arXiv 2608.06503, 6 Aug 2026) finds that recurrent context compression in long-horizon agents weakens the influence of recent interactions, producing more blocked actions, repeated exploration, and run-to-run instability — behavioural effects that token-count metrics never surface. The authors propose TRACE, which evaluates each individual compaction event by running paired closed-loop continuations from the same environment state, then optimises the compression prompt while leaving all models frozen. If your agent compacts, the implication is that compaction boundaries should be evaluated as discrete events with executable outcomes rather than by eyeballing summary quality.

arxiv.org agentic-aicontext-managementreliabilityevaluation
02 / 3 findings

Security & containment

The attack surface a system gains the moment it acts on content it did not author.

Early academic work argues the agent threat model is broader than instruction injection

A Seoul National University–led preprint argues that agent security research has concentrated too narrowly: prior work has focused primarily on indirect prompt injection, whose most-studied category is instruction injection, where attacker-controlled untrusted data is interpreted as an instruction. The paper's case is that data injection — poisoning what the agent believes to be true, rather than what it is told to do — is a realistic threat class in its own right. If your agent threat model is built solely around "untrusted text might contain commands", this is a prompt to widen it.

arxiv.org securitythreat-modellingagentic-airesearch

Indirect prompt injection against web-browsing agents documented in live campaigns

Zscaler ThreatLabz documented real-world campaigns embedding instructions in web content aimed at AI agents, describing indirect prompt injection as attacks that embed malicious instructions in content an AI agent retrieves — websites, documents, email — to influence the agent's reasoning during task execution. Their test setup matters: they built an autonomous agent with web browsing and payment-execution tools, ran it fully sandboxed with no real funds, and deliberately configured it with no spending limits to measure the maximum exploitation surface. The engineering takeaway is that spend caps, tool-scope limits and human confirmation on irreversible actions are the controls doing the actual work — not model-level instruction hardening.

zscaler.com securityprompt-injectionagentic-aicontainment

Statelessness moves MCP authorization to the application layer — and most MCP risk was never in the transport

Removing the session also removes per-session authorization context; as Google's write-up puts it, "As the responsibility of managing state shifts from the transport layer to the application layer, security becomes paramount." An independent security review of the release is blunter: statelessness changes where authorization happens and how you deploy the server, but the vulnerabilities found in MCP servers sit in the functionality they expose, which the specification does not touch. The spec upgrade buys scale and cheaper operations, not safety — every request must now carry and re-verify its own authorization, and tool-level authorization design remains entirely your problem.

equixly.com mcpsecurityauthorizationarchitecture
03 / 2 findings

Protocol, tooling & architecture

Releases that change how agentic systems get built — and what they make legacy.

MCP migration has sharp edges: silent version downgrade and three deprecated capabilities

Beta releases of the Python, TypeScript, Go and C# SDKs are available with support for the 2026-07-28 spec. The trap: the streamable HTTP transport accepts 2026-07-28 only when you set StreamableHTTPOptions.Stateless = true — leave it unset and clients negotiate down to 2025-11-25, a silent behavioural downgrade rather than an error, so add an explicit assertion on negotiated protocol version to your integration tests. Breaking changes are otherwise confined to the capabilities the specification deprecates — roots, sampling and logging; if your agent design leans on server-initiated sampling, that is now on a deprecation path. Also note that server/discover is optional for clients to call but mandatory for every 2026-07-28 server to implement.

blog.modelcontextprotocol.io mcptooling-releasemigration

MCP went stateless — the 2026-07-28 spec is a breaking change for remote MCP server deployment

The 2026-07-28 Model Context Protocol specification shipped with a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, authorization hardening, a formal extensions framework, and updated Tier 1 SDKs — the largest revision of the protocol since launch. The initialize/initialized handshake (SEP-2575) and the Mcp-Session-Id header (SEP-2567) are removed entirely; every request is now self-describing, with protocol version, client info and capabilities travelling in a _meta field inline on every request. A remote MCP server that previously needed sticky sessions, a shared session store and deep packet inspection at the gateway can now run behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tools/list responses for as long as the server's ttlMs permits. If you have an MCP server in production behind a Redis session store, that architecture is now legacy — plan the migration rather than inheriting it.

blog.modelcontextprotocol.io mcptooling-releasearchitecture
Method / how this page is made

An agent gathers it. A human decides what you see.

This page is itself a small piece of the craft it teaches — a retrieval agent with a bounded budget, a human review gate, and a deliberate refusal to let the agent speak about anything it cannot source.

  • 01

    One research pass per topic, on a schedule

    The retriever runs weekly across a fixed set of topics — architecture patterns, evaluation and reliability, agent security, and releases that change how systems get built. Each topic gets its own budget, because a shared one lets the first topic starve the rest and the agent then reports thin findings instead of admitting the gap.

  • 02

    Nothing publishes itself

    The scheduled run opens a pull request rather than committing. Sunil reads what the agent gathered before a prospect does, and every item carries a private note on source quality and what could not be confirmed — which is why the wording here is careful about the difference between an unreplicated preprint and a settled result.

  • 03

    The agent cannot write our own numbers

    Prices, dates, and seat counts are deliberately out of scope for the retriever and never appear on this page. They live in one place and are published from there, so a figure can never be current on an offer page and stale in a finding.

  • 04

    Findings expire

    Anything older than 90 days drops off automatically. A "latest" page quietly serving year-old news is worse than no page at all.

This is the reading. The program is the judgment.

Findings like these are raw material — knowing that context compaction is a reliability problem is not the same as knowing what to do about it in a system you are accountable for. That is what the 6 weeks are for.

Or ask the site's agent about any finding above — it answers from the same notes.