{
  "format": "agent-article-v0",
  "article_id": "EA-020",
  "canonical_url": "/tools/ea-020-ai",
  "page_type": "reference",
  "claim_ids": [],
  "evidence_ids": [
    "EA-020-R11-RESEARCH",
    "EA-020-R11-WEB-READBACK"
  ],
  "unknown_ids": [
    "EA-020-UNKNOWN-01",
    "EA-020-UNKNOWN-02",
    "EA-020-UNKNOWN-CURRENTNESS"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "UNKNOWN",
  "observation_status": "SPEC_ONLY",
  "freshness": "UNKNOWN",
  "last_verified": null,
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "COMM-022-EA0020",
    "WEBBODY-EA0020-R8-AB9B8567"
  ],
  "article_sources": [
    {
      "id": "EA-020-R11-RESEARCH",
      "evidence_class": "RESEARCH",
      "title": "EA-020 監査済みresearch / canonical revision binding",
      "supports": [
        "AIアーキテクチャは、Single-agentかMulti-agentかという一問だけでは決まらない。制御を誰が握るか、状態と知識をどこに置くか、外部ツールをどの境界から呼ぶか、同期・非同期・batchのどの実行形態を使うか、人間承認と復旧をどこに置くかを分けて設計する。"
      ],
      "limit": "canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "COMM-022-EA0020"
      ],
      "supporting_locators": [
        "COMM-022-EA0020",
        "EA-020-R5-LEGACY-MIGRATION-20261008-R1",
        "content/staging/EA-020.md"
      ],
      "scope": "監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。",
      "provenance_status": "AUDIT_PASS_CANONICAL_BINDING"
    },
    {
      "id": "EA-020-R11-WEB-READBACK",
      "evidence_class": "IMPL",
      "title": "EA-020 Web body identity / canonical readback",
      "supports": [
        "canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。"
      ],
      "limit": "body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。",
      "checked_at": null,
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "WEBBODY-EA0020-R8-AB9B8567"
      ],
      "supporting_locators": [
        "WEBBODY-EA0020-R8-AB9B8567",
        "content/staging/EA-020.md",
        "EA-020-R5-LEGACY-MIGRATION-20261008-R1"
      ],
      "scope": "R9/R10 canonical readback後のProduction生成時body identity。",
      "provenance_status": "CANONICAL_READBACK_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "Public claim",
      "text": "AIアーキテクチャは、Single-agentかMulti-agentかという一問だけでは決まらない。制御を誰が握るか、状態と知識をどこに置くか、外部ツールをどの境界から呼ぶか、同期・非同期・batchのどの実行形態を使うか、人間承認と復旧をどこに置くかを分けて設計する。\n\nRAG、MCP、human-in-the-loop、batchはagent数とは別の層であり、同じsystem内で組み合わせられる。複雑な構成ほど高度とは限らず、追加したcoordination boundaryごとに状態喪失、権限、停止条件、検証、復旧の責任も増える。"
    },
    {
      "heading": "Five-axis architecture matrix",
      "text": "このtaxonomyは `PROPOSAL`。一列の成熟度taxonomyではなく、以下の組合せとして扱う。\n\n1. CONTROL TOPOLOGY\n   - deterministic workflow\n   - single-agent loop\n   - planner-executor\n   - manager / orchestrator-workers\n   - decentralized multi-agent\n   - evaluator-optimizer\n\n2. STATE & KNOWLEDGE\n   - ephemeral context\n   - explicit checkpoint-state\n   - RAG\n   - blackboard / shared state\n   - external source of truth\n\n3. INTEGRATION BOUNDARY\n   - direct API/tool\n   - MCP host/gateway/server\n   - queue/event bus\n   - sandbox\n\n4. EXECUTION MODE\n   - synchronous interactive\n   - asynchronous task\n   - batch\n   - scheduled/event-driven\n\n5. OVERSIGHT & RECOVERY\n   - HITL approval\n   - policy gate\n   - verifier\n   - checkpoint/resume\n   - retry/idempotency\n   - trace/audit\n\n同一systemは各層から一つ以上を組み合わせ得る。`single-agent + RAG + MCP + HITL + async task` は矛盾しない。"
    },
    {
      "heading": "Pattern-card operational fields",
      "text": "各pattern cardには以下を固定欄として持たせる。\n\n- USE WHEN\n- DO NOT USE WHEN\n- STATE OWNER\n- ACTION AUTHORITY\n- TERMINATION\n- RECOVERY\n- OBSERVABILITY\n- COST SHAPE\n\n### Planner / executor\ncontrol decompositionとして扱う。plan drift、stale plan、executor error、replanning条件、terminationを評価する。ReAct型のreasoning/action interleaveとはcontrol placementが異なる。\n\n### Multi-agent\nsingle-agentの上位互換とは扱わない。役割分離、parallelism、context isolation、specializationの便益候補と、handoff loss、shared-state conflict、duplicate work、termination disagreement、verification costを同時に評価する。\n\n### Blackboard / shared state\nmulti-agent固有とは扱わない。shared artifact/state storeを複数worker、人間、deterministic processが読み書きするcoordination patternとして扱う。古典blackboard architectureからLLM-era shared-stateへの対応付けは `INFERENCE`。\n\n### RAG\nagent topologyではなくknowledge access layerとして扱う。retrieval corpus ACL、index freshness、retrieval recall/precision、evidence provenance、generator groundingを分離して評価する。RAG導入だけでworkflow controlやsource-of-truth governanceが解決したとはみなさない。\n\n### MCP gateway\nagent topologyではなくinteroperability/security boundaryとして扱う。protocol revision、routing、authorization、gateway境界をagent orchestrationと分離する。MCPは `PRODUCT_VOLATILE` とし、publication時にcurrent specificationを再取得する。\n\n### HITL\n「最後に人が見る」だけでは不足する。interrupt point、decision type、persisted state、resume semantics、identity、audit trail、timeout/escalationを設計対象にする。\n\n### Batch\nexecution modeとして扱う。interactive agentと同じSLA/UXで比較しない。throughput/costとlatency、partial completion、result reconciliation、retention、cancel/retryのtradeoffを記録する。"
    },
    {
      "heading": "Evidence / provenance",
      "text": "- OpenAI, A practical guide to building agents — single/multi-agent orchestration guidance。provider guidanceであり普遍標準ではない。`PRODUCT_VOLATILE`。\n- Anthropic, Building Effective AI Agents — workflow/single-agent/multi-agent/sequential/parallel/evaluator-optimizerのarchitecture guidance。provider guidanceであり普遍標準ではない。\n- Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models — reasoningとexternal actionをinterleaveするagent-loop研究。benchmarkをenterprise production reliabilityへ外挿しない。\n- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — retriever + generator / non-parametric memoryの研究根拠。authorization/freshness/provenanceは別評価。\n- H. Penny Nii, The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures — classical blackboard architecture。LLM shared-state mappingは `INFERENCE`。\n- Model Context Protocol 2026-07-28 Specification — current interoperability surfaceとして採用。`PRODUCT_VOLATILE`、publication-time recheck必須。\n- LangGraph Persistence / overview — checkpoint、HITL、resume、fault-tolerant executionのauthor-maintained implementation example。唯一方式とは扱わない。`PRODUCT_VOLATILE`。\n- Cemri et al., Why Do Multi-Agent LLM Systems Fail? — multi-agent coordination failureのcounterevidence。single-agentが常に優れる証明とは扱わない。"
    },
    {
      "heading": "Evaluation",
      "text": "architecture比較では同一task fixtureを用い、agent数自体を品質指標にしない。\n\n- task completion / correctness\n- tool/action success and side-effect correctness\n- total model/tool calls\n- token/API cost\n- wall-clock latency\n- retry/replan/handoff count\n- state loss / duplicated work / stale-plan incidence\n- termination correctness\n- evidence/citation fidelity for RAG\n- human interventions / approval latency\n- recoverability after injected interruption\n- trace completeness / provenance\n\nsingle-agent vs multi-agentは可能な範囲で同一model能力、tool set、task familyを揃える。"
    },
    {
      "heading": "Security / privacy / audit / cost / operability",
      "text": "Security: action-capable patternはleast privilege、tool allowlist、sandbox、approval gate、identity propagationを設計する。MCP gatewayはcurrent protocol revisionに沿ったauthorization等をpublication時に再確認する。\n\nPrivacy: RAG corpus、shared state、blackboard、checkpoint、batch filesは会話contextとは別のretention/data residency/access-control surfaceを持つ。\n\nAudit: planner decision、handoff、retrieval evidence、tool call、approval、state version、batch job/resultを相関可能なIDで追跡する。\n\nCost: multi-agent/evaluator loopsはcall数を増やし得る。batch/parallelismは単価またはthroughputを改善し得るが、latency/coordination costを含めTCOで評価する。\n\nOperability: checkpoint/resume、idempotent external write、timeout、cancellation、dead-letter/reconciliation、versioned state schemaを長時間・非同期patternの運用条件にする。"
    },
    {
      "heading": "Availability gates",
      "text": "- Core pattern自体はprovider plan非依存。\n- 実装可能性はtool calling、structured output、async job、state store、human approval surface等に依存。\n- Provider agent implementationはAPI/SDK release、model support、organization policy、tool authorizationに依存。\n- MCPはclient/host/serverのprotocol revision/extension compatibilityに依存。\n- LangGraph等のstateful implementationはpackage/runtime/version、checkpointer backend、deployment modeに依存。\n- Batchはendpoint/model support、usage tier、rate limits、retention policy、latency toleranceに依存。"
    },
    {
      "heading": "Failure envelope / OPEN_UNKNOWN",
      "text": "- provider architecture guideをEnterprise AI Coreの必須仕様へ昇格しない。\n- ReAct/RAG/MAS研究benchmarkを特定企業tenant、current closed model、全業務へ外挿しない。\n- multi-agent superiorityを推論しない。\n- blackboard古典研究と2026 LLM shared-state implementationの同一性を主張しない。\n- LangGraphをcheckpoint/HITLの唯一方式としない。\n- MCPの旧session architectureをcurrent恒久仕様として固定しない。\n- context長増加だけでexternal state/persistence不要とは断定しない。\n- batch価格、対象model、retention、rate limitは `PRODUCT_VOLATILE`。"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "- current productionにおけるblackboard/shared-state LLM architectureの独立case/failure evidence\n- planner-executorとsingle-loop ReAct型のenterprise同条件比較\n- MCP current revisionへの主要client/server migration・compatibility evidence\n- model能力差を統制したcurrent multi-agent task boundary\n- provider横断batch comparison\n\nこれらは推測で閉じない。"
    },
    {
      "heading": "Architecture selection flow",
      "text": "`最小構成 → 観測されたfailure/constraint → 必要なlayerだけ追加 → eval → rollback可能性確認` を基本線とする。"
    }
  ],
  "human_url": "/tools/ea-020-ai",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-020-ai",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-020-ai"
}