# a2a Published articles for a2a. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Article: Agentic AI Architecture: Current Challenges and Future Opportunities DevFeed: [Article: Agentic AI Architecture: Current Challenges and Future Opportunities]() Original publisher: [Read original article]() Author: Rafał Gancarz Published: 2026-11-09T10:52:00Z Content type: article Language: en Sources: [InfoQ]() Topics: [AI Architecture](), [Agentic AI](), [software-architecture](), [Multi Agent Systems](), [AI Integration Strategies](), [LLM security](), [observability](), [Cloud Architecture](), [decoupling](), [agent to agent communication](), [A2A protocol](), [Artificial Intelligence]() Tags: [a2a](), [adoption](), [agentic](), [agentic-ai](), [agentic-ai-architecture](), [agentic-ai-architecture-challenges-opportunities](), [agents](), [ai](), [ai-agents](), [ai-architecture](), [ai-coding](), [ai-development](), [architecture](), [architecture-design](), [architectures](), [article](), [artificial-intelligence](), [bounded](), [bounded-context](), [challenges](), [cloud](), [cloud-native](), [code-generation](), [components](), [context](), [context-engineering](), [future](), [large-language-models](), [model-context-protocol-mcp](), [retrieval-augmented-generation]() ### AI overview Agentic AI architecture builds on microservices and cloud-native systems, adding agents that use context, memory, and protocols such as MCP for tools and A2A for agent interoperability. The excerpt highlights bounded contexts to limit agents' access to local data and services, and says coordination strategies must be tested for each task: centralized orchestration performed better for financial reasoning, while decentralized coordination suited web navigation. It identifies risks including prompt injection, poisoned tool outputs, and model-provider data handling; proposed safeguards include capability-scoped permissions and task-scoped credentials. Because agent behavior is nondeterministic, the text recommends structured decision logs, quality, latency and spend metrics, tracing, alerts, and runbooks. Adoption is expected to be gradual, with existing architectures coexisting and platforms absorbing common agent components. ### Source excerpt Agentic AI architecture extends microservices and cloud-native architectures with AI agents that work with context, memory, and protocols such as MCP and A2A. The article covers bounded-context integration, task-dependent coordination strategies, new security risks, and observability needs. It expects gradual adoption alongside existing architectures, with platforms absorbing common components. By Rafał Gancarz ## Aegis OS: A Transactional Multi-Tenant Operating System Runtime for Eliminating Authorization Fatigue in Autonomous Coding Agents DevFeed: [Aegis OS: A Transactional Multi-Tenant Operating System Runtime for Eliminating Authorization Fatigue in Autonomous Coding Agents]() Original publisher: [Read original article]() Author: Hui Zhao (Heurion Research) Published: 2026-11-09T05:00:00Z Content type: article Language: en Sources: [arXiv: Cryptography and Security](), [arXiv: Software Engineering]() Topics: [Multi Agent Systems](), [Authorization](), [Kernel](), [Agent Harness](), [A2A protocol](), [agentic workflows](), [tenant data protection](), [google-antigravity]() Tags: [a2a](), [a2a-protocol](), [agent2agent](), [agents](), [anthropic](), [anthropic-claude](), [antigravity](), [api](), [arxiv](), [attack](), [attacks](), [authorization](), [autonomous-coding](), [autonomy](), [boundary](), [bridge](), [coding-agents](), [cs-cr](), [cs-ma](), [cs-os](), [cs-se](), [operating-system](), [os](), [runtime]() ### AI overview Aegis OS moves authorization from individual tool calls to transactional workspace boundaries to reduce prompts while isolating autonomous coding agents. Its Rust runtime uses macOS Seatbelt or Linux Bubblewrap sandboxes, copy-on-write shadow workspaces, an identity-pinned HTTP egress proxy for scoped secret injection and outbound DLP, and an A2A bus with content-addressable storage. The abstract reports 94.19%-99.88% fewer prompts in 1,500 controlled calls and 90.7%-97.9% fewer across 28,087 calls in 52 sessions; attack success fell from 100% to 0% across 80 attacks on both platforms. It also reports 6.3 ms APFS and 15.6 ms btrfs cloning for a 1,000-file repository and detection of all 10 tested merge conflicts. These are claims from the supplied abstract; methods and broader limitations are not described. ### Source excerpt arXiv:2611.08516v1 Announce Type: cross Abstract: Autonomous coding agents such as Google Antigravity (agy), Anthropic Claude Code (claude), and OpenAI Codex CLI (codex) execute multi-step software engineering workflows on workstations and cloud hosts. Existing agent environments face a Security-Autonomy Dilemma: operators must choose between per-action confirmation prompts, which interrupt workflows on 45%-57% of tool calls and induce authorization fatigue, or unconfined execution (--yolo / --dangerously-skip-permissions), which exposes host files, SSH/cloud credentials, and API tokens to prompt injection and hallucination risks. Furthermore, concurrent agents editing a shared working tree clobber one another's changes, while passing large artifacts inline through LLM context windows incurs high token overhead. We present Aegis OS (aegis-os), a transactional, multi-tenant Agent Operating System Runtime in Rust exposed via the Model Context Protocol (MCP) and Google Agent2Agent (A2A) protocol. Aegis OS shifts the authorization boundary from individual tool calls to transactional workspace boundaries. Each agent runs inside a kernel-enforced OS sandbox (macOS Seatbelt and Linux Bubblewrap with default-deny --tmpfs $HOME isolation and a Unix-socket egress bridge) backed by a Copy-on-Write (CoW) shadow workspace (APFS clonefile; single-open Linux FICLONE reflinks), an identity-pinned HTTP Egress Proxy with L7 method/path-scoped secret injection and outbound DLP, and an A2A IPC bus with Content-Addressable Storage (CAS). Across 1,500 controlled calls and 28,087 real calls across 52 coding-agent sessions, Aegis OS reduces prompts by 94.19%-99.88% (controlled) and 90.7%-97.9% (real sessions, 1.12% IPR), lowers attack success rate across 80 attacks in eight categories from 100.0% to 0.0% on macOS and Linux, clones 1,000-file (78.1 MB) repos in 6.3 ms on APFS and 15.6 ms on btrfs, and catches 10/10 syntactic and semantic merge conflicts. ## IRIS: Intelligent Random Access with Integrated Shared Learning for Decentralized LEO Direct-to-Satellite Uplinks DevFeed: [IRIS: Intelligent Random Access with Integrated Shared Learning for Decentralized LEO Direct-to-Satellite Uplinks]() Original publisher: [Read original article]() Author: Abdullah Al Noman, Gaurav Singh, Rameez Ahmed, Debashri Roy Published: 2026-11-06T05:00:00Z Content type: article Language: en Sources: [arXiv: Networking]() Topics: [AI Networking](), [openenv]() Tags: [a2a](), [ablation](), [agent](), [arxiv](), [channel](), [context](), [coverage](), [cs-ni](), [d2s](), [decentralized](), [deep](), [delay](), [delta](), [deployments](), [efficiency](), [evaluations](), [fairness](), [learning](), [leo](), [random](), [satellite]() ### AI overview IRIS addresses grant-free LEO satellite uplink contention without real-time centralized scheduling. In A2A-IRIS, each UE uses a shared binary transmission policy informed by local traffic and channel data plus compact peer states exchanged over sidelink; Vanilla-IRIS uses local information only. In the evaluated rural and suburban deployments, A2A-IRIS reached 2.1579 and 5.4478 Mbps (99.9% and 96.1% of scenario-specific upper bounds), improving throughput over Vanilla-IRIS by 40.8% and 325.0%. It also outperformed centralized schedulers with one- or two-epoch delay by about 51-130%. The abstract reports improved fairness, coverage, and transmission efficiency, moderate DQN inference overhead, and sustained performance across the evaluated active-UE load range. Results are from the described simulations using TLE/SGP4 trajectories, with a Walker-Delta constellation as fallback. ### Source excerpt arXiv:2611.07201v1 Announce Type: new Abstract: Grant-free uplink access in low-Earth-orbit (LEO) non-terrestrial networks (NTNs) poses a coordination challenge when multiple UEs share a satellite channel without real-time centralized scheduling under long propagation delays and time-varying channels. Conventional random access does not exploit peer context, leading to collisions and inefficient channel use as contention increases. To address this problem, we propose IRIS, a multi-agent reinforcement learning framework for decentralized grant-free direct-to-satellite (D2S) uplink access, with A2A-IRIS as its sidelink-assisted Agent-to-Agent (A2A) realization. Each UE executes a shared binary transmission policy using local traffic/channel information augmented by compact peer states exchanged over UE-to-UE sidelink, while Vanilla-IRIS serves as a local-only ablation. Evaluations in rural and suburban LEO D2S deployments use TLE-based trajectories propagated using the Simplified General Perturbations 4 (SGP4), with a Walker-Delta constellation as fallback. A2A-IRIS achieves 2.1579 and 5.4478 Mbps, corresponding to 99.9% and 96.1% of the respective scenario-specific upper bounds. Relative to Vanilla-IRIS, throughput improves by 40.8% and 325.0%, with collision rates of 0.0000 and 0.0433, while one- and two-epoch delayed centralized schedulers are outperformed by approximately 51--130%. A2A-IRIS also improves fairness, service coverage, and transmission efficiency with moderate Deep Q-Network (DQN) inference overhead. Active-UE load scalability results further show sustained performance over the evaluated load range. These results demonstrate the effectiveness of sidelink-assisted A2A coordination for decentralized LEO D2S uplink access under propagation delay and delayed channel feedback. ## The Two-Ledger Model: Transaction-Grain Cost Accounting for Multi-Agent AI Systems Across Clouds, Models, and Systems of Record DevFeed: [The Two-Ledger Model: Transaction-Grain Cost Accounting for Multi-Agent AI Systems Across Clouds, Models, and Systems of Record]() Original publisher: [Read original article]() Author: Vivek Acharya Published: 2026-11-06T05:00:00Z Content type: article Language: en Sources: [arXiv: Artificial Intelligence](), [arXiv: Distributed Computing]() Topics: [Multi Agent Systems](), [ai observability](), [finops](), [LLM observability]() Tags: [a2a](), [accounting](), [billing](), [correlation](), [cs-ai](), [cs-dc](), [cs-ma](), [focus](), [large-language-models-llms](), [multi-agent](), [opentelemetry](), [probabilistic](), [rate-card](), [reconciliation](), [shadow-ai](), [simulation]() ### AI overview The Two-Ledger Model aims to attribute AI costs to individual business transactions, which settlement-grain billing cannot do because providers do not see enterprise transaction boundaries. It joins a FOCUS-conformant settlement ledger with an invocation-grain attribution ledger built on OpenTelemetry GenAI telemetry. A layered correlation spine uses trace context, A2A/MCP metadata, business keys, then probabilistic matching, recording its method and confidence; a versioned rate card prices usage, and invoice reconciliation uses unexplained residuals to identify shadow AI. In a simulation, cost coverage stayed above 99% as trace propagation fell to zero, residuals recovered planted unmetered spend within 0.24 percentage points while flagging billing errors, and mid-flight gating reduced p99 transaction cost by up to 61% with a 2-4% false-pause rate. The authors propose standardizing the attribution ledger as an invocation-grain FOCUS profile. ### Source excerpt arXiv:2611.06989v1 Announce Type: new Abstract: Enterprises run business transactions through multi-agent AI systems spanning clouds, large language models (LLMs), orchestration harnesses, and systems of record. Finance receives AI cost only at settlement grain, aggregated by SKU and charge period. The business question (what did this order, claim, or case cost in AI?) cannot be answered from billing data, because providers never see enterprise transaction boundaries. The FinOps Open Cost and Usage Specification (FOCUS) gives billing data one schema across providers but remains settlement-grain even as it adds AI token and requester attribution. We formalize this grain mismatch, derive seven requirements, and propose the Two-Ledger Model: a settlement ledger of FOCUS-conformant billing data joined to an attribution ledger of invocation-grain usage records built on OpenTelemetry GenAI telemetry. A layered correlation spine (trace context, A2A/MCP metadata, business-key correlation, probabilistic matching) assigns each record to its business transaction with recorded method and confidence; a versioned rate card prices usage in near real time; period reconciliation ties both ledgers to the invoice, and the unexplained residual identifies shadow AI. Costs are reported per order, claim, or outcome with agentic cost metrics. A simulation with known ground truth shows the spine sustaining cost coverage above 99% as trace propagation falls to zero, the reconciliation residual recovering planted unmetered spend within 0.24 percentage points while flagging provider billing errors, and mid-flight gating cutting p99 transaction cost by up to 61% at a 2-4% false-pause rate. We propose the attribution ledger as an invocation-grain FOCUS profile for standardization. ## How U Mobile built agentic telco operations with Amazon Bedrock AgentCore DevFeed: [How U Mobile built agentic telco operations with Amazon Bedrock AgentCore]() Original publisher: [Read original article]() Author: Jin Tiong Lim Published: 2026-11-04T16:23:33Z Content type: article Language: en Sources: [Artificial Intelligence]() Topics: [Amazon Bedrock AgentCore](), [Agentic AI](), [Amazon Bedrock Knowledge Bases](), [Kiro](), [CI/CD](), [Amazon Web Services](), [5G]() Tags: [5g](), [a2a](), [advanced-300](), [agentcore](), [agentic](), [agentic-ai](), [ai](), [ai-operations](), [amazon-bedrock](), [amazon-bedrock-agentcore](), [autonomous](), [customer-solutions](), [launch](), [malaysia](), [mobile](), [network](), [operational](), [operations](), [platform](), [production](), [telco](), [tickets]() ### AI overview U Mobile's AiDaH platform uses Amazon Bedrock AgentCore to coordinate specialist agents across telco systems, reducing manual investigation and proposing remediation for staff review. Its layered design routes requests through low-cost deterministic matching, a lightweight classifier, or a full orchestrator; MCP gateways connect backend systems, while A2A enables cross-domain delegation. Identity checks, six-tier role-based access, data masking, guardrails, private networking, and audit logging underpin access. Staff confirm actions affecting live subscriber accounts. U Mobile reports more than 150 operational scenarios across six divisions and ticket reductions of up to 84.5% in measured categories. The account describes a progression from a two-agent pilot to production use, with autonomous resolution remaining a future goal. ### Source excerpt U Mobile, Malaysia's newest 5G network provider, built AiDaH, an agentic AI operations platform on Amazon Bedrock AgentCore that moves beyond AI assistance to autonomous action across telco operations. Nine months after production launch, AiDaH handles over 150 operational scenarios across six divisions, cutting trouble tickets by up to 84.5%. ## The next chapter of Redis Iris: what agents need to work in the real world DevFeed: [The next chapter of Redis Iris: what agents need to work in the real world]() Original publisher: [Read original article]() Author: Simba Khadder Published: 2026-11-04T00:00:00Z Content type: release Language: en Sources: [Redis Blog](), [Redis Blog]() Topics: [AI Context Management](), [agent to agent communication](), [AI for customer service automation](), [AI Infrastructure](), [agent orchestration](), [Redis]() Tags: [2026](), [a2a](), [adaptive](), [agent](), [agent-memory](), [agent-mesh](), [agents](), [agents-in-production](), [ai](), [ai-agent](), [ai-stack](), [audit](), [audit-trail](), [authorization](), [beta](), [built-in](), [cache](), [capabilities](), [customer-support](), [redis](), [tech]() ### AI overview Redis Iris is presented as a context and runtime layer intended to make AI agents more reliable in production by giving them relevant context quickly, retaining useful history, and reusing established procedures. Its six capabilities include intent classification for routing; Agent Playbooks that reuse stable answers or procedures and improve through a learning loop; Agent Memory that builds, organizes, audits, and can forget sensitive or irrelevant information; and Context Gateway, which connects context sources while handling identity and authorization. Lens (beta) traces outcomes to routes, playbooks, memories, and source sessions, with task, token, and latency visibility. Agent Mesh (beta) provides durable SSE streams and A2A communication for handoffs. The article illustrates these components in a hypothetical account-charge support interaction. Capabilities can be used together or independently; claims of customer results are vendor-reported. ### Source excerpt The other day, I was chatting with a customer support AI agent dealing with a cancelled flight. The experience was terrible. You could tell the agent realistically only had a few functions, and this was clearly not one of them. I'm sure when the devel... ## Agents Are Software: Introducing the Next Chapter of Redis Iris DevFeed: [Agents Are Software: Introducing the Next Chapter of Redis Iris]() Original publisher: [Read original article]() Author: Rowan Trollope Published: 2026-11-04T00:00:00Z Content type: release Language: en Sources: [Redis Blog](), [Redis Blog]() Topics: [Multi Agent Systems](), [Redis](), [agent to agent communication](), [AI Integration Strategies]() Tags: [a2a](), [adaptive](), [agent](), [agent-memory](), [agent-mesh](), [agent-skill](), [agents](), [ai](), [ai-agents](), [ai-models](), [ai-stack](), [announcements](), [automatic](), [behavior](), [beta](), [context](), [enterprise](), [infrastructure](), [production](), [redis](), [software](), [tech]() ### AI overview Redis Iris presents agents as software needing memory, context, routing, communication, and live application data, and offers six capabilities in one runtime to support them. Intent Router directs requests by meaning; Agent Playbooks reuse stable answers or rerun procedures when current data is needed; Agent Memory organizes and audits memories built from user actions and documents, with controls to forget data such as PII; Context Gateway provides governed access to connected sources and caches useful tool choices; Lens (beta) traces outcomes and exposes success, token use, and latency; Agent Mesh (beta) supports agent handoffs over streams with buffering and reconnection. Redis says these capabilities can be combined or used independently to reduce custom integrations and token costs. The article describes Iris as launched in May 2026 and reports customers using it in production, but provides no independent performance evidence. ### Source excerpt The next chapter of Redis Iris is here AI models and infrastructure are now good enough for the enterprise, yet few teams are seeing repeatable, production-level success with agents. This is because agents lack the right context, at the right time, r... ## Towards a Trustworthy and Governable Internet of Agentics: An Architectural Perspective on Protocols, Systems, and Services DevFeed: [Towards a Trustworthy and Governable Internet of Agentics: An Architectural Perspective on Protocols, Systems, and Services]() Original publisher: [Read original article]() Author: Haoyi Xiong, Yi Liu, Jiang Bian, Peng Diao, Bin Zhu, Tingting Hu, Yi Wang, Sumi Helal Published: 2026-11-03T05:00:00Z Content type: article Language: en Sources: [arXiv: Artificial Intelligence](), [arXiv: Distributed Computing]() Topics: [Multi Agent Systems](), [agent to agent communication](), [AI Architecture](), [software-architecture](), [Service fabric]() Tags: [a2a](), [abstractions](), [agent](), [agent-workflows](), [agentic](), [agentic-ai](), [agentic-ai-foundation](), [agentic-systems](), [agents](), [ai](), [architectures](), [autonomy](), [capabilities](), [composition](), [control](), [cs-ai](), [cs-dc](), [internet](), [perspective](), [protocols](), [services](), [systems]() ### AI overview The paper frames dependable agent deployment as an interoperability and governance problem: agents need to work across frameworks, runtimes, data boundaries, and organizational controls. It presents a three-layer progression from fragmented ecosystems to interoperable agents and then trustworthy, governable autonomy. Its protocol survey covers MCP for agent-tool interaction, A2A for agent coordination, procedural manifests, and discovery, transport, and trust mechanisms such as AGNTCY and SLIM. It also reviews deployment abstractions including orchestration, gateways, registries, runtime control loops, and hardware-aware inference. Finally, it recasts service-computing concerns such as discovery, composition, governance, pricing, and trust around cognitive capabilities rather than deterministic functions. ### Source excerpt arXiv:2611.03066v1 Announce Type: cross Abstract: Large language model applications are increasingly being organized as tool-using and multi-agent workflows rather than as isolated chat interfaces. This perspective paper examines the architectural problem that follows from that shift: agents may reason, invoke tools, and delegate work, but dependable deployment still requires interoperability across frameworks, runtimes, data boundaries, and organizational control domains. We study this problem through the lens of the \emph{Internet of Agentics} (IoA), an emerging service-computing view in which heterogeneous agents are treated as governable service participants rather than only as stand-alone model endpoints. The paper organizes the landscape as a three-layer progression: from today's fragmented agent ecosystem, to interoperable agents, and ultimately to trustworthy and governable autonomy. First, it examines the protocol stack centered on the Agentic AI Foundation, including MCP for agent--tool interaction; A2A for agent--agent coordination; AGENTS.md and Skills-style procedural manifests; and discovery, transport, and trust mechanisms such as AGNTCY and SLIM. Second, it reviews the systems abstractions that make agents deployable as service components, including logical agent architectures, orchestration patterns, gateways, registries, runtime control loops, and hardware-aware inference infrastructure. Third, it situates these developments within services computing, arguing that agentic systems reinterpret classical concerns from SOA and microservices---discovery, composition, governance, pricing, and trust---at the level of cognitive capabilities rather than deterministic functions. ## Why Other Requests Change Your LLM's Output DevFeed: [Why Other Requests Change Your LLM's Output]() Original publisher: [Read original article]() Author: Avi Chawla Published: 2026-10-31T20:21:59Z Content type: article Language: en Sources: [Daily Dose of Data Science]() Topics: [Large Language Model](), [Agent Harness](), [LLM optimization](), [llm-reasoning](), [llamaindex](), [LLM observability]() Tags: [a2a](), [ag-ui](), [agent](), [agent-harness](), [agent-tasks](), [alibaba](), [api](), [arena](), [artifacts](), [attention](), [backend](), [batch](), [batching](), [benchmark](), [benchmarking](), [benchmarks](), [harness](), [harness-engineering](), [llm](), [update]() ### AI overview Identical prompts can produce different outputs at temperature 0 because GPU kernels change the order of floating-point reductions according to batch size; near-tied token scores can then select different next tokens, causing completions to diverge. The forward pass remains repeatable for an identical batch, but production continuous batching changes batch composition across decoding steps. Batch-invariant kernels use a fixed reduction order to make outputs independent of batch composition. Thinking Machines Lab reports that this made all 1,000 sampled Qwen3-235B completions identical. The tradeoff is lower throughput: SGLang's cited benchmarks show typical slowdowns of 25-45%; vLLM's option is in beta, and DeepSeek's DeepInfer option supports NVIDIA GPUs only. For reproducible evaluations or RL rollouts, the text recommends enabling the relevant engine flag and treating batch composition as part of the experimental setup. ### Source excerpt + an update on Harness Engineering 2.0. ## Java Weekly, Issue 669 DevFeed: [Java Weekly, Issue 669]() Original publisher: [Read original article]() Author: baeldung Published: 2026-10-30T16:16:14Z Content type: news Language: en Sources: [Baeldung]() Topics: [Java](), [Spring Framework](), [Security](), [openjdk](), [Quarkus](), [ai code review](), [TornadoVM](), [IntelliJ IDEA](), [Hibernate]() Tags: [2](), [3](), [a2a](), [accelerate](), [agent](), [agentic](), [agents](), [ai](), [ai-agents](), [ai-code](), [ai-development](), [first](), [issue](), [java](), [no-ads](), [no-after-post](), [no-before-post](), [no-optins](), [post](), [releases](), [security](), [solid](), [upgrades](), [weekly](), [weekly-review](), [weekly-review-no-ads-no-after-post-no-before-post-no-optins]() ### AI overview The issue highlights a practical guide to upgrading from Java 21 to 25, with reproducible examples and a migration checklist. It also points to work on ontology-driven observability at Netflix, arguing that a shared model of systems can help incident investigation. Much of the release roundup emphasizes security updates, including a call to update OWASP Java Security Libraries and version announcements for Quarkus, Micronaut, Helidon, Spring Security, and other Java projects. Other selected topics include JVM reflection and code generation, JDK 28 proposals, Spring AI, and Java GPU computing. This is a newsletter excerpt listing and briefly characterizing selected links, not a detailed account of the linked articles. ### Source excerpt Java 21 to 25 upgrades and lots of solid security releases. As expected after the weeks we've had :) The post Java Weekly, Issue 669 first appeared on Baeldung. ## The Coordination Tax and the Heterogeneity Dividend: Break-Even Conditions for Multi-Agent LLM Pipelines DevFeed: [The Coordination Tax and the Heterogeneity Dividend: Break-Even Conditions for Multi-Agent LLM Pipelines]() Original publisher: [Read original article]() Author: Andreas Zettl, Diego Gosmar Published: 2026-10-30T04:00:00Z Content type: article Language: en Sources: [arXiv: Artificial Intelligence]() Topics: [Multi Agent Systems](), [agent to agent communication](), [llm-reasoning](), [Large Language Model]() Tags: [a2a](), [abstract](), [agent](), [call](), [choice](), [claude](), [claude-opus-5-5](), [cost](), [costs](), [cs-ai](), [cs-ma](), [dividend](), [forecast](), [haiku](), [half](), [humaneval](), [llm](), [model](), [moving](), [multi-agent](), [pipelines](), [tax]() ### AI overview The study models when a multi-agent pipeline's coordination tax--decomposition overhead plus protocol handoffs--can be offset by routing roles to cheaper models, and tests the model with OFP on 135 HumanEval and ClassEval tasks across 2,430 runs. OFP adds 7.2 ms per handoff (0.11% of pipeline time). On these tasks, a planner-coder-reviewer pipeline using the strong model costs 3.22x as much and takes 3.24x as long as one strong call without solving more tasks. Assigning planner and reviewer to the cheaper model cuts pipeline cost to 0.39x, but pass@1 falls by 6.7 points; the pipeline remains slower, less accurate, and dearer than the strong call, partly because cheap roles inflate token volume and the break-even forecast misses by 19%. An oracle choosing between the two single-model calls solves 94.3% of runs at half the strong call's cost per solved task. These findings are limited to the reported benchmarks and models. ### Source excerpt arXiv:2610.37700v1 Announce Type: cross Abstract: Multi-agent LLM pipelines built on interoperability protocols such as the Open Floor Protocol (OFP) or A2A are usually justified on capability grounds, with their runtime cost treated as an overhead of unknown size. Comparing such a pipeline with one model call is underspecified, because a pipeline can give each role a different model. We give a closed-form model that sets the coordination tax (decomposition overhead plus per-handoff protocol cost) against the heterogeneity dividend from routing work to a cheaper model, with a break-even threshold and a feasibility bound, $\alpha < 1/r$, and measure every term, with OFP as the protocol under test, on 135 HumanEval and ClassEval tasks in 2430 runs of six architectures with Claude Opus 5.5 and Haiku 5.5. The protocol adds 7.2 ms per handoff, 0.11% of pipeline wall time. Decomposition does not pay on these tasks: a planner-coder-reviewer pipeline costs 3.22x as much as a single strong call, takes 3.24x as long, and solves no more tasks. Moving planner and reviewer to the cheap model cuts the pipeline's cost to 0.39x but changes pass@1 by -6.7 points, leaving it dearer, slower and less accurate than the single call, and the break-even forecast misses by -19% because the cheap roles inflate token volume. The saving lies in choosing a model per task instead: an oracle choice between the two single calls solves 94.3% of runs at half the strong call's cost per solved task. ## LiteLLM or Opencontroller: which one should govern your AI agents? DevFeed: [LiteLLM or Opencontroller: which one should govern your AI agents?]() Original publisher: [Read original article]() Author: Lyzr Team Published: 2026-10-29T10:20:54Z Content type: comparison Language: en Sources: [Lyzr.ai]() Topics: [litellm](), [control-plane](), [AI Infrastructure](), [shadow AI]() Tags: [a2a](), [admin-roles](), [agent-authorization](), [agent-gateway](), [agent-identity](), [agent-sprawl](), [ai-agent-governance](), [ai-agents](), [ai-gateway](), [air-gapped](), [api-keys](), [audit-logs](), [authentication](), [budget](), [ciso](), [cloud](), [clusters](), [control-plane](), [litellm](), [openai]() ### AI overview LiteLLM routes model, MCP and agent traffic through a shared gateway, providing an OpenAI-style API, team keys, budgets, fallback and usage tracking for registered resources. Its inventory cannot cover agents that bypass the gateway, and shared keys may obscure which agent made a call. Lyzr Opencontroller is presented as a broader control plane: it scans for agents across environments, assigns each an identity and owner, gates releases, and checks policy and budget before calls. Both can route traffic and block on budgets or guardrails; the source distinguishes Opencontroller by discovery and per-agent governance. It describes LiteLLM's core as MIT-licensed and free to self-host, with listed enterprise features paid, and says teams can begin Opencontroller adoption with read-only discovery. ### Source excerpt TL;DR A year ago, a platform team put LiteLLM in front of its apps. It was a good call. Thirty-odd services got one OpenAI-style endpoint,... ## Introducing the Microsoft Copilot harness in Foundry Agent Service DevFeed: [Introducing the Microsoft Copilot harness in Foundry Agent Service]() Original publisher: [Read original article]() Author: Jeff Hollan, Viswa Balaji and Anthony Chu Published: 2026-10-28T17:40:56Z Content type: release Language: en Sources: [Microsoft Azure]() Topics: [Agent Harness](), [hosted-agents](), [AI Agent](), [Agent Skills](), [agent orchestration](), [azd](), [Microsoft](), [Visual Studio Code]() Tags: [2026](), [a2a](), [about](), [abstraction](), [accountability](), [actions](), [agent](), [agent-harness](), [agent-service](), [agents](), [ai-agents](), [ai-plus-machine-learning](), [azure](), [copilot](), [first](), [foundry](), [foundry-agent-service](), [harness](), [microsoft](), [microsoft-copilot](), [microsoft-foundry](), [preview](), [public](), [service]() ### AI overview The Microsoft Copilot harness in Foundry Agent Service is in public preview as a managed way to build declaratively defined agents: Microsoft runs the agent loop and sandbox, while developers provide skills, knowledge, supported tools, and configured authentication and approvals. It manages working context and model/tool steps within configured limits; developers can choose a supported Foundry model and author through the portal, azd, or Foundry Toolkit for Visual Studio Code. Hosted agents offer a different level of control: developers bring their framework, loop, middleware, dependencies, and runtime behavior. Their long-running resilience is generally available; Foundry restarts interrupted work with its original input, but application code must save progress and make external actions safe to repeat. During preview, the harness must be selected when creating an agent, cannot be switched later, and its CPU, memory, and idle settings are managed by Foundry. Harness runtime is free before December 1, 2026; model inference and separately billed tools remain chargeable. From that date, sandbox compute and memory have stated consumption rates, subject to regional and agreement pricing ### Source excerpt Today, we're introducing the Microsoft Copilot harness in Foundry Agent Service in public preview. The post Introducing the Microsoft Copilot harness in Foundry Agent Service appeared first on Microsoft Azure Blog. ## Digitate adds AI agents for patch planning, service desks, and SAP operations DevFeed: [Digitate adds AI agents for patch planning, service desks, and SAP operations]() Original publisher: [Read original article]() Author: Industry News Published: 2026-10-28T14:36:59Z Content type: release Language: en Sources: [Help Net Security]() Topics: [AI in IT operations](), [agentic workflows](), [Multi Agent Systems](), [A2A protocol]() Tags: [a2a](), [agent2agent](), [agentic](), [agents](), [ai](), [ai-agents](), [aiops](), [audit](), [build](), [built-in](), [capabilities](), [change](), [context](), [diagnosis](), [digitate](), [industry-news](), [operations](), [patch](), [planning](), [sap](), [service]() ### AI overview ignio Hummingbird adds task-specific agents that carry IT work from diagnosis through approved action and verification, with enterprise approval, change-management and audit controls. Its agents handle failed SAP IDocs, service-desk device issues and risk-aware patch scheduling; enterprises can also build custom agents. Built-in MCP and A2A servers expose ignio capabilities through tools such as Microsoft Teams, Claude and Gemini. Other additions include business-process views linked to application and infrastructure health, and governed security remediation with prioritized vulnerabilities, verified fixes, certificate renewal and continuous compliance. The excerpt describes intended capabilities but gives no performance results or comparative evaluation. ### Source excerpt Digitate has announced ignio Hummingbird, the latest release of its agentic AIOps platform. Hummingbird introduces AI agents that bring operational expertise to specific IT tasks, move from diagnosis through approved action and verification, and operate within enterprise change, approval and audit controls. The release also enables enterprises to build their own IT operations agents and includes built-in Model Context Protocol (MCP) and Agent2Agent (A2A) servers, allowing ignio capabilities to work with the agents, assistants and ... More -> The post Digitate adds AI agents for patch planning, service desks, and SAP operations appeared first on Help Net Security. ## The Envelope Layer: An Underestimated Surface of LLM Agent Defense DevFeed: [The Envelope Layer: An Underestimated Surface of LLM Agent Defense]() Original publisher: [Read original article]() Author: Yuelin Han Published: 2026-10-28T04:00:00Z Content type: article Language: en Sources: [arXiv: Cryptography and Security]() Topics: [LLM security](), [prompt injection]() Tags: [a2a](), [admission](), [agent](), [assembly](), [attack](), [breach](), [context](), [cs-cr](), [defense](), [experiment](), [failure](), [frontend](), [layer](), [llm](), [manipulation](), [measurement](), [memory](), [methodology](), [permissions](), [property](), [surface]() ### AI overview In experiments using the A2A-TIBA attack, strong labels consistently reduced semantic breach rates when envelopes were authentic, while weak labels were not necessarily better than no labels. Forgery weakened strong labels' benefit, with its direction varying across frontends. Memory had a larger effect than label changes: success memories raised breach rates, failure memories lowered them, and most combinations containing both returned to the no-memory baseline. The paper therefore describes the envelope as both an admission channel and a context assembly surface, with its security boundary shaped jointly by label claims, frontend permissions, and historical memory. ### Source excerpt arXiv:2610.37415v1 Announce Type: new Abstract: Prior work framed the envelope layer as the channel through which malicious content enters an agent, and established it as a defense surface independent of the LLM layer and the agent layer; however, that work only tested the envelope layer briefly and did not examine how label strength, envelope authenticity, scaffold differences, or existing memories affect defense effectiveness. Following its GDA Measurement methodology and the A/B/C/D outcome taxonomy, this paper takes the A2A-TIBA attack as the test vehicle, uses the semantic breach rate as the primary indicator with the semantic refusal rate as its complementary reference, and characterizes the security boundary of the envelope layer through a two-by-two factorial experiment and a memory experiment. The results show that: when the envelope is authentic, strong labels consistently reduce the semantic breach rate, whereas weak labels are not necessarily better than an unlabeled baseline; when the envelope can be forged, the benefit of strong labels is weakened and its direction varies across frontends; and memory has a larger effect than any label manipulation: success memory raises the semantic breach rate while failure memory lowers it, and most combinations that contain both experiences return to the no-memory baseline. Accordingly, this paper refines the envelope layer from a single admission channel into two levels, an admission channel plus a context assembly surface, and argues that its security boundary is not a fixed property of labels but a dynamic outcome jointly shaped by label claims, frontend permissions, and historical memory. ## SAP wants Joule to run business workflows, not just answer questions DevFeed: [SAP wants Joule to run business workflows, not just answer questions]() Original publisher: [Read original article]() Author: Taryn Plumb Published: 2026-10-27T08:05:00Z Content type: news Language: en Sources: [CIO]() Topics: [agentic workflows](), [Multi Agent Systems](), [AI Infrastructure](), [control-plane](), [A2A protocol]() Tags: [a2a](), [a2a-protocol](), [agent](), [agent2agent](), [agentic](), [agentic-ai](), [agents](), [ai](), [ai-agents](), [ai-assistants](), [ai-platform](), [apps](), [artificial-intelligence](), [artificial-intelligence-enterprise-applications-erp-systems-sap-vendors-and-providers](), [build](), [building](), [business](), [capabilities](), [edition-us](), [enterprise-applications](), [erp-systems](), [joule](), [language-en](), [run](), [sap](), [storytype-news](), [vendors-and-providers](), [workflows]() ### AI overview SAP is expanding Joule from a conversational assistant into a platform for building and running multi-step business workflows. Joule Studio will integrate natively with Joule Work so users can describe an intent and have the system coordinate agents, apps, and data; workflows can be saved as reusable skills and shared. Agents are intended to connect to external systems through MCP and A2A, while builders gain shared, role-based environments, sandboxes, and offline evaluations. SAP also describes a Knowledge Graph drawing on SAP and non-SAP data, a governed gateway for third-party agents, and an Enterprise AI Gateway that centralizes authentication, policy enforcement, routing, monitoring, and auditing. Joule Work and Studio features are rolling out in phases; general availability for the gateway and new Knowledge Graph capabilities is planned for Q1 2027. The article also reports separate data, RISE with SAP, and SAP-RPT-2.0 announcements. ### Source excerpt SAP says it is ushering in a new era of agentic AI, one where agents don't just learn a business, but help run it. This week at its TechEd conference, the company is announcing new tools in its SAP Business AI Platform that will extend AI agents' capabilities, give them richer, more enterprise-specific data and context, and beef up governance controls so they can be rolled out safely across enterprise workflows. "There used to be a time where AI assistants or interfaces could do a couple queries, and you had to get the query more or less right," SAP chief AI officer Jonathan von Rüden told CIO. "And then if you asked three, four questions, eventually it would say, 'I can't go that far.' Now that constraint isn't really there anymore." New orchestration layer SAP has introduced new capabilities in its AI-driven workspace Joule Work and its AI no-code/pro-code agent building environment, Joule Studio. Joule Studio will now be natively integrated with Joule Work, giving users a single build layer. They will be able to describe their intent, and the system will orchestrate the right agents, apps, and data. Joule Work is built on the SAP Business AI Platform, which provides context, data, and governance. "Effectively, business users get a coding agent into their hands, but they don't know it is one, so they come up with all kinds of very, very interesting use cases," von Rüden said. SAP has put a good deal of R&D effort into graduating from conversations to a generative UI to "step-by-step" replace classic UIs, he noted. "You don't need those anymore, you can have them tailor made per person." A new orchestration layer in Joule Work will support more complex, multi-step workflows. Beyond working across SAP environments, agents will be able to plug into external systems, data, and tools via Modern Context Protocol (MCP) and Agent2Agent (A2A) Protocol. Further, Joule Studio will be more tightly integrated with SAP Business Data Cloud so that builders can access various dat ## A2ABreak: Systematic Security Analysis of the A2A Protocol DevFeed: [A2ABreak: Systematic Security Analysis of the A2A Protocol]() Original publisher: [Read original article]() Author: Alireza Lotfi, Mirza Masfiqur Rahman, Imtiaz Karim, Elisa Bertino Published: 2026-10-27T04:00:00Z Content type: article Language: en Sources: [arXiv: Cryptography and Security](), [arXiv: Software Engineering]() Topics: [A2A protocol](), [Multi Agent Systems](), [Finite-state machine](), [Security]() Tags: [a2a](), [a2a-protocol](), [agent2agent](), [agents](), [ai](), [ai-agents](), [analysis](), [autonomous](), [autonomous-ai-agents](), [communication](), [compliance](), [context](), [credential-harvesting](), [cs-cr](), [cs-se](), [data-exfiltration](), [delegation](), [formal](), [formalized](), [framework](), [llm](), [security]() ### AI overview A2ABreak reports 11 protocol-level vulnerabilities in A2A that a specification-compliant adversary can exploit without implementation flaws. The framework uses LLM-assisted extraction of a verified finite-state machine from the natural-language specification (37 states, 76 transitions, and 929 formalized statements), then applies adversarial verification. Reported examples include cross-client context injection through unprotected context identifiers, credential harvesting after identity loss in delegation chains, and data exfiltration via agents making unattested capability claims. Against manual expert review, it achieves 73.3% precision and 84.6% F1; a zero-shot LLM baseline on the same specification yielded no confirmed findings. These are abstract-level claims; the supplied text does not detail mitigations or individual vulnerability analyses. ### Source excerpt arXiv:2609.10871v3 Announce Type: replace Abstract: The Agent2Agent (A2A) protocol, now governed by the Linux Foundation, is an open standard that enables autonomous AI agents to discover, authenticate with, and delegate tasks to one another across organizational boundaries. Designed to complement the Model Context Protocol (MCP) for tool integration, A2A is rapidly emerging as the horizontal communication layer of the multi-agent ecosystem. Yet the protocol's security has received no systematic analysis. This paper presents A2ABreak, the first rigorous systematic security analysis of the A2A protocol. We introduce a novel framework that utilizes an LLM-assisted extraction of a verified finite-state machine directly from the natural-language specification, producing a unified model of 37 states and 76 transitions from 929 formalized statements, and then systematically reasons over this model to discover protocol-level vulnerabilities through adversarial verification, under a full-compliance assumption. Our analysis uncovers 11 new vulnerabilities, each exploitable by a specification-compliant adversary without requiring any implementation flaw. Among the findings are cross-client context injection through unprotected context identifiers, credential harvesting via multi-hop identity loss in delegation chains, and data exfiltration through rogue agents advertising unattested capability claims. A2ABreak achieves 73.3% precision and 84.6% F1 against manual expert review, while a zero-shot LLM baseline operating over the same specification produces zero confirmed findings, demonstrating that explicit formal grounding is essential for sound protocol security analysis. ## Marc Montez: AI decides, workflows execute DevFeed: [Marc Montez: AI decides, workflows execute]() Original publisher: [Read original article]() Author: Marc Montez Published: 2026-10-23T12:00:00Z Content type: opinion Language: en Sources: [Automate Your Network]() Topics: [agentic workflows](), [workflow automation](), [AI Integration Strategies](), [agent to agent communication]() Tags: [a2a](), [agent](), [agents](), [ai](), [ai-agents](), [audit](), [audit-trail](), [automation](), [control](), [deterministic-workflows](), [execution](), [guardrails](), [itential](), [john-capobianco](), [lumen](), [mcp](), [network](), [partnership](), [reasoning](), [social](), [workflows]() ### AI overview Marc Montez argues that production network automation should pair AI agent reasoning--interpreting intent, correlating signals, and deciding next steps--with deterministic workflows that execute changes predictably and repeatably. He says those workflows provide guardrails, approvals, observability, and an audit trail, aiming for speed while retaining control and trust. He cites work with Itential and says they are exploring MCP and agent-to-agent patterns for production-grade orchestration. ### Source excerpt Marc Montez - LinkedIn - Marc describes the partnership between agent reasoning and deterministic workflows, with approvals, repeatable execution, and visible evidence. ## The Cost of Saying Hello: An Empirical Study of Handshake Overhead in AI Agent Communication Protocols DevFeed: [The Cost of Saying Hello: An Empirical Study of Handshake Overhead in AI Agent Communication Protocols]() Original publisher: [Read original article]() Author: Pranav Varshney Published: 2026-10-23T04:00:00Z Content type: article Language: en Sources: [arXiv: Artificial Intelligence](), [arXiv: Machine Learning]() Topics: [agent to agent communication](), [Multi Agent Systems](), [A2A protocol](), [LLM observability]() Tags: [2025](), [2026](), [a2a](), [acp](), [agent](), [agent-communication](), [agents](), [ai](), [ai-agent](), [ai-agents](), [analysis](), [arxiv](), [benchmark](), [communication](), [context](), [cost](), [cs-ai](), [cs-lg](), [handshake](), [overhead](), [protocols](), [study]() ### AI overview The benchmark finds that handshake round trips dominate startup latency across the tested agent protocols. At an emulated 50 ms RTT, legacy MCP takes three round trips and 230 ms, while A2A takes one and 61 ms. Metadata adds a separate context cost when an LLM reads counterpart capabilities: 24-107 tokens per capability, or 11% of a 200k-token context window for 200 capabilities. MCP's 2026 discover revision reduces the handshake to two round trips, and era pinning eliminates it on warm reconnects. The study used official SDKs and tested cold starts, warm repeats, capability mismatches, and degraded metadata; these results describe the reported benchmark conditions. ### Source excerpt arXiv:2610.30151v1 Announce Type: cross Abstract: Every interaction between AI agents begins with a handshake: the initiating agent must locate its counterpart, learn what it can do, and establish a session before the first useful message can be sent. Surveys of agent communication protocols name handshake overhead as an efficiency criterion, yet none report measurements. This paper presents the first empirical, phase-decomposed benchmark of the handshake in three major agent protocols: MCP (in both its 2025 initialize and 2026 discover eras), A2A, and ACP. Using each protocol's official SDK, we instrument every request for round trips, per-phase latency, wire bytes, and token cost across cold-start, warm-repeat, capability-mismatch, and degraded-metadata scenarios (N=50 per cell, on loopback and under an emulated 50 ms RTT). Round-trip count dominates handshake cost. A legacy MCP handshake takes three round trips and 230 ms at 50 ms RTT; A2A needs one round trip and 61.0 ms. Round trips are not the whole bill: when an LLM reads the counterpart's metadata, handshake cost scales with the counterpart's capability inventory at 24-107 tokens per capability, so a 200-capability counterpart spends 11% of a 200k-token context window before the agent reads its own task. MCP's own 2026 revision cuts its handshake from three round trips to two and, with era pinning, to zero on warm reconnects, protocol evolution that corroborates the cost we measure. We release the full harness, raw data, and analysis at https://github.com/pvarshh/handshake-benchmark. ## Controlled self-healing Amazon EKS Clusters with AWS DevOps Agent and A2A remote agents DevFeed: [Controlled self-healing Amazon EKS Clusters with AWS DevOps Agent and A2A remote agents]() Original publisher: [Read original article]() Author: Sudheer Sangunni Published: 2026-10-22T18:43:59Z Content type: tutorial Language: en Sources: [AWS Cloud Operations Blog]() Topics: [AIOps for Kubernetes](), [Amazon Elastic Kubernetes Service](), [A2A protocol](), [Multi Agent Systems](), [agent to agent communication](), [supervisor agent pattern](), [Amazon Web Services](), [Self-hosted](), [container-networking]() Tags: [a2a](), [agent](), [agents](), [amazon](), [amazon-bedrock-agentcore](), [amazon-eks](), [amazon-elastic-kubernetes-service](), [amazon-elastic-kubernetes-service-amazon-eks](), [application](), [automated](), [aws](), [cloud-operations](), [cluster](), [clusters](), [devops](), [devops-agent](), [eks](), [kubernetes](), [management-tools](), [memory](), [monitoring-and-observability](), [monitoring-observability](), [pod](), [remote](), [self-healing](), [technical-how-to]() ### AI overview The walkthrough makes EKS self-healing conditional on a separate guardrail agent's approval. AWS DevOps Agent orchestrates diagnostics from K8sGPT through a custom Argo CD A2A agent, asks the guardrail agent before each deployment change, then verifies and reports the result. In the example, the guardrail allows doubling the memory limit for an OOMKilled deployment with a Pod Disruption Budget (PDB) and blocks the change for one without. The PDB check is illustrative: PDBs constrain voluntary evictions, not Deployment rolling updates, so organizations should substitute their own change controls. The agents run as cluster pods and are exposed through API Gateway using AWS_IAM and SigV4. The demo registers pod IPs directly, which must be refreshed after pod restarts; the text recommends AWS Load Balancer Controller with TargetGroupBinding for automatic registration. Setup also requires EKS, Argo CD, K8sGPT, specified Bedrock model access, and incurs charges for infrastructure and model use. ### Source excerpt 1. Introduction A pod on your Amazon Elastic Kubernetes Service (Amazon EKS) cluster is restarting on a memory limit. An automated agent spots it, doubles the memory, and syncs the application. On a quiet afternoon that is a tidy self healing story. During a release window, or on a service that is mid rollout, the [...] ## Build an AI agent once and reuse it across teams DevFeed: [Build an AI agent once and reuse it across teams]() Original publisher: [Read original article]() Author: Daniel Takabayashi Published: 2026-10-22T00:00:00Z Content type: article Language: en Sources: [Redpanda]() Topics: [AI Agent](), [Multi Agent Systems](), [agent observability](), [Agent Harness](), [Microsoft Teams]() Tags: [a2a](), [agent](), [agent2agent](), [agent2agent-protocol](), [agentic](), [agents](), [ai](), [ai-agent](), [ai-gateway](), [alert](), [audit](), [build](), [governance](), [hr](), [identity](), [it](), [observability](), [ops](), [reuse](), [teams](), [tutorial]() ### AI overview Redpanda's Agentic Data Plane is presented as a way to build an internal capability agent once and let other teams or event-driven pipelines call it under shared governance. A managed IT Assist agent connects to ServiceNow through Redpanda-hosted MCP tools, keeps credentials in a secret store, authorizes actions as the requesting employee, and applies tool access policies outside the model. A self-managed onboarding orchestrator can discover and call it over A2A while adding Workday and SharePoint agents through an OpenAPI-generated MCP server or a fronted existing MCP server. For operations, Redpanda Connect can send alerts to a triage agent, which composes existing agents and uses a pipeline service identity with narrowly granted permissions. The excerpt also describes per-agent budgets, GitOps management, transcript retention choices, and centralized traces and run records for reviewing delegated work and avoiding unsafe duplicate catalog submissions. It gives a product-specific architecture example; it does not establish comparative results against other platforms. ### Source excerpt Learn how to build an AI agent once and reuse it across IT, HR, and ops teams, with shared governance, identity, and observability. ## Inside NVIDIA Sentry: Secure AI Agents at Runtime DevFeed: [Inside NVIDIA Sentry: Secure AI Agents at Runtime]() Original publisher: [Read original article]() Author: Ofir Arkin Published: 2026-10-21T09:52:16Z Content type: article Language: en Sources: [NVIDIA Developer](), [NVIDIA Technical Blog]() Topics: [AI Agent](), [DOCA](), [OpenShell](), [Nvidia]() Tags: [a2a](), [agent](), [agentic-ai-generative-ai](), [agents](), [ai](), [ai-agent](), [ai-agents](), [ai-networking](), [can](), [complete](), [cross](), [gtc-berlin-2026](), [inside](), [networking-communications](), [nvidia](), [nvidia-sentry](), [open-agent-safety-platform](), [openshell](), [runtime](), [secure-ai](), [secure-ai-agents](), [security](), [security-controls](), [sentry](), [show](), [top-stories](), [trustworthy-ai-cybersecurity](), [using]() ### AI overview NVIDIA Sentry places agent monitoring and policy enforcement on BlueField-4, outside the host and agent's control, to protect against agents that bypass software boundaries. DOCA Flow applies silicon-accelerated layer-4 network filtering; permitted traffic passes to DOCA Tower for TLS termination, application-layer inspection, and Open Policy Agent policy checks. DOCA Argus independently observes host memory and maps processes and execution environments, adding runtime context to access decisions and tamper-evident records. The system can inspect requests and responses, redact secrets, classify behavior, and quarantine agents within milliseconds. It integrates with workload identity systems and can send telemetry to enterprise security platforms. These capabilities are described as part of the OpenShell reference architecture; NVIDIA Sentry is planned for availability early next year, while the text says developers can explore related DOCA components now. ### Source excerpt An AI agent can complete its assignment and still cross a security boundary. Recent incidents show that agents can circumvent security controls while using... ## Developing an AI Factory Digital Twin with an Agent-Assisted Workflow DevFeed: [Developing an AI Factory Digital Twin with an Agent-Assisted Workflow]() Original publisher: [Read original article]() Author: Tanya Lenz Published: 2026-10-21T09:38:49Z Content type: article Language: en Sources: [NVIDIA Developer](), [NVIDIA Technical Blog]() Topics: [AI Agent](), [3D](), [Agent Harness](), [Agent Skills]() Tags: [3d](), [a2a](), [agent](), [ai](), [ai-agent](), [ai-factory](), [assets](), [building](), [data-center-cloud](), [developer-tools-techniques](), [developers](), [developing](), [digital](), [digital-twin](), [engineering](), [equipment](), [factory](), [featured](), [gtc-berlin-2026](), [model](), [openusd](), [requirements](), [requires](), [simulation-modeling-design](), [teams](), [top-stories](), [vera-rubin-nvl72](), [with](), [workflow]() ### AI overview An agent-assisted workflow can turn reference assets, site data, and engineering requirements into an editable OpenUSD AI factory campus model, then prepare it for review and simulation. The NVIDIA Omniverse DSX Blueprint provides reusable digital-twin assets and workflows; agents can assemble and revise scenes through connected tools, while engineers check dimensions, assumptions, and proposed changes. Drawings, equipment data, geographic inputs, and architectural references ground the model, but do not remove the need for dimensional checks and engineering review. SimReady specifications and validators help assess whether geometry, properties, and connection data meet the intended analysis needs. The article sketches a possible fixed-power capacity study: its 1 MW, PUE 1.1 comparison of 400 GPUs and 1.35x token throughput for DSX MaxLPS versus MaxP is illustrative, not a result generated by the campus model. Actual electrical and cooling studies require configured solver connections and engineer review. It also describes distinct roles for SysML requirements tools, managed CAD integration, digital-twin power and cooling analysis, and fluid-flow simulation. ### Source excerpt Building an AI factory digital twin requires developers to bring site plans, equipment assets, and engineering requirements into a consistent model that teams... ## Discover tools at runtime with AWS Agent Registry DevFeed: [Discover tools at runtime with AWS Agent Registry]() Original publisher: [Read original article]() Author: Vibhu Pareek Published: 2026-10-20T16:22:24Z Content type: article Language: en Sources: [Artificial Intelligence]() Topics: [AI Agent](), [Multi Agent Systems](), [agent orchestration](), [agent to agent communication](), [Tool](), [Amazon Bedrock](), [Amazon Cognito](), [AWS IAM](), [Amazon CloudWatch Logs]() Tags: [a2a](), [agent](), [agents](), [amazon-bedrock-agentcore](), [aws](), [build](), [catalog](), [instead](), [intermediate-200](), [mcp](), [mcp-servers](), [post](), [registry](), [runtime](), [search](), [semantic](), [semantic-search](), [servers](), [technical-how-to](), [this](), [tool](), [tools](), [with]() ### AI overview AWS Agent Registry lets an orchestrator find approved MCP servers and A2A agents at runtime, then build request-scoped clients and an agent from the returned capabilities. The sample uses hybrid keyword and semantic search, parses protocol descriptors, and tears down clients after each turn; the catalog stays out of the model context. Registry results provide connection metadata, not invocation credentials: the sample obtains a Cognito OAuth token for MCP calls through AgentCore Gateway, while A2A runtime calls are signed with the caller's AWS credentials through Boto3. Manual approval makes only approved records discoverable, and publisher and approver permissions can be separated. Search quality depends on descriptions, descriptors, queries, and evaluation; the demonstrated return/refund match is a sample result, not a guarantee. Runtime discovery can decouple compatible approved records from orchestrator releases, though protocol, authentication, or policy changes may still require updates. Small stable catalogs and fixed pipelines may be simpler with explicit wiring. ### Source excerpt Hardcoded tool wiring breaks down as an agent's catalog grows from a handful of tools to hundreds. This post walks through a runtime Discover, Instantiate, Execute loop built on AWS Agent Registry, where an orchestrator discovers MCP servers and A2A agents through semantic search at runtime instead of compiling every tool at build time. [Next page]()