Agent-to-Agent Protocols

Standards and conventions by which agents discover, negotiate with and delegate to other agents — the interoperability layer of the agentic web.

Also known as: A2A, A2A (Agent-to-Agent), agent-to-agent, agent card, Handshake (A2A handshake), open agent protocol, protocols (externalized), two-agent collaboration, shared interfaces

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (17)

• Presentation: APIs for Agents: Rethinking API Programs in the MCP Era Jim Gough, Andreea Niculcea · 2026-09-23 Reader 🖥️
  As agent protocols (MCP, then A2A, then whatever comes next) reshape how consumers reach enterprise systems, Morgan Stanley argues platforms should keep APIs as the stable, governed foundation and use Architecture-as-Code (CALM) to encode, version, and automatically enforce security/governance controls and deployment gates across every protocol adapter built on top — so the organization can adopt new interaction protocols quickly, and evolve already-deployed services at scale, without sacrificing safety or consistency.
• AI Sovereignty: Bargaining with Big Tech and the Promise of Full Stack Open Source AI Nicole Butterfield · 2026-09-22 Reader 🖥️
  Genuine AI sovereignty requires building and sustaining an interoperable, full-stack open-source AI ecosystem — spanning agent harnesses, inference engines, protocols, data stores, and observability tooling, not just open-weight models or vendor-branded 'sovereignty' offerings — because dependency and acquisition pressure persist at every layer that stays closed or commercially controlled.
• The Interfaces Are Arriving Tommy Tran · 2026-09-11 source ↗ Reader 🖥️
  Because rival AI vendors are now donating and independently implementing shared interoperability protocols (MCP, A2A) under neutral, foundation-based governance — repeating the historical pattern of Ethernet and the Language Server Protocol — engineering organizations should treat these protocols as durable, ownable infrastructure worth building on now, even though the standards themselves remain young and cannot resolve the deeper semantic-trust and cross-hop-delegation problems that lie beneath them.
• Multi Agent Collaboration Gets Persistent Compute in Bedrock AgentCore Matt Saunders · 2026-08-19 source ↗ Reader 🖥️
  Amazon Bedrock AgentCore's new runtime instances add a persistent, EC2-backed compute option alongside its existing eight-hour microVM sessions, and the right choice between the two is a workload-shape decision (session length, GPU/memory needs, multi-agent co-location, sustained CPU utilization) rather than a wholesale replacement of one by the other.
• When Your Buyer Is an AI Agent Rudrendu Paul and Sourav Nandy · 2026-08-19 source ↗ Reader 🖥️
  As autonomous AI agents increasingly perform the research, negotiation, and (in advanced cases) contracting stages of enterprise B2B procurement on the buyer's behalf, sellers must re-architect their commercial infrastructure — replacing per-seat pricing with outcome-based pricing, replacing relationship-driven sales collateral with machine-readable product data, and replacing human-click checkout with agent-compatible authorization — or risk being screened out of consideration before a human relationship ever begins.
• An Evolutionary Architecture Pattern for Managing AI's Pace of Change Joe Price, Branimir Đurek, Pavlos Migkiros, Trevor Dearham · 2026-07-27 source ↗ Reader 🖥️
  Because AI capabilities, protocols, and threats now change faster than enterprise systems can safely absorb — a gap the authors treat as permanent rather than a phase to wait out — organizations should deliberately concentrate the fastest-moving AI concerns (model routing, identity, action policy, segmentation, content guarding, and audit) into one architectural seam, the AI gateway, so the rest of the enterprise can remain stable, and should build that seam proactively rather than at the higher cost of building it after an incident forces the issue.
• Article: Multi-Agent AI for Production Security Operations: An A2A and MCP Architecture in a 5G Core Willem Berroubache · 2026-07-23 source ↗ Reader 🖥️
  In a high-volume, high-stakes security operations center, a multi-agent LLM architecture becomes production-viable and durable only when narrow agents coordinate over open protocols (A2A/MCP), expensive non-deterministic LLM inference is gated behind a cheap classical anomaly detector, and every consequential action is checked by a privileged, deterministic policy-as-code reviewer that treats human escalation as a first-class designed output rather than a monolithic LLM or a GenAI layer bolted onto conventional SIEM/SOAR tooling.
• The Pragmatic Engineer AMA The Pragmatic Engineer · 2026-07-08 Reader 🖥️
  Orosz's authority and judgment — on his own editorial choices, on hiring, on technology standards, and on AI adoption — consistently rest on direct, ground-level evidence and deliberate, revisable tradeoffs rather than on assumption, hype, or a fixed ideological stance.
• Tony Seale's Post Tony Seale · 2026-07-05 source ↗ Reader 🖥️
  Durable agent memory should fuse the two kinds of human memory — a markdown wiki for the episodic (what happened) and a formal ontology for the semantic (what things mean) — in one layered file format, Vault-LD (markdown plus optional YAML-LD frontmatter), so that any note can progressively acquire structure and meaning and a private vault can scale, unchanged in substrate, from a personal second brain up to an open, decentralised agentic web.
• AWS Releases Loom, an Open-Source Reference Platform for Governing AI Agents at Enterprise Scale Steef-Jan Wiggers · 2026-07 Reader 🖥️
  Loom demonstrates — as a free, open-source reference implementation rather than a managed product — that enterprise-grade AI agent governance is achievable today by composing existing AWS primitives (Strands Agents, Bedrock AgentCore Identity, RFC 8693 token exchange, Secrets Manager) into a configuration-driven, identity-propagating platform, with resource tagging and delegated on-behalf-of tokens as the two mechanisms that make agent actions auditable and scoped end-to-end.
• Agent Tools & Interoperability Kanchana Patlolla, Łukasz Olejniczak, Pier Paolo Ippolito · 2026-06-10 Reader 🖥️
  Adopting standardized agent-interoperability protocols — MCP for tools, A2A for agent-to-agent delegation, A2UI for agent-generated interfaces, and AP2/UCP for agentic commerce — replaces the bespoke, fragile wrappers of custom integration with a modular, plug-and-play 'virtual workforce' architecture, converting a developer from a low-leverage integration 'Conductor' into a high-leverage system 'Orchestrator.'
• This Week in AI: Rethinking the Agent Harness Michelle Smith · 2026-05-22 source ↗ Reader 🖥️
  In mid-2026 the strategic locus of AI value has shifted from model selection to harness design, so practitioners — including non-developers — should build their own skill-driven agent harnesses rather than depend on bespoke applications or wrapped commercial products.
• The Production Gap: 5 Patterns for Building Long-Running AI Agents Addy Osmani and Shubham Saboo (Google Cloud), published in Turing Post · 2026-05-22 source ↗ Reader 🖥️
  To survive contact with real production workloads, AI agents must be redesigned as long-running, stateful server processes — using checkpoint-and-resume, in-place delegated approval, governed multi-layer memory, ambient event-driven processing, and fleet orchestration with A2A/MCP interoperability — because most current agent architectures are 'secretly stateless' and silently reconstruct context from scratch on every turn.
• The Agentic P&L: Beyond the Empire of Headcount Shreshta Shyamsundar and Anmol Jain · 2026-05 source ↗ Reader 🖥️
  Headcount is obsolete as the unit of corporate value; in an agentic enterprise, leverage must be measured and rewarded along three new axes — contextual density (potential energy of knowledge enclaves), agentic throughput at a managed cost per cognitive outcome (kinetic energy), and revenue productivity per person — organized in '3+N' squads governed by decision-provenance 'mirrors'.
• The AI paradox: More automation, more humans, more work | Dan Shipper Lenny Rachitsky (host); Dan Shipper (guest, CEO Every) · 2026-05 Reader 🖥️
  Despite radically improving model capabilities, the agentic era will paradoxically generate more work for more humans — because every agent needs a human gardener, SaaS persists (with users bringing their own tokens via Codex/Claude Code), and progress merely commoditizes yesterday's competence and pushes humans further up the value chain to define what is worth doing next.
• #3: How to Build an AI-Native Startup from Day One Will Schenk (TheFocus.AI) and Ksenia Se (Turing Post) · 2026-04-11 source ↗ Reader 🖥️
  An AI-native startup is one designed from inception so that machine intelligence can participate in ordinary business work; achieving this requires making organizational knowledge machine-legible, choosing tools for visibility and portability, and restructuring work around outcomes rather than handoffs -- shifting the founder question from 'where do we use AI?' to 'what parts of the business assume intelligence is abundant, uneven, and improvable?'
• Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering Chenyu Zhou, Huacan Chai, Wenteng Chen, Zihan Guo, Rong Shan, Yuanyi Song, Tianyi Xu, Congming Zheng, Jiachen Zhu, Zeyu Zheng, Zhuosheng Zhang, Xingyu Lou, Zhihui Fu, Jianghao Lin, Weinan Zhang · 2026-04-09 Reader 🖥️
  Practical progress in LLM agents increasingly depends not on improving model weights but on externalizing cognitive burdens into external infrastructure — memory, skills, protocols, and harness engineering — which together form a systems-level framework of cognitive artifacts.

Propositions touching this concept (9)

By publication month, oldest first (extraction month when no publication date is known).

2025-09

• explicitThe subagents feature was built in a three-day internal hackathon in which the team spent the first two days designing, then discarding, a complex multi-agent topology with inter-agent message buses, before converging on day three on the simplest viable design: a single blocking orchestrator invoking agents defined only via the existing "/" command and markdown files, with no agent-to-agent communication.
  How Claude Code Is Built · p13

2026-04

• implicitCurrent AI tooling has made agent-to-agent collaboration easier than human-to-human collaboration on the same codebase, which is an inversion of priorities
  Genie Lessons: Nobody Wants Agents · p5

2026-05

• explicitA future 'open agent protocol' will let agents move between environments and receive environment-specific skills from each environment.
  This Week in AI: Rethinking the Agent Harness · p12

2026-06

• explicitA2A resolves agent-ecosystem fragmentation by giving a central Orchestrator a standard way to discover (via Agent Card + registries), onboard, and delegate to any specialist agent regardless of its underlying framework, language, or organization.
  Agent Tools & Interoperability · p4
• explicitThe largest concrete sources of AI waste found in Revenium's beta testing were circular/redundant dependencies among agent-to-agent requests, continued reliance on outdated and more expensive models, and concentrated high failure rates with specific model providers.
  The tokenmaxxing party is over, and Revenium is mopping up · p5

2026-07

• explicitCentralized agent/tool discovery (via a registry complying with the A2A agent card spec and MCP tool schema) is treated as a governance mechanism, not merely a convenience feature — agents undergo review before being publishable for production use.
  AWS Releases Loom, an Open-Source Reference Platform for Governing AI Agents at Enterprise Scale · p9
• explicitdevelopedMCP's authentication, transport mechanisms, and tool discovery are still changing as adoption grows, and no clear industry standard yet exists for agent-to-agent (A2A) protocols, so parts of an AI integration stack built today may look different within 12 months.
  An Evolutionary Architecture Pattern for Managing AI's Pace of Change · p12

2026-09

• explicitThe semantic gap produces a trust gap: a protocol, or a signed A2A Agent Card, can carry a claim and bind it to an identity, but an organization still needs an independent basis for deciding which identities, publishers, code, and claims deserve authority — the protocol carries that decision through a system, it does not make it.
  The Interfaces Are Arriving · p10
• explicitPreventing token passthrough closes one authorization hole, but no common mechanism yet defines how authority should narrow (attenuate) as a request passes through an arbitrary chain of agent-to-agent-to-tool hops, so platforms currently solve delegation locally or leave too much authority in place.
  The Interfaces Are Arriving · p11

Open gaps (53)

• incompleteHeadcount-as-political-capital is not reckoned with. The authors treat headcount purely as a productivity input that has been superseded. But in real enterprises, headcount is the currency of influence in budget negotiations, executive succession, real-estate claims, and cross-functional bargaining. A VP with 500 reports has structural leverage that a 3+N squad lead with equivalent cost per cognitive outcome simply does not have, because the negotiating game inside the firm is still played in headcount units. The article's 'reframing that works' assumes prestige and political capital will rebase on the new metrics; it does not argue for it.
  The Agentic P&L: Beyond the Empire of Headcount — read next: John Cutler on operating-system design and 'institutionalized overload' (TBM 411–413); Jeffrey Pfeffer 'Managing With Power' on resource-based political capital inside firms; Henry Mintzberg on the politics of organization; recent work on 'middle manager hollowing' under AI
• incompleteThe implicit theory of compensation and prestige re-anchoring is unargued. If pay and status currently track span-of-control, what is the mechanism by which they migrate to enclave density, RPP, and cost per cognitive outcome? Boards, peer benchmarking firms (e.g. Mercer, Korn Ferry), proxy advisors, and executive labor markets all currently price seniority partly on people-managed. The article needs an account of how this rebasing happens — or admits that early adopters will lose talent to firms still paying for empires.
  The Agentic P&L: Beyond the Empire of Headcount — read next: Compensation literature on equity comparators (Bebchuk, Fried); Korn Ferry and Mercer methodology papers; the 'platform company' compensation case studies (Stripe, Shopify) where small teams produce outsized revenue
• incompleteAccountability and liability allocation in the 3+N model is hand-waved. The 'human-as-rubberstamp' joke acknowledges the failure mode but the article does not specify who is on the hook when an agentic compliance decision causes a regulatory breach: the strategic architect? The policy-and-ethics lead? The vendor of the foundation model? The CFO who signed off on the cost-per-outcome budget? Without an answer, regulators are unlikely to treat the mirror as substantively equivalent to a named accountable individual.
  The Agentic P&L: Beyond the Empire of Headcount — read next: EU AI Act allocation of responsibility; the FCA / PRA senior managers regime in UK financial services; recent Bank of England consultation papers on AI in regulated firms
• incompletePower dynamics between the 3+N squad and the rest of the enterprise are unaddressed. If most of the cognitive work has shifted into squads, who allocates budget to them, who chooses what gyms to build, and who controls promotion across them? The article specifies the three internal human roles (architect, policy lead, orchestrator) but is silent on the governance layer above and the inter-squad coordination layer between.
  The Agentic P&L: Beyond the Empire of Headcount — read next: Spotify squad-tribe-chapter critiques (Henrik Kniberg's later writings, Marty Cagan); team-of-teams literature (Stanley McChrystal); Cutler on cross-team operating models
• incompleteNo adoption or outcome data is presented — no organizations are named as having deployed Loom, no metrics on how it performs against the seven challenges in practice, and the only community reaction is a single Reddit comment two days after release. The 'reference platform' framing is asserted, not evidenced.
  AWS Releases Loom, an Open-Source Reference Platform for Governing AI Agents at Enterprise Scale — read next: Track future InfoQ or AWS coverage for case studies of organizations that adopted or forked Loom, or search for post-mortems on the AWS Labs GitHub repo (issues, forks, deployment reports).
• incompleteThe article notes Loom's role-based access model 'still carries visible demo scaffolding' but doesn't specify what that scaffolding is or what a production-hardening checklist would include — leaving the reader unable to assess how much engineering work stands between the reference implementation and an actual production deployment.
  AWS Releases Loom, an Open-Source Reference Platform for Governing AI Agents at Enterprise Scale — read next: Read the AWS Labs repository's own deployment guide and cleanup instructions (mentioned in the closing paragraph) for the concrete list of what's demo-only versus production-grade.
• uninformedThe article asserts that MCP's authentication, transport mechanisms, and tool discovery 'have changed as adoption has grown' and that A2A protocols have 'no clear industry standard,' but never gives a concrete before/after account of what gateway-side integration work this protocol churn has actually broken in a real deployment.
  An Evolutionary Architecture Pattern for Managing AI's Pace of Change — read next: The MCP Transport Working Group's spec-change history (e.g., SEP-1442) and vendor gateway release notes (kgateway, Portkey, LiteLLM), to see how much engineering effort per release cycle is attributable to keeping pace with MCP/A2A spec changes versus shipping new features.
• incompleteThe transfer of the 'cognitive artifacts' framework from human cognition to LLM systems is asserted but not defended. Human cognitive artifacts augment a general intelligence; LLM externalization compensates for specific architectural limitations (finite context, no persistent state). The analogy may be more misleading than illuminating.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Look for critiques of anthropomorphic framings of LLM capabilities; compare with distributed systems or compiler theory as alternative analogies.
• incompleteThe taxonomy assumes memory, skills, and protocols are 'distinct but coupled' — but the boundaries may be artificial. A skill with embedded memory and protocol-like interfaces blurs all three categories. The abstract does not address how to handle such overlap.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Check whether the full paper provides clear criteria for categorizing borderline cases.
• uninformedThe abstract does not address whether externalization introduces new failure modes (brittleness, composability failures, versioning conflicts) that may offset reliability gains. The framing is almost entirely positive.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Look for systems engineering literature on integration risk; check if the full paper's 'open challenges' section addresses this.
• illogicalThe historical progression 'weights -> context -> harness' is presented as a clean trajectory, but in practice these co-evolve. Larger context windows reduce the need for some externalization; better weights reduce the need for elaborate harnesses. The narrative oversimplifies.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Consider whether a co-evolutionary or dialectical framing would be more accurate than a linear progression.
• incompleteNo discussion of agent-to-agent trust boundaries. When multiple agents operate in the same repository or pipeline, can one compromised agent influence another? The architecture treats 'agent' as a single entity rather than addressing multi-agent coordination security.
  How GitHub Is Securing Agentic Workflows in Modern CI CD Systems — read next: Multi-agent systems security literature; research on trust propagation in autonomous system networks.
• incompleteNo discussion of conflict of interest: the 'independent AI explainer' is produced by the same platform that monetizes the slot. The word 'independent' carries the full epistemic load of the trust claim and is never justified.
  A new generation of ads for the AI era of Search — read next: Read regulatory and FTC commentary on AI-generated ad disclosures; read on agentic commerce protocols (e.g., Anthropic / OpenAI agent-to-agent standards) for alternative settlements; revisit Tim Hwang 'Subprime Attention Crisis' on the structural economics of programmatic ads
• incompleteThe 'virtual workforce' framing never addresses runtime failure modes for a remote A2A specialist (unavailable, slow, or behaving maliciously/incorrectly), despite the paper's own MCP best-practices section explicitly warning against trusting unverified public servers — the same caution is absent from the A2A discovery/registry sections.
  Agent Tools & Interoperability — read next: Look for A2A-specific resilience patterns (circuit breakers, fallback orchestration, registry trust scoring) in follow-on protocol documentation.
• uninformedThe paper treats MCP and A2A as settled 'Industry Standards' worth building an architecture around, without engaging the countervailing view — present elsewhere in the corpus — that individual agent protocols are still young and revised rapidly, and that APIs (not agent protocols) should remain the stable integration point precisely because of that churn risk.
  Agent Tools & Interoperability — read next: Compare directly against documents arguing for an API-stable, protocol-agnostic integration layer underneath MCP/A2A.
• incompleteThe paradox is asserted but its mechanism is under-specified. Shipper offers 'every agent needs a human' (a maintenance claim), 'benchmarks miss prompting' (an attention claim), and 'models commoditize yesterday's competence' (a frontier claim). These are three different mechanisms doing different work, and Shipper conflates them. The maintenance claim is explicitly transient — he concedes personal agents return as models improve. The attention claim is partially circular — he will redesign his benchmark to zero out a saturated model. Only the frontier claim is structural, and it is the least developed. A serious version of the thesis needs to argue that the new frontier work is itself non-automatable and remunerated — neither is shown.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Acemoglu & Restrepo on task displacement and reinstatement; the 'augmentation vs. automation' literature (Brynjolfsson, Mitchell); recent econometric work on AI's effect on call-centre and software-engineering productivity (the GitHub Copilot RCT, Brynjolfsson-Li-Raymond on generative AI in customer support)
• incompleteThe 'humans-as-orchestrators' vision is unfalsifiable in this conversation. Shipper says explicitly that when models 'saturate' his senior-engineer benchmark, he will redesign it to zero out the current model. If the benchmark moves to wherever AI cannot yet go, the claim 'humans are still needed' is true by construction and tells the listener nothing about the actual trajectory of automatable knowledge work. A senior engineering leader needs a falsifiable formulation — what specifically would need to be true for Shipper to concede that the 'more humans' claim has expired? — and the conversation does not offer one.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Popper on falsifiability; Sutton's 'bitter lesson' as the counter-frame; the eval-design literature (HELM, MMLU saturations, the ARC-AGI debate); recent critiques of human-baseline benchmarks (Anthropic's METR work on long-horizon agentic tasks)
• incompleteSelection effects in the Every case are uninterrogated. Every is ~30 self-selected curious early adopters with pre-release model access, dual media-and-software business model, founder writer-CEO, no legacy systems, no regulated environment, no enterprise sales process longer than the model release cycle. Every assertion in the conversation is sourced from this one organization and projected onto knowledge work in general. For evaluating organizational impact in a Norwegian enterprise context (regulated industries, slower procurement, less English-language model access for non-English work, strong worker-council constraints), the generalization gap is large and unflagged.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Erik Brynjolfsson's recent work on cross-firm productivity dispersion in AI adoption; Wharton-led surveys on enterprise AI deployment; case studies from regulated EU firms (Klarna's published numbers and their later retraction); Norwegian-context: BI Handelshøyskolen / Sintef studies on AI adoption in Nordic enterprise (the 'forskning og digitalisering' extraction in this library)
• incompleteToken-economics assumption (SaaS users bring their own tokens via Codex) is treated as a stable equilibrium when it is more plausibly a transitional artifact. Once enterprise procurement notices that token spend is shifted to user-attached agent harnesses, three forces will push back: (a) per-call agent-tier pricing from SaaS vendors capturing the new volume, (b) enterprise consolidation of agent infrastructure (corporate-controlled Codex/Claude Code deployments), and (c) usage-based SaaS pricing emerging precisely to capture agent-driven volumes. Each of these inverts Shipper's 'buy SaaS stocks' conclusion. He does not engage any of them.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Tomasz Tunguz's recent essays on AI pricing; the cloud-pricing history (AWS's evolution from flat to consumption); Bessemer State of the Cloud reports on agent-driven pricing changes; OpenRouter / LLM-aggregator economics
• incompleteShipper's 'CEO must be personally AI-pilled' claim sits uncomfortably with his 'super-agent per company maintained by a forward-deployed engineer' claim. If the FDE is the load-bearing role and the per-company agent is the substrate, the CEO's personal model fluency is arguably the wrong variable to optimize — the firm needs FDE talent supply and an org design that protects FDE attention from the C-suite. The conversation never reconciles the personal-fluency prescription with the structural FDE prescription.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Karl Weick on 'sense-making' in organizations; recent CIO/CTO surveys on AI organizational placement (Gartner, MIT Sloan); the literature on 'two-pizza team' analogues for AI deployment
• incompleteNo engagement with worker-attention costs of the prescription. 'Ride the models' for every new release, 'try Codex in your off-hours if your employer blocks it', 'every agent needs a human gardener', 'inbox-zero for 10 straight days via Codex monologue' — collectively this is a maximally attentive lifestyle marketed as liberation. Shipper notes he 'works way more' and frames it as paradox-evidence, not as cost. For a senior engineering leader thinking about sustainable organizational design, the elision of attentional and psychological cost is significant.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: The 'AI psychological costs' extraction in this library (extract-psychological-costs-of-ai-*); Cal Newport on attention residue and deep work; recent labour-economics work on AI-driven work intensification (LSE, Stanford); union/works-council positions on AI workload
• illogicalThere is internal tension between (a) 'CLIs are over, GUIs win' and (b) 'agents using SaaS via CLI is how SaaS survives'. If the user's primary surface is Codex/Co-work GUI and the agent talks to SaaS over CLI, then CLIs are precisely what is preserved — they are the agent-readable API layer, not the user surface. Shipper conflates the user-surface CLI claim with the agent-readable-API CLI claim. The two are different and have opposite trajectories: the first dies, the second flourishes. The conversation does not separate them.
  The AI paradox: More automation, more humans, more work | Dan Shipper
• incompleteThe article recommends publishing SOC-domain agent schemas industry-wide (a call the author repeats from KubeCon feedback) but never engages the tension this creates with Property 4/5: if agent schemas standardize across operators, does the safety-policy layer standardize too, and if so, does that create a shared attack surface or single point of failure across every adopter of the published schema — the article treats schema standardization as unambiguously good without weighing this cost.
  Article: Multi-Agent AI for Production Security Operations: An A2A and MCP Architecture in a 5G Core — read next: Compare against supply-chain-security literature on shared/standardized security tooling creating correlated risk across adopters.
• incompleteThe article frames the new pattern ('agents call each other as tools within a shared session') as a smile-inducing convenience, but doesn't address how it relates to — or competes with — AgentCore's own Agent-to-Agent (A2A) protocol support, which InfoQ's own earlier coverage (cited in this same article) established as AgentCore's interoperable multi-agent mechanism. Are these two different multi-agent patterns meant for different scopes (same-host co-location vs. cross-network agent discovery), or does the shared-session pattern quietly sideline A2A for same-vendor multi-agent work?
  Multi Agent Collaboration Gets Persistent Compute in Bedrock AgentCore — read next: AWS's Agent-to-Agent protocol support documentation for AgentCore (the InfoQ article on A2A support for Bedrock AgentCore cited here) and the corpus's broader agent-to-agent-protocols material, to see whether AWS itself distinguishes when to use shared-session co-location versus A2A calls between AgentCore agents.
• incompleteThe piece describes human review as optional ('Humans may review pull requests, but aren't required to... we've pushed almost all review effort towards being handled agent-to-agent') but never says what determines which PRs actually receive a human look versus none, or what happens when agent-to-agent review systematically misses the same class of issue because both the authoring agent and the reviewing agent share the same model's blind spots.
  Harness engineering: leveraging Codex in an agent-first world
• incompleteThe 'rethinking' is asserted rather than performed. The article never enumerates the prior harness assumptions being overturned (e.g., DAG-based orchestration, deterministic tool dispatch, code-defined skills, developer-mediated change) nor articulates the new principles replacing them beyond 'skills written in English.' For a piece titled 'Rethinking the Agent Harness,' the actual rethink is one anecdote and one neologism.
  This Week in AI: Rethinking the Agent Harness — read next: Berryman & Ziegler, 'Prompt Engineering for LLMs' (the cited O'Reilly book); Anthropic's own Claude Code design docs; the Stanford paper at arXiv:2603.28052; Birgitta Böckeler's 'harness engineering' piece for an attempt to actually decompose the harness layer.
• incompleteSingle-case generalization. The unity ('build your own harness') rests almost entirely on one consulting client where it 'worked perfectly.' No failure modes, no boundary conditions, no comparison to cases where a bespoke app or a wrapped product would still be the right choice.
  This Week in AI: Rethinking the Agent Harness — read next: Post-mortems of agent deployments at scale; the Cognition/Devin retrospectives; harness-engineering writeups from teams shipping to production rather than consultants.
• incompleteThe relationship between the three sections is unargued. Mythos, the compute buildout, and the harness thesis are juxtaposed without the article noticing that they imply different theories of where AI value is moving — model layer (compute), capability frontier (Mythos), or harness layer (Berryman). The implicit reconciliation would be the most interesting move and isn't made.
  This Week in AI: Rethinking the Agent Harness — read next: Articles framing 'value migration in the AI stack' explicitly; investor letters or analyst notes that try to resolve which layer captures economic returns.
• incompleteThe 'open agent protocol' is named without being specified. No design sketch, no examples of what an environment-supplied skill looks like, no comparison to existing proposals (MCP, A2A, agent-to-agent protocols). The reader is left with a direction but no testable proposal.
  This Week in AI: Rethinking the Agent Harness — read next: Anthropic's Model Context Protocol spec; agent interoperability proposals from Google, OpenAI, and the LangChain ecosystem; the future-cast section in the next Berryman appearance.
• uninformedSchneier's challenge to Mythos's uniqueness is mentioned and then immediately set aside ('either way, it's a problem that's coming'). The article does not engage with the substantive question of whether the policy response is calibrated to actual differential capability or to perceived capability — a question whose answer matters for whether FDA-style review is wise.
  This Week in AI: Rethinking the Agent Harness — read next: Schneier's full post on Mythos; CAISI's framing; counter-arguments from researchers who replicated Mythos-like findings on cheaper public models.
• illogicalMild equivocation on 'harness.' Claude Code (a specific product), 'the agent harness' (a layer), and Berryman's bespoke consulting build (a specific instance) are used interchangeably. A reader could leave thinking 'use Claude Code' and 'build your own harness' are the same recommendation, when the article's argument actually requires the latter and only points at the former as an example.
  This Week in AI: Rethinking the Agent Harness — read next: Explicit harness taxonomy work — what distinguishes a product, a framework, and a bespoke harness — e.g., Böckeler's 'harness engineering' piece.
• incompleteOrosz states his default editorial policy is to write about what works rather than what's broken, yet his most notable piece is precisely an exposé of what went badly wrong at Pollen. He never articulates the criteria or threshold (e.g., degree of misconduct, being publicly dismissed) that triggers an exception to the default policy.
  The Pragmatic Engineer AMA — read next: Look for any explicit statement of The Pragmatic Engineer's editorial values/criteria beyond this one anecdote — e.g., an About page, a past newsletter issue on his editorial philosophy, or interviews where he discusses how he decides what to cover critically.
• incompleteThe claim that standards adoption hinges on the originating company being perceived as non-dominant rests on a single supporting case (MCP) and a single contrasting case (Agent2Agent), with no broader survey of other protocol/standard adoptions to test the generality of the mechanism.
  The Pragmatic Engineer AMA — read next: Compare against the adoption histories of other widely-adopted open protocols/standards (e.g., OAuth, gRPC, Kubernetes, USB-C) to test whether 'non-threatening originator' consistently predicts adoption, or whether technical merit and network effects dominate more often.
• incompleteThe 'AI doesn't make work easier if you're pushing yourself hard enough' claim is a personal heuristic with no account of how it might vary by task type, seniority, or skill level — it's unclear whether it generalizes beyond an expert writer/engineer who has already optimized their own workflow.
  The Pragmatic Engineer AMA — read next: Look for empirical research on AI's effect on productivity/effort across skill levels and task types (e.g., controlled studies of AI-assisted coding speed) to test whether the 'should still feel just as hard' framing holds broadly or mainly for already-expert practitioners.
• uninformedThe deterministic-simulation/hostile-environment testing technique (via Antithesis) is presented through a sponsor endorsement with a screenshot and a one-line personal impression, not a technical account of how deterministic replay is achieved, what classes of bugs it does or doesn't catch, or its performance/adoption cost.
  The Pragmatic Engineer AMA — read next: Read Antithesis's own technical documentation or independent write-ups on deterministic simulation testing (and compare with FoundationDB's well-documented deterministic-simulation approach) to evaluate the technique on its merits beyond the sponsored blurb.
• incompleteThe closing wager — 'the interfaces are likely to last' — is stated with confidence but the essay never specifies what would falsify it: a major founding vendor forking MCP, a rival protocol displacing it, or one founding company (e.g. Anthropic, as MCP's originator and steward) accumulating outsized influence inside the supposedly neutral Agentic AI Foundation. Without a falsification condition, the durability claim is unfalsifiable as stated.
  The Interfaces Are Arriving — read next: Track the Agentic AI Foundation's actual governance structure and voting/veto rights among Anthropic, Block, OpenAI, and the supporting companies (Google, Microsoft, AWS, Cloudflare, Bloomberg) over the next 1-2 years, and watch for defections or competing forks.
• incompleteThe implicit failure model is not made explicit. The patterns are pitched as a coherent system but the specific breakdowns they prevent are scattered: context loss after a 4-hour crash (Pattern 1), reasoning-context loss on HITL serialization (Pattern 2), behavioral drift and cross-workflow data leakage (Pattern 3), policy-version skew across an unsupervised fleet (Pattern 4), LLM-shortcutting orchestration logic and cascade-failure deploys (Pattern 5), and bespoke integration tax (A2A/MCP). A reader looking for 'which pattern solves which specific production breakdown' has to reverse-engineer the mapping.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Read Reed's 'Ironies of A²I²' (Bainbridge revisited) for the failure-modes-of-automation framing the post is implicitly using but never names; pair with Grab's multi-agent engineering-support post for a concrete incident catalog from an actual production deployment.
• incompleteHuman throughput is treated as a non-issue. The post mentions 'managing twenty concurrent long-running agents' and a 'unified inbox' but never confronts the reality that the human review queue itself is the binding constraint — the central thesis of Osmani's own 'Orchestration Tax is You' piece. Pattern 2's elegant in-place pause optimizes the agent side of the handoff while the human side scales linearly with agent count.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Read Osmani's 'Orchestration Tax is You' alongside this article — same author, opposite end of the telescope. Together they expose the gap: 'pause in place' is necessary but not sufficient; without batching, prioritization, and judgement-content sorting, the agent fleet just queues faster in front of the human bottleneck.
• incompleteMemory drift is named but not operationally addressed. Governance prevents unauthorized writes; it does not detect agents whose accumulated long-term memory is subtly warping their reasoning. The post stops at IAM-for-memory; it does not propose drift detection, periodic memory audits, or rollback mechanisms — and gives no guidance on memory garbage collection over multi-week timescales.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Karpathy's 'LLM knowledge bases' extraction (in this library) and Karpathy's 'kb-tool built' piece for the orthogonal view that memory is a tool with editable artifacts, not a black-box store; revisit Bainbridge/Reed for why 'silently changing behavior' is the failure mode automation literature has studied for forty years.
• incompleteFramework-neutrality is asserted in form (the patterns) but undermined in substance. The code uses google.adk; the only named runtime is Google Cloud Agent Runtime; the CTA is the Gemini Enterprise Agent Platform; A2A is Google-backed; the seven-day persistence number is a vendor capability claim. A reader trying to implement these patterns on LangGraph, the Anthropic SDK, OpenAI Assistants, Mastra, or a homegrown stack has to translate every prescription — and several (notably 'zero-compute pause' and 'sub-second cold start') are runtime-dependent guarantees, not just design choices.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Read 'Anthropic's three-agent harness' and 'Anthropic harness design for long-running application development' for how the same problem space looks from the SDK-and-harness perspective rather than the managed-runtime perspective; read 'Block Goose' and 'OpenClaw setup' for OSS-stack equivalents.
• uninformedThe centralized governance layer is presented as an unalloyed good. No mention of the centralization risk: a policy engine in the hot path of every memory and tool access is both a high-availability requirement (downtime stalls the entire agent fleet) and a high-value attack surface (compromise = read/write to every memory bank). The post inherits microservices-governance vocabulary without inheriting microservices-governance failure modes.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Schneier and the supply-chain attack extractions in this library (CNCF Kusari, OpenClaw malicious skills) for the adversarial framing; classic site-reliability literature on policy-engine SPoFs.
• incompleteThe diagnostic question ('what is the longest uninterrupted unit of work?') is only directional. It does not help a team decide whether a 6-hour workflow is better as one long-running agent or as four 90-minute agents handing off through a queue. The 'compose-or-decompose' question is the real architectural choice and is unanswered.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Kniberg's 'Multi-agent workflows' and 'Anthropic harness design' for the decomposition-vs-persistence tradeoff worked out in opposing directions.
• illogicalThe competitive-advantage claim — 'companies building stateless agents today will be refactoring in twelve months' — is offered as if self-evident but rests on the very premise the article is selling: that multi-day workflows are the workloads that matter. For organizations whose agentic workloads are genuinely bounded (single-session research, short bursts of tool use), the refactoring prediction does not follow.
  The Production Gap: 5 Patterns for Building Long-Running AI Agents — read next: Treat the closing prediction as marketing prose; the diagnostic question two paragraphs earlier is the honest version.
• paywall truncationPrinciples 3-5 (expert loops before administrative layers; organize around outcomes not handoffs; install evaluation/permissions/review from the start) are behind a paywall. The analysis is necessarily incomplete.
  #3: How to Build an AI-Native Startup from Day One — read next: Upgrade to Turing Post premium or find coverage of the full article elsewhere.
• missing evidenceThe McKinsey 2025 survey is cited for the claim that workflow redesign drives EBIT impact, but no link, sample size, or effect size is given. The leap from enterprise survey data to startup prescriptions is not justified.
  #3: How to Build an AI-Native Startup from Day One — read next: Look up the actual McKinsey 2025 generative AI survey to assess whether the findings support startup-specific conclusions.
• unexamined assumptionThe article assumes the documentation overhead of machine-legibility is worth it for startups, but early-stage startups are notoriously resource-constrained. No cost-benefit framework is offered for deciding what to externalize and what to leave tacit.
  #3: How to Build an AI-Native Startup from Day One — read next: Look for empirical work on documentation burden in small teams, or case studies of AI-native startups that quantify the overhead.
• unexamined assumptionThe article treats 'flatter organizational structures' as a natural and desirable consequence of cheaper intelligence, without examining whether this prediction holds or whether flattening carries risks (e.g., loss of mentorship, decision overload on fewer people).
  #3: How to Build an AI-Native Startup from Day One — read next: Research on organizational delayering and its effects on decision quality and employee development.
• conceptual gapThe framing 'the organization itself becomes part of the product surface' is evocative but underdeveloped. It is unclear whether this means organizational design is visible to customers, or is a competitive moat, or something else.
  #3: How to Build an AI-Native Startup from Day One — read next: Look for related work on organizational design as competitive advantage (e.g., Zenger on theory-based strategy, or Jacobides on architectural advantage).
• incompleteOntology maintenance and curation cost is entirely unaddressed. The post treats the ontology as a layer that 'supplies' semantic memory, but says nothing about who authors the shared formal vocabulary, how it is governed as many notes link into it, or that this is scarce knowledge-engineering labour. If maintaining the ontology is the hard part, the bottleneck moves from markdown convenience to specialist curation — undercutting the linked 'simplest thing that could possibly work' framing.
  Tony Seale's Post — read next: Read the historical adoption record of formal ontologies and the Semantic Web (OWL/RDF, schema.org governance) for why ontology upkeep, not authoring notes, is the recurring failure point. Compare with this repo's own knowledge/ layer, which runs the same episodic+semantic split but deliberately diverges from Vault-LD: it keeps the ontology in an external, human-curated registry (concepts.yaml) rather than inline YAML-LD, and uses positional refs (slug#p3) rather than linked-data URIs. That a working instance of the pattern chose an external registry is direct evidence that inline 'one file, each layer optional' is not the only viable architecture — and that someone still has to own the semantic layer by hand.
• incompleteThe inference payoff is asserted but never demonstrated. 'Project into a graph, where inference, validation, query and integration are already waiting' names four benefits without a single worked example of what an agent can now answer, or what a validation constraint would catch, that a plain markdown wiki could not. The most consequential claim in the piece — that the ontology overhead buys real capability — is left as a promise.
  Tony Seale's Post — read next: Seek the linked Vault-LD spec for a concrete example, then pressure-test it against the counter-claim in the corpus (Karpathy: an LLM-maintained markdown index is sufficient for complex Q&A at ~100-article scale without any graph). Ask specifically: what query, inference or validation justifies the ontology, and at what vault size does flat markdown actually break?
• incompleteThe net-positive assumption skips the sync/drift ledger. Keeping typed fields and ontology links in agreement with prose as the prose evolves is ongoing cost, and 'each layer optional until you need it' in practice tends to mean 'skipped' — which leaves the graph sparse exactly where semantics were supposed to add value, and leaves the annotated minority prone to silent divergence from the text it describes.
  Tony Seale's Post — read next: Read on documentation drift / doc-rot and on the divergence between described and enforced structure over time (cf. the static-sensors debate on markdown guides vs enforcement rules). Consider whether YAML-LD frontmatter has the same rot dynamics as any duplicated metadata, and what would keep it honest.
• incompleteThe JSON-LD-on-HTML analogy imports an inevitability it has not earned. The web's structured-data adoption was driven by a concrete incentive — search engines reward JSON-LD with ranking — and is itself uneven and gamed. The post identifies no equivalent forcing function for private or team vaults, yet treats 'the same move' as a settled outcome rather than a hopeful one.
  Tony Seale's Post — read next: Examine schema.org adoption data and its SEO dynamics — how much of the web's 'knowledge graph' is genuine semantics versus ranking-driven boilerplate — and ask what a vault-world analogue of search-ranking pressure would even be. If none exists, the adoption story needs a different engine than the analogy provides.
• incompleteNo treatment of the trustworthiness of the memory itself. Agent memory is largely LLM-written; a hallucinated or drifting note, once given typed fields and ontology links, inherits machine-queryable false authority. The semantic layer is presented purely as validation upside, with no acknowledgement that it propagates bad facts as readily as it structures good ones, or that memory poisoning becomes more consequential once memory is formally queried.
  Tony Seale's Post — read next: Read on agent-memory poisoning and knowledge-base trust (how errors propagate through an LLM-maintained base over time). Distinguish validation that catches contradictions from structure that merely launders unverified claims into confident graph facts.