Diff

Vercel: agent building is a product problem, not a model problem

Andrew Qu's AI Engineer World's Fair talk argues that the teams who ship reliable agents stopped asking 'which model?' first and started asking 'what does the harness need?' — state management, verification loops, and tool surface boundaries are engineering problems that precede model selection. The talk landed the same week as Mike Chambers' AWS containment talk and Anthropic's featured engineering post 'How we contain Claude across products,' three independent sources converging on harness-first architecture as the discipline of 2026. For Policy Assistant, this is a direct frame for how to scale the protocol surface: the protocols themselves aren't the product, the harness that scopes, verifies, and re-runs them is.

AI Engineer30 min video

Read — youtube.com30 min

Harness-first: the model is a component; the envelope around it is the product
Separation of concerns between tool definition, tool routing, and tool verification
State management as the hidden cost of scaling agent workflows
When to trust the model's output and when the harness must check it

Why read anyway — Vercel ships at scale to developers — their harness choices reflect production constraints, not lab ideals. original ↗

via ai engineer world's fair 2026 — andrew qu, vercel

techniqueagents

AWS: 'production cage' = scoped capabilities + blast-radius cap per agent task

Mike Chambers coins 'production cage' for the set of containment patterns AWS uses in enterprise domain agents: each agent task gets a scoped capability surface, lateral movement between domains is blocked at the harness level, and blast radius is bounded before a task starts rather than after it fails. This slots alongside Anthropic's own engineering post 'How we contain Claude across products' as a practitioner-grade account of what containment actually means in production — not safety theatre but a concrete harness design. If Policy Assistant protocols ever reach out to external APIs or data stores on a user's behalf, the cage pattern is the architecture that makes that safe to expand.

AI Engineer30 min video

Read — youtube.com30 min

Production cage: scope capabilities per task, not per agent globally
Block lateral movement at the harness boundary, not at the model prompt
Blast radius is a design-time decision, not a runtime surprise
Enterprise domain agents need different containment than general-purpose assistants

Why read anyway — AWS is running this in production for enterprise customers — the patterns are battle-tested, not theoretical. original ↗

via ai engineer world's fair 2026 — mike chambers, aws

shiftindustry

Socher's Eureka Machine: an AI lab that runs, writes, and improves its own research loop

Richard Socher (ex-Salesforce Chief Scientist, founder of Recursive AI) describes a system — the Eureka Machine — where AI agents autonomously generate hypotheses, run experiments, interpret results, write paper drafts, and feed findings back to refine the next research loop. He calls it 'auto research' and frames recursive self-improvement of the research process itself as the near-term path to superintelligence — not a bigger model, but a tighter loop. The claim is debatable (Socher is not Hinton, and 'recursive superintelligence' is doing a lot of work in the title), but the concrete artifact — an AI system that closes the research loop end-to-end — is real and worth watching as the lab makes claims about what it can replicate.

Latent Space60 min video

Read — youtube.com60 min

Eureka Machine: agents propose, run, and interpret experiments autonomously
Auto research = closing the loop between hypothesis and publication draft
Recursive self-improvement of the research process, not the model weights
Socher's timeline: meaningful auto research within 2 years

Why read anyway — Socher built the research infrastructure at Salesforce AI; this is a practitioner's bet, not a lab paper. original ↗

via latent space — richard socher, recursive ai

MCP servers: expose workflows, not one tool per endpoint

The emerging best practice for MCP server design is to expose workflow-level operations — search/inspect/execute as a trio, or a bundled 'do the whole job' tool — rather than one tool per API endpoint. Bloated tool lists inflate context, confuse tool selection, and push discovery logic into the model prompt instead of the harness. The pattern: push discovery and routing client-side (as Codex and Claude Code now do), keep the server surface to the fewest tools that cover real jobs. For DotTif Labs or Policy Assistant MCP integrations, this is the design filter before adding any new tool.

Read — youtube.com6 min

One-to-one API tools bloat context and confuse tool selection
Layered discovery (search/inspect/execute) now lives client-side in Codex and Claude Code
Code mode: the agent writes a script in a sandbox and returns only the result
Workflow-level tools still matter — bundle the three calls a job needs into one
The server defines what tools exist; the client decides how to discover and execute them

Why read anyway — The Neon server before/after is the whole argument in one picture. original ↗

DeepMind's Schmid: the agent is now a markdown file and a sandbox

Philipp Schmid (Google DeepMind) argues that the next unit of agent deployment is a YAML/markdown skill file plus a filesystem — no Python glue code, no framework. Skills declare what the agent can do; the runtime handles invocation, memory, and tool access; the developer edits a text file and ships. The implication is that agent 'code' is increasingly declarative configuration, and the complexity moves into the runtime (harness) and the skill definitions. For Claude Code and Cowork users already writing .claude/agents/*.md files, this is exactly the trajectory already underway inside Anthropic's own tooling.

Read — youtube.com30 min

Agent = skill file (YAML/markdown) + sandbox; no framework, no glue code
Skills declare tools, memory access, and invocation patterns
The runtime is the complexity surface; the developer edits text
Filesystem as the agent's primary state store

Why read anyway — Schmid built Hugging Face's transformers library — his bets on what simplifies tend to land. original ↗

Cantrill: alarm without expertise is a breach of trust

Bryan Cantrill's essay argues that the current wave of AI alarm — from prominent engineers, executives, and researchers — is often 'expertise laundering': credentials from one domain lending false authority to predictions in another. His target is anyone who raises existential AI risk claims without the technical depth to evaluate them, which he treats as a professional ethics failure, not a difference of opinion. The essay has landed as a forcing function for technical practitioners to articulate where their own AI risk views come from.

Read — bcantrill.dtrace.org20 min

Alarm without expertise is a breach of professional trust
Expertise laundering: credentials from domain A don't transfer to domain B
The essay is a provocation, not a dismissal of AI risk
Cantrill's target is epistemics, not any specific claim

Why read anyway — Cantrill has a 20-year record of calling technical trends correctly — this is his epistemics essay, not a hot take. original ↗

Managed Agents now auto-evaluates each tool call individually

Managed Agents permission policies now include auto: instead of blanket rules (always run / always block a given tool type), the server evaluates each agent.tool_use and agent.mcp_tool_use call and decides to run, deny, or pause for human approval on a per-call basis. The evaluation decision surfaces in the event's evaluation field alongside evaluated_permission, so you can audit why each call was handled the way it was. Previously, granular per-call oversight meant either manual approval routing or complex static policy trees; auto makes the server the dynamic per-call gatekeeper. If Policy Assistant uses Managed Agents for protocol execution, this is the upgrade path from static permission policies to dynamic per-call evaluation — closer to the Sentinel pattern Meta built for Muse, but inside the Claude Platform.

DeepSeek V4.1 Flash: 552B MoE, native vision, 60% cheaper cached reads

DeepSeek released V4.1 Flash on September 10 — a 552B-parameter mixture-of-experts model (8B active on input, 16B on output) with native vision, 1M token context, and a new Causal Encoder-Decoder architecture that cuts the KV cache to ~890 bytes per token (roughly one-quarter of V4-Flash). Pricing: cached input at $0.003/MTok (60% lower than V4-Flash), uncached at $0.15/MTok, output at $0.60/MTok. V4 Pro is being discontinued. The cached-read price is the headline: for cache-heavy agentic loops, V4.1 Flash is now competitive with Fable 5.1's $0.25/MTok cache reads on a cost-per-task basis, while being multimodal. If you track model economics and cost per agentic task, this is the new reference point for what a Flash-tier open-weight model costs at scale.

Fable 5.1 thinking blocks persist across turns — and bind to your prefix

Since the September 1 launch, Claude Fable 5.1 preserves thinking blocks in conversation history so the model can build on its own previous reasoning in later turns. Two constraints matter for production: (1) thinking blocks replay only to Fable 5.1 or newer — earlier models silently receive them empty; (2) on accounts created August 31 or later, if anything before a thinking block changes between turns (system prompt, tools, earlier messages), replaying that block returns a 400 error. The thinking-binding-controls-2026-08-01 beta header gives you control: prefix_mismatch_behavior chooses between rejecting or silently dropping mismatched blocks, and input_transformations in the response reports what was dropped. If Policy Assistant runs multi-turn sessions that inject per-turn context into the system prompt or swap tool specs mid-conversation, this binding behavior is the new constraint to test against — it can silently fail unless you opt in to the beta header.

Fable 5.1 cache reads dropped 75% — now $0.25/MTok

Cache reads on Claude Fable 5.1 cost $0.25/MTok (0.025× base input price), compared to $1/MTok (0.1×) on Fable 5 and all other models. For a heavily cached agentic loop with a large system prompt or tool spec, this cuts the cache-read cost by three-quarters automatically once you are on Fable 5.1. The cost improvement alone strengthens the Fable 5.1 migration case — though the breaking change on tool_choice: any/tool (those now return 400; switch to auto or the strict tool-use pattern) needs a check before migrating, if Policy Assistant forces tool selection via tool_choice.

`clear_at` lets per-turn reminders render once and cost nothing after

clear_at: "next_user_message" on a mid-conversation system message makes it render once (after a tool result, for example), then silently drop to zero tokens on every subsequent request — while staying in the array byte-for-byte so the prompt cache prefix stays intact. The pattern it solves: per-turn reminders like 'verify your previous step' or 'request independent reads in one turn' that would otherwise pile up in message history and inflate costs over a long agentic loop. The constraint worth knowing: the cleared message must be re-sent byte-for-byte unchanged on every subsequent call; editing or removing it breaks the cache and any bound thinking blocks. If Policy Assistant has per-turn instruction patterns in its protocol loops, this is the clean fix.