What's Missing in the Open Agentic Stack: Lessons From OSS Integration

Transcript

1. AGNTCon + MCPCon Japan What’s Missing in the Open Agentic Stack: Lessons From OSS Integration Sep. 11, 2026 Tatsuya Sato, Satoshi Ito Research & Development Group, Hitachi, Ltd. ©Hitachi, Ltd. 2026. All rights reserved
2. Speakers Tatsuya Sato (Ph.D.) Satoshi Ito Hitachi, Ltd. Chief Researcher, Research & Development Group Hitachi, Ltd. Research & Development Group Senior OSS Specialist, Hitachi OSPO (concurrent role) Joined Hitachi in 2009. Conducts R&D in Agentic AI, IT operations management, blockchain, and OSS. - Started his career in IT operations mgmt. R&D, developing B2B SaaS app. monitoring technologies. - Has worked on blockchain R&D since 2016 and actively contributes to LFDT. He has served as a core maintainer of Hyperledger Fabric since 2024. - Expanded his research focus to Agentic AI in opensource ecosystems. 2 Connect with me on LinkedIn. Researcher at Hitachi working on OSS-centered R&D across blockchain, AI infrastructure, and agentic AI. Focuses on architecture, prototyping, and evaluation of technologies including domain-specific LLMs, distributed inference platforms, MCP, A2A, AGNTCY, and agentgateway. Active OSS contributor and AAIF Community Organizer, organizing Agentic Tokyo to help grow Japan’s opensource AI agent ecosystem. Connect with me on LinkedIn. ©Hitachi, Ltd. 2026. All rights reserved
3. Contents 1. Motivation & Approach 2. [Step A] Agentic AI OSS / Standards Map 3. [Step B] OSS-based Agentic AI System Architecture Patterns 4. [Step C] Demo / Reference Implementation 5. Issue & Missing-Piece Analysis Based on Steps B & C 6. Conclusion 3 ©Hitachi, Ltd. 2026. All rights reserved
4. 1. Motivation & Approach ©Hitachi, Ltd. 2026. All rights reserved
5. 1-1. Background and Motivation Background: ⚫ Standards and open-source software for Agentic AI are rapidly emerging ⬦ MCP, A2A, agent framework, related OSS etc. ⚫ However, in practice, a single protocol, OSS component, or framework is not enough to build a complete (multi-)agent system ⚫ Enterprise adoption demands system architecture that also covers cross-cutting concerns ⬦ Core capabilities such as inter-agent communication and orchestration ⬦ + AuthN / AuthZ and observability, etc. to ensure reliability and operational stability Key Questions: ⚫ How should OSS components be combined to build a practical agentic AI system? ⚫ What gaps and missing pieces remain in an end-to-end OSS-based Agentic AI stack? 5 ©Hitachi, Ltd. 2026. All rights reserved
6. 1-2. Approach: 3-Step Living Reference Loop Investigate the current state of the OSS stack (available components, selection criteria, and missing pieces) through the following three steps 3-Step Living Reference [Step A] OSS / Standards Map [Step B] System Arch. Patterns [Step C] Demo / Ref. Impl. Map the overall landscape of OSS and standards as an OSS-based Agentic AI stack Derive system architecture patterns based on MCP, A2A, and representative OSS components Validate each architecture pattern by building a practical prototype Continuously update Steps A–C while uncovering what is still missing for enterprise adoption (= Living) 6 ©Hitachi, Ltd. 2026. All rights reserved
7. 2. [Step A] Agentic AI OSS / Standards Map ©Hitachi, Ltd. 2026. All rights reserved
8. A B C 2-1. [Step A] Organizing the Agentic AI OSS Stack – Layer Definitions Organize the stack using two types of layers: core layers and cross-cutting layers Agentic AI OSS stack layer definitions Core Layers: ⚫ Main functional areas of the system Provide the system’s core capabilities Cross-cutting Layers: ⚫ Concerns that span the whole system rather than a single layer (e.g., AuthN / AuthZ, observability) Help ensure enterprise-grade quality 8 5 Core Layers Application / UI Orchestration / Runtime 2 Cross-cutting Layers Security/ Operations/ AuthN/ Observability/ AuthZ/ Evaluation Identity Agent Protocol Context / State Management Foundation Models Notes: ⚫ IT infrastructure layer is out of scope ⚫ Some OSS components span multiple layers ©Hitachi, Ltd. 2026. All rights reserved
9. A B C 2-2. [Step A] Organizing the Agentic AI OSS Stack – Sub-layer Definitions Application / UI Agent Application / Chat UIs UI protocols / Generative UI Orchestration / Runtime Agent SDK / Framework Workflow Builder / Mgmt. Sandbox Agent Protocol Core Communication Commerce / Payment Resource Context / State Management Instructions / Skills Knowledge / RAG Security/ AuthZ/AuthN Identity Operations/ Observability/ Evaluation Identity Mgmt. (Subject) Operations & Observability Policy / Guardrails (Rule) Evaluation Gateway Memory / State (Enforcement Point) Foundation Models 9 ©Hitachi, Ltd. 2026. All rights reserved
10. 2-3. [Step A] Agentic OSS Stack Overview (as of Aug. 20, 2026) Application/ UI Agent Applications / Chat UIs Orchestration/ Agent SDK / Framework LangGraph Runtime Graph-based agent WF Impl. MIT LangChain MCP Apps(SEP-1865) Ollama/OpenAI WebUI BSD+ Open WebUI Impl. MCP-compatible apps MIT AAIF Spec. clauses. AG-UI CrewAI Role-based agent collab. Impl. MIT CreｗAI Dify MIT Spec/Impl CopilotKit Flue goose Sandbox agent FW Impl. ASL Astro Local-first AI agent Impl. ASL AAIF Langflow n8n ASL MCP Visual agent builder UI Langflow MIT Impl. A2A Agent collab. infra. Spec/Impl ASL LF Google ADK, MS Agent FW etc. Impl. ・・・ ・・・ Ops. & Observability E2B Sandbox runtime for agents Impl. ASL AAIF Sandbox for AI-gen code Impl. ASL E2B AP2 Agent skills AGENTS.md Memory / State Mem0 Memory layer for agents Impl. ASL Mem0 agent comm. (ACP) Spec/Impl MIT Package for agent capabilities Anthropic Spec. N/A LangChain Memory Conversation memory LangChain Impl. MIT x402 Stablecoin payment Spec/Impl MIT LF Instructions / Skills Agent settings/inst. spec Spec. MIT AAIF Editor AAIF Impl. ASL Agent discovery spec. Spec. ASL LF Prefect ACP(Agent commerce Protocol) Verifiable Intent AI payment checkout standard OpenAI+Stripe Spec. ASL MCP Registry MCP Server registry Impl. ASL AAIF Knowledge / RAG Milvus Large-scale vector DB Impl. ASL LFAI Memory.md Memory description Spec. N/A Anthropic ChatGPT, Genimi, Claude etc. Open-weight LLMs Llama, Mistral, Qwen, DeepSeek etc. model ・・・ ・・・ ARD Proof of user intent Spec/Impl ASL Mastercard Agent resource discovery Spec. ASL Google OKF Knowledge description Spec. MIT Google LlamaIndex RAG/data integration FW Impl. MIT LllmaIndex Context Ontology Accelerator Ontology context layer Impl. ASL AWS Keycloak Langfuse LLM observability PF Integrated ID management Impl. ASL CNCF Workload identity standard Impl. ASL CNCF ANS Impl. MIT+EE Langfuse OpenLLMetry OTel-based LLM inst. Impl. ASL Traceloop Agent naming & discovery CC-BY-SA Impl. Decentralized CNCF Spec. W3C W3C Verifiable Credential Verifiable credential info W3C promptfoo LLM eval / red teaming Impl. W3C Policy/Guardrails (rules) NeMo Guardrails Impl. Eval Quality evaluation Decentralized ID LLM guardrails NVIDIA ASL Agent Governance Toolkit MIT promptfoo RAGAS RAG eval. FW Impl. ASL Ragas DeepEval LLM/ agent eval. FW Impl. Gateway (enforcement point) ASL Confident AI Model access & routing Red teaming LLM proxy / gateway BerriAI Impl. MIT LLM vulnerability scanner LiteLLM Agent Router Garak Impl. ASL NVIDIA Formerly Envoy AI Gateway Impl. ASL AAIF Agent communication Legend: Layer Sub-layer explanation Spec/Impl Telemetry standard ASL CNCF Spec/Impl OpenID OpenID Policy/governance for agents Impl. MIT MS OSS Name Proprietary LLMs Spec. DID OASF FastMCP High-speed MCP impl. OpenTelemetry OAuth authentication extension Spec. UCP ・・・ OAuth 2.1 SPIFFE/SPIRE OpenSandbox Agno Agent mgmt. platform ASL Ango Impl. Agent Client Protocol Agent comm. protocol Spec. ASL AAIF Agent commerce protocol Agent payment protocol Spec. ASL Google Spec. ASL Google Prop. Vendor-led Agent SDKs Resource Resource/tool integration protocol Spec/Impl MIT→ASL AAIF model Operations/ Observability/Eval. Authorization standard Spec. IETF IETF Google AGNTCY Core Communication Commerce / Payment 10 Spec/Impl Identity Mgmt. (subject) Centralized Agent-driven gen UI proto Sandbox Workflow automation n8n Impl. SUL Cond. Foundation Models C OpenID Connect Integrated app dev. ASL+ LangGenius Impl. Context/ State Management A2UI Agent–UI comm. proto Workflow Builder / Management Agent Protocol B Security/Auth/Identity UI protocols / Generative UI Open WebUI LibreChat Multi-model chat UI ClickHouse MIT Impl. A License Owned by AAIF Project under AAIF LF Project under LF family ©Hitachi, Ltd. 2026. All rights reserved agentgateway Gateway for agent comm. Impl. ASL AAIF Tool/MCP ©Hitachi, Ltd. 2026. All rights reserved MCP Gateway MCP mgmt. proxy Impl. MIT MS
11. 2-3. [Step A] Agentic OSS Stack Overview Interactive HTML version ©Hitachi, Ltd. 2026. All rights reserved 11 ©Hitachi, Ltd. 2026. All rights reserved
12. 3. [Step B] OSS - based Agentic AI System Architecture Patterns ©Hitachi, Ltd. 2026. All rights reserved
13. A B C 3-1. [Step B] Defining Architecture Patterns – Selecting the Comparison Axes (1) To define the patterns, we need to decide what to compare: ⚫ The axes are the key design decisions that determine “which OSS to use” at each layer ⚫ To identify the axes, we first fix and exclude: [1. Fix] prerequisites — broadly applicable to enterprise use cases → no longer axes • MCP and A2A are required as core protocols for the multi-agent architecture • The system is OSS-based in principle, but it also uses proprietary LLMs because they are commonly used in enterprise settings today (Local LLMs are out of scope) • AuthN/AuthZ and observability are required. A centralized enterprise IdP is assumed for identity management 13 [2. Exclude] advanced or use-casespecific axes — to validate the minimal architecture first • Commerce and payment • Execution isolation (sandbox) • ・・・ ©Hitachi, Ltd. 2026. All rights reserved
14. A B C 3-2. [Step B] Defining Architecture Patterns – Selecting the Comparison Axes (2) Main axis: How are the OSS components integrated? ⚫ Pattern 1: Pure A2A / MCP — directly combine standard protocols, basic SDKs, and individual OSS components. baseline ⚫ Pattern 2: Framework / Suite-based — use an agent framework / suite and its integrated components. and what still remains? How much integration can the framework take over, ⚫ Pattern 3: Gateway-based — put a gateway in the middle of all agent, tool, etc. communication. How much control can be added without modifying agent code, and what still remains? Ref. Other axes (out of scope for this validation) ⚫ Workflow model: deterministic or dynamic (e.g., n8n, Dify, etc. for deterministic workflows) ⚫ Use of A2A for agent-to-agent integration: with or without A2A 14 (Direct API or framework-native integration without A2A is also possible) ©Hitachi, Ltd. 2026. All rights reserved
15. A B C 3-3. [Step B] Defining Architecture Patterns – Mapping to Concrete OSS Map the three architecture patterns to specific OSS components ⚫ AGNTCY is adopted for Pattern 2 as the framework, and agentgateway for Pattern 3 as the gateway Layer Pattern 1: Pattern 2: Pattern 3: Pure A2A/MCP Framework/Suite-based Gateway-based Agent Core communication A2A, MCP (adopt in all patterns) Protocol Resource discovery Static discovery Dynamic discovery Static discovery (A2A Agent Card etc.) (Agent Directory + OASF) (Gateway-managed) Orchestration Framework / Suite No (Standards + Yes (AGNTCY) No (Standards + / Runtime vendor SDKs) vendor SDKs) Workflow Dynamic (prompt-defined) Security / Centralized (IdP), Centralized Centralized Centralized Auth / Decentralized (DID/VC) (Keycloak) (Keycloak as IdP) (Keycloak) Identity Agent–MCP Token Exchange Same as Pattern 1 Pattern 1 + (Keycloak) Gateway-managed Agent–Agent ID authN (Keycloak) Same as Pattern 1 Gateway-managed Observability OTel + Langfuse AGNTCY Obs & Eval Gateway-managed 15 Parameter ©Hitachi, Ltd. 2026. All rights reserved
16. 4. [Step C] Demo / Reference Implementation ©Hitachi, Ltd. 2026. All rights reserved
17. 4-1. [Step C] Target Use-Case Scenario – Procurement Process Optimization Multi-agent support for enterprise procurement: request -> budget / compliance / procurement checks -> approval -> ordering Processing sequence (excerpt) ⚫ Requester WebUI Purchase request Coordinator Agent Request info Budget Agent Budget Mgmt. System (MCP) Case info & management request Ordering Agent Case Mgmt. System (MCP) Register case Approver Purchase approval Request info Check case info Budget check Get case info Get budget info Approval request Case info & approval info 17 Update case ©Hitachi, Ltd. 2026. All rights reserved
18. A B C 4-2. [Step C] Pattern 1: Pure A2A/MCP (Individual OSS Combination) Chat UI Keycloak Coordinator Agent Budget Agent ① Agent endpoints managed statically in-app A2A ②Agent-Agent connect directly ③ Token Exchange propagates authority Compliance Agent Procurement Agent MCP Budget Mgmt. System Where more custom build is needed than in the other patterns Compliance System - SDKs (vendor / protocol) - Connection code (A2A/MCP) - Instrumentation code Ordering Agent ② Agent-MCP connect directly ③ Token Exchange delegates authority on MCP access Contract Mgmt. Langfuse (Observability) A2A MCP Trace export Case Mgmt. System Pattern 1 characteristics: ① Holds a static internal list of agent endpoints, and fetches the A2A Agent Card directly from each agent ② Agent-Agent and Agent-MCP connect directly over standard protocols, with no intermediary (no proxy / gateway / registry) ③ Uses Token Exchange to hand the user's authority downstream 18 ©Hitachi, Ltd. 2026. All rights reserved
19. A B C 4-3. [Step C] Pattern 2: Framework/Suite-based (AGNTCY) ①Dynamic discovery Chat UI (Directory+OASF) AGNTCY Directory AGNTCY Identity Coordinator Agent A2A MCP Agent AGNTCY Trace export components SLIM (A2A/MCP) ②A2A/MCP traffic via SLIM Keycloak SLIM Node(s) Messaging (pub/sub, encrypted) Node Budget ③ User-centric AuthZ Agent (delegation) needs Pattern 1-style build Budget Mgmt. System Node SLIM(A2A) Compliance Agent Compliance System Node Node Procurement Agent Ordering Agent SLIM(MCP) ② Observability via Observe SDK AGNTCY Obs & Eval ③Badge proves origin (IdP federation) Case Mgmt. Contract Mgmt.but per-agent instrumentation remains System Pattern 2 characteristics: ①Agents are discovered and connected dynamically: AGNTCY Directory + OASF gives cross-cutting search to derive the agent to call ②A2A/MCP traffic consolidated on SLIM. Observe SDK instruments A2A/SLIM/MCP for consistent observability; per-agent instrumentation remains ③AGNTCY Identity federates with the IdP and proves provenance via Badge; its agent-centric AuthZ model still needs build for user delegation 19 ©Hitachi, Ltd. 2026. All rights reserved
20. A B C 4-4. [Step C] Pattern 3: Gateway-based (agentgateway) Chat UI ① No endpoint changes needed ① Connections centrally managed by GW ② Observability without agent changes agentgateway ③ Per-agent access control Budget ③ User-centric AuthZ Agent (delegation) needs Pattern 1-style build Budget Mgmt. System Trace export Centralized comms / observability / policy A2A ② Agent internals not instrumented Compliance Agent Procurement Agent MCP Compliance System Ordering Agent ③ Per-tool authz / filtering Contract Mgmt. Case Mgmt. System Langfuse (Observability) Keycloak Coordinator Agent agentgateway components A2A MCP Pattern 3 characteristics: ①The gateway rewrites and distributes Agent Card endpoints, so callers need no endpoint change ②Traces, logs and metrics through the gateway are collected without agent changes; agent internals are out of scope ③agentgateway validates JWT / OAuth 2.0 and uses the result to control access to agents and MCP servers 20 ©Hitachi, Ltd. 2026. All rights reserved
21. A B C 4-5. [Step C] Multi-Agent Demo for Procurement Process Optimization (Pattern 1) 21 ©Hitachi, Ltd. 2026. All rights reserved
22. 5. Issue & Missing - Piece Analysis Based on Steps B&C ©Hitachi, Ltd. 2026. All rights reserved
23. 5-1. [Step B&C] Comparative Evaluation of the Three Patterns Trade-offs among flexibility, ease of adoption, and governance — issues remain in every Axis Overall eval. Pros Cons Open issues 23 Pattern 1: Pure A2A/MCP [Flexibility first] High freedom, heavy build effort • Free OSS choice and swap • Build to any level of detail Pattern 2: Framework/suite-based [Ease of adoption first] Easy to adopt; bound by suite maturity • Bundled agent features (discovery, ID, obs.) • Less per-component wiring Pattern 3: Gateway-based [Governance first] Central control, few agent changes • Gateway-central authN / obs. / policy • Few agent changes; auth before requests arrive • No control outside the gateway (agent internals) • Gateway lock-in (protocol versions) • Heavy design, build, config, test • Framework lock-in (maturity, load versions, companion OSS) • Track each OSS's updates & compat. • Auth still needs extra OSS or custom build in every pattern • Observability: coverage vs. effort trade-off remains • Pattern. 1: costly individual instrumentation, but scope designed freely • Pattern. 2: SDK covers part; extra instrumentation beyond it • Pattern. 3: non-invasive at the gateway; agent internals / outside invisible ©Hitachi, Ltd. 2026. All rights reserved ©Hitachi, Ltd. 2026. All rights reserved
24. 5-2. [Step B&C] Issue & Missing-Piece Analysis Based on the Three Patterns End-to-End Observability ⚫ Heavy burden: design per observation goal, then combine multiple methods ⬦ e.g., E2E tracing needs combined individual instrumentation; a simpler way to link A2A tasks, agent runs, and tool calls per task is needed ⬦ e.g., the gateway logs who accessed tools/agents; OTel audits why -> either alone leaves audit gaps End-to-end delegation of authority & authorization ⚫ AuthN/AuthZ building blocks exist, but with Agent → Agent → Tool → Resource decided dynamically, an E2E-consistent way is needed to handle whose authority applies, what is delegated downstream, and how permissions narrow at each hop Mechanisms to control agent faithfulness ⚫ In the procurement use case, orders were sometimes placed despite unmet terms or approvals; mechanisms to keep agents faithful are needed (paired with AuthN/AuthZ responsibility boundaries) 24 ©Hitachi, Ltd. 2026. All rights reserved
25. 6. Conclusion ©Hitachi, Ltd. 2026. All rights reserved
26. 6. Conclusion ⚫ Approach: Investigate the current state of the OSS stack through the following steps ⬦ [Step A] Agentic AI OSS / Standards Map ⬦ [Step B] OSS-based Agentic AI System Architecture Patterns ⬦ [Step C] Demo / Reference Implementation ⚫ Issue analysis based on architecture design and demo implementation of three typical patterns ⬦ Pattern 1: Pure A2A; Pattern 2: Framework/Suite-based (AGNTCY); Pattern 3: Gateway- based (agentgateway) ⬦ OSS broadly covers the stack, but enterprise adoption needs broader protocol-version and OSS-integration support, plus stronger end-to-end authN/authZ and observability 26 ©Hitachi, Ltd. 2026. All rights reserved
28. A B C Appendix. [Step C] Target Use-Case Scenario – Procurement Process Optimization Overview ⚫ Support enterprise procurement with multi- agent workflows (request -> budget/compliance/procurement review -> approval -> ordering) ⚫ The orchestrator agent acts as the user interface and requests checks from specialist agents (budget, compliance, procurement) ⚫ Based on the request, required approvals and rule checks are performed, and approval requests are issued to the manager, budget owner, procurement staff, etc. ⚫ Items are ordered only after all conditions and Actors Role Responsibility Requester Requests purchase of products/services Manager Reviews and approves business need for purchase Budget Owner Reviews and approves validity of budget usage Compliance Officer Assesses compliance issues and exception risks Procurement Staff Checks procurement terms/vendor purchasing rules and approves exceptions Ordering Staff Processes orders for approved requests human approvals are complete 28 ©Hitachi, Ltd. 2026. All rights reserved