The AI Agent Fabric Catalog

Source: github.com/aws-samples/sample-agentic-fabric (MIT-0, Python + TypeScript CDK)

Intent

Demonstrate a complete governance-first agent fabric on AWS, with deterministic policy evaluation on every dispatch, dynamically-generated worker agents, and explicit authority modeling.

Motivating Problem

Most reference architectures for agent fabrics demonstrate plumbing: how an event bus connects to a Lambda that calls an LLM. They don’t demonstrate governance. The Arbiter is the public exception: a CDK-deployable substrate that wires up event routing, async queues, dynamic agent generation, and deterministic governance into a single coherent design --- with the governance treated as architecturally first-class rather than as a feature bolted onto an existing platform.

How It Works

Three coordinating agent roles run on Lambda: the Arbiter (the supervisor; uses the Bedrock Converse API to select worker agents via an agent-as-tool pattern; dispatches via SQS; tracks fan-out/fan-in completion); Workers (dynamically-generated agents executed by a generic wrapper that downloads code from S3 and injects a governance tool handler); the Fabricator (generates new agent code with the Strands Agents SDK when no existing agent can handle a task, uploads to S3, registers in the Fabric Index).

Event routing happens via EventBridge --- renamed in the architecture as the “Neural Weave.” Twelve DynamoDB tables hold agent registry, workflow state, worker state, tool configuration, five governance tables (authority units, composition contracts, case law, constitutional layers, governance ledger), and two memory tables (agent metrics, workflow outcomes). S3 holds versioned agent code. SNS handles governance escalation notifications.

The Control-Surface Band is the governance layer, deployed as a Lambda Layer (not a service) and so architecturally independent from the agents it governs. It evaluates every dispatch against four primitives --- Authority Scopes, Composition Contracts, Arbitration Patterns (scope-based, priority, conjunction, and state-aware with monotonic reduction), and the Legibility Ledger --- with no LLM calls and a default of denial for actions not explicitly permitted. Mandatory constitutional review applies to every permit; two global invariants are seeded by default (no_irreversible_action_without_audit_trail and no_scope_expansion_under_unconfirmed_state).

Governance is in bypass mode (GOVERNANCE_BYPASS=true) on initial deploy so the system runs as a standard Supervisor pattern; flipping the flag activates the full evaluation. Conflicts that the engine can’t resolve escalate to humans; the human resolution is encoded as case law and applied deterministically on recurrence.

When to Use It

Teams building agent fabrics on AWS who want a governance-first design. Architects studying the constitutional-substrate pattern as a design reference. Read-and-port even if not deploying the exact stack --- the four governance primitives transfer to any architecture.

Alternatives --- AWS Sample Agentic Platform for a broader-scope reference with multiple compute choices but less governance focus. Microsoft Agent Framework when the target stack is .NET / Azure. Roll-your-own when the governance model needs to differ substantially from the constitutional pattern.

Sources

• github.com/aws-samples/sample-agentic-fabric

• Aaron Sempf, “Architecting Autonomy” series (aaronsempf.substack.com; returned HTTP 404 as of October 2026, though the repo README still links to it)

Example

A claim-processing agent fabric for an insurance back-office. The Arbiter receives claim events via EventBridge, selects from a fleet of specialized worker agents (document extraction, fraud detection, payment authorization). The Fabricator generates a new agent the first time a claim type is encountered that no existing agent handles. The Control-Surface Band denies any payment-authorization action that the agent doesn’t hold the corresponding Authority Scope for; escalations get reviewed by a claims supervisor and the resolution is encoded as case law. Every dispatch and every governance decision is recorded in the Legibility Ledger for compliance audit.

Example artifacts

Schema / config.

// Authority Scope (Python dataclass; src/governance/models.py)

\@dataclass

class AuthorityScope:

action: str # e.g. "payment.authorize"

target: str # e.g. "customer.{customer_id}"

conditions: dict # e.g. {"amount_lte": 10000, "region": "us"}

delegated_by: str

expires_at: datetime

// Composition Contract

\@dataclass

class CompositionContract:

pattern: Literal["scope_based", "priority", "conjunction",
"state_aware"]

scopes: list[AuthorityScope]

resolution: ConflictResolution

Setup.

# Deploy the full stack:

cd app

npm install

npm run build

ENVIRONMENT=dev npx cdk bootstrap --profile <your-profile>

ENVIRONMENT=dev npx cdk deploy --all \

--require-approval never --profile <your-profile>

# Submit a test task via EventBridge:

aws events put-events --entries '[{

"Source": "task.request",

"DetailType": "System-Task",

"Detail": "{\"task\": \"Create a greeting agent that says
hello\"}",

"EventBusName": "agentic-fabric-dev"

}]'

Source: github.com/aws-samples/sample-agentic-platform (broader-scope companion repo)

Intent

Demonstrate the operational shape of an agent platform on AWS across two compute paths, EKS with Helm or Bedrock AgentCore Runtime with an ECS/Fargate gateway layer, organized so that coding agents can navigate the repo.

Motivating Problem

The Arbiter sample focuses tightly on the governance design. A broader question that AWS’s Sample Agentic Platform answers: when you build an agent fabric on AWS, which compute primitive should each component run on? A self-operated EKS cluster, or Bedrock AgentCore Runtime with a lighter gateway layer on ECS? The repo is structured as a navigable monorepo with explicit structural documentation so that coding agents can read it and propose changes; the design philosophy itself demonstrates a fabric property (agent-readable infrastructure).

How It Works

The repo offers two deployment paths, both built with Terraform. Option A deploys an EKS cluster and runs agents and services through Helm charts. Option B deploys a lighter ECS/Fargate layer for the LiteLLM gateway and runs each agent in Bedrock AgentCore Runtime. Both paths share the same agent code, because every agent implements the AgentCore interface (port 8080, /invocations). The shared components are Cognito for identity, a LiteLLM gateway, Aurora PostgreSQL, ElastiCache, and OpenTelemetry collectors.

The structural documentation pattern is the distinctive feature. A tree of AGENTS.md files guides coding agents (Claude Code, Kiro, Cursor) through the monorepo, explaining what each part does and how to extend it. The premise is that a maintainable agent platform must be readable by the agents that operate on it.

When to Use It

Teams choosing among AWS compute primitives for their agent platform. Cases where the question “should this agent run on EKS or AgentCore” needs a worked example with trade-off discussion. Reference for the agent-readable documentation pattern.

Alternatives --- the Arbiter sample (above) when the question is governance design. Direct cloud-vendor documentation when the question is about a single service.

Sources

• github.com/aws-samples/sample-agentic-platform

Source: github.com/microsoft/agent-framework (.NET and Python; MIT)

Intent

Provide Microsoft’s official building blocks for orchestrating and safely deploying production multi-agent workflows on the Azure stack.

Motivating Problem

Microsoft’s agent tooling grew as two separate SDKs, Semantic Kernel and AutoGen, and teams had to choose between them. Agent Framework (1.0 GA, April 2026) is the successor to both: it combines Semantic Kernel’s enterprise features with AutoGen’s multi-agent orchestration, and Microsoft publishes migration guides from each. AutoGen is now in maintenance mode, and new Semantic Kernel feature work has moved to Agent Framework. Production concerns (identity, observability, hosting) are handled by the framework rather than left to the application.

How It Works

The framework provides typed agent and workflow abstractions with native support for both .NET and Python. Agents have role-defined behavior, optional tool access, and pluggable model backends (Azure OpenAI, Bedrock, OpenAI direct, etc.). Workflows orchestrate multi-agent collaborations with deterministic transitions and built-in state persistence.

Production deployment integrations: Entra ID for agent identity (so each agent shows up as a verifiable principal); built-in OpenTelemetry with the GenAI semantic conventions, exportable to Application Insights; Microsoft Foundry hosted agents for managed execution; A2A hosting so other agents can call an agent; and durable agents through the Durable Task / Azure Functions extension. The framework hides the wiring; the developer writes agent and workflow definitions in code.

When to Use It

Teams on the Microsoft enterprise stack (Azure, Entra, M365) who want a vendor-supported framework for production agent workflows. Cases where Semantic Kernel and AutoGen lessons need to be combined under one SDK. Enterprise deployments where identity into Entra and observability into Application Insights are requirements rather than nice-to-haves.

Alternatives --- LangGraph for the cross-cloud open-source equivalent. Existing Semantic Kernel or AutoGen code keeps working, but AutoGen is in maintenance mode and Microsoft recommends migrating both to Agent Framework. Volume 9 covers multi-agent orchestration frameworks as a class.

Sources

• github.com/microsoft/agent-framework

• devblogs.microsoft.com/agent-framework/migrate-your-semantic-kernel-and-autogen-projects-to-microsoft-agent-framework-release-candidate/

Example

An enterprise document-review agent fabric: a workflow of three agents (extractor, classifier, summarizer) defined with the Agent Framework, each with an Entra-issued identity scoped to specific SharePoint sites; Application Insights traces every step; the workflow runs on Azure Container Apps with auto-scaling driven by Service Bus queue depth. The same workflow runs in a developer sandbox via Azure Container Apps local emulation.

Source: aws.amazon.com/bedrock/agentcore (managed agent runtime)

Intent

Provide a managed, serverless runtime for AI agents on AWS, with a dedicated microVM per session and managed identity, memory, tool gateway and observability services, so teams run agents without operating the substrate.

Motivating Problem

For teams that don’t want to operate their own agent fabric on EKS or build their own substrate, AgentCore is AWS’s managed offering: bring agent code written in any framework (Strands Agents, LangGraph, CrewAI, LlamaIndex) against any model, deploy it to AgentCore Runtime, and get per-session isolation, identity, memory and observability. The operational tax shifts from the agent platform to AWS.

How It Works

AgentCore (GA October 2025) is a set of services rather than one runtime: Runtime, Gateway, Memory, Identity, Observability, Code Interpreter and Browser. Runtime gives each session its own microVM with isolated compute, memory and filesystem; the microVM is terminated and its memory sanitized when the session ends, and sessions last up to 8 hours. Identity handles inbound authentication from identity providers (Cognito, Okta, Entra) and keeps an outbound credential vault for the tokens and keys agents use to call other services. Observability sends OpenTelemetry traces into CloudWatch. Agents can use Bedrock models through the Converse API, Knowledge Bases for retrieval and Guardrails for content moderation, but the runtime is framework- and model-agnostic.

Integration with the broader AWS ecosystem is the differentiator. AgentCore plugs into EventBridge for event triggers, into S3 for file ingestion, into Step Functions for orchestration, into Bedrock Knowledge Bases for retrieval. The agent code is mostly the same as it would be elsewhere; the operational surface is AWS-shaped.

When to Use It

Teams running on AWS who want managed agent infrastructure. Cases where the AWS-native integration is more valuable than cross-cloud portability. Workloads where shifting operational tax to AWS is worth the cost.

Alternatives --- self-hosted on EKS for full control, or kagent (Section F) for a Kubernetes-native agent runtime. The AWS Arbiter Sample (above) when the governance design is critical. Cross-cloud frameworks (LangGraph, CrewAI) when portability matters more than AWS-native integration.

Sources

• aws.amazon.com/bedrock/agentcore

• docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-sessions.html

Source: github.blog/ai-and-ml/generative-ai/under-the-hood-security-architecture-of-github-agentic-workflows/ (Landon Cox and Jiaxiao Zhou, March 2026)

Intent

Contain a coding agent running inside GitHub Actions by isolating it in its own container on the runner VM, routing its network, tool and model traffic through trusted proxies, and letting it change the repository only through vetted outputs.

Motivating Problem

GitHub Agentic Workflows (gh-aw) run coding agents (Copilot, Claude Code, Codex) from markdown workflow files inside GitHub Actions, with access to repositories and the GitHub API. That security profile differs from a general code sandbox: the agent runs against the customer’s real code, in an environment connected to the customer’s CI and deployment pipeline, and it reads untrusted input such as issue text. The blast radius of a successful prompt injection is everything the workflow can touch. GitHub’s design contains the agent so that a compromised agent holds no secrets and cannot write anything directly.

How It Works

Each run uses a standard GitHub Actions runner VM. Inside it, the agent runs in its own container, in a chroot jail over a read-only mount of the host. Network egress passes through a firewall; MCP tool access goes through a trusted MCP gateway; LLM calls go through an API proxy, so the agent container never holds secrets or API keys. The agent cannot write to the repository or the GitHub API itself: its intended writes are staged as “safe outputs”, which are vetted before anything is applied.

The GitHub blog post (March 2026) documents the design. The patterns are educational for any team building a layered sandbox themselves: isolate the agent inside the VM boundary, keep credentials in trusted proxies outside the agent’s reach, and turn writes into reviewable artifacts. For the trigger side of the same platform, see Volume 4, GitHub Actions as agent runner.

When to Use It

Repositories on GitHub that want agentic workflows with appropriate safety properties. Teams designing their own agent sandbox, who can read the design as a reference.

Alternatives --- E2B or Modal (Volume 3) for general-purpose code-execution sandboxes. Self-built runners on hyperscaler infrastructure (Nitro Enclaves on AWS, Confidential VMs on GCP, Confidential Computing on Azure) when the agent must run on the customer’s own infrastructure with stronger isolation guarantees. GitHub Actions as agent runner (Volume 4) for the trigger and workflow side.

Sources

• github.blog/ai-and-ml/generative-ai/under-the-hood-security-architecture-of-github-agentic-workflows/

• github.github.com/gh-aw/introduction/architecture/

Source: strata.io/maverics-platform/identity-orchestration-for-ai-agents/ (commercial product; Strata is now part of Rubrik)

Intent

Provide an identity security control plane purpose-built for AI agents: discovery, registry, OAuth scope auditing, IDP binding, federated trust across clouds and platforms.

Motivating Problem

AI agents in an enterprise span many platforms: ChatGPT in Azure, LangChain in AWS, CrewAI on-premises, agents in GitHub Actions. Each has its own identity model; none of them surface to the security team as a coherent population. The Strata Agent Fabric makes the agent population visible: every agent gets discovered as it spins up, registered with its identity binding and scopes, categorized by risk, and audited like a human user.

How It Works

The Strata platform sits alongside the customer’s identity fabric (covering humans and IDPs) and app fabric (covering applications), connected through Identity Orchestration. Agents are discovered programmatically across LLM frameworks, API runtimes, CI/CD environments, and cloud-native services. Each discovered agent gets a registry entry tracking: agent identity in the IDP (Entra, Okta, CyberArk, Descope, Transmit, Auth0, Keycloak), scopes and permissions, intent and function, TTL and revocation, audit trails, risk level.

Federated trust is enforced via Identity Orchestration: when an agent in one cloud authenticates against a service in another, the orchestration layer evaluates the request against the agent’s scopes, the target service’s policy, and the current risk profile. Denied requests don’t reach the target service. Approved requests are logged with the full identity chain.

Strata frames the problem as three sibling fabrics (identity, app, agent), and the product is the commercialization of that framing; the 80× agent-growth figure is the vendor’s own forecast. Rubrik acquired Strata in June 2026 and sells the technology as part of its Identity Continuity offering, so product names and URLs may change.

When to Use It

Enterprises operating agents across multiple clouds and IDPs who need unified identity governance and audit. Cases where the security and compliance teams need a single source of truth about which agents exist and what they’re permitted to do. Industries with strict identity requirements (financial services, healthcare, government).

Alternatives --- cloud-vendor IDPs alone (Entra, Okta) when the agent population fits inside one platform; building your own registry on top of SPIFFE/SPIRE when the team prefers open-source self-hosting. The decision is mostly whether the commercial control plane is worth the cost relative to building.

Sources

• strata.io/maverics-platform/identity-orchestration-for-ai-agents/ (archived: web.archive.org/web/20261006163915/https://www.strata.io/maverics-platform/identity-orchestration-for-ai-agents/)

• strata.io/blog/agentic-identity/agent-fabrics-registries-central-2b/ (archived: web.archive.org/web/20260520095106/https://www.strata.io/blog/agentic-identity/agent-fabrics-registries-central-2b/)

• rubrik.com/company/newsroom/press-releases/26/rubrik-advances-identity-resilience-through-strata-acquisition-and-identity-roll-forward-innovation

Source: istio.io, linkerd.io

Intent

Use a standard service mesh (Istio, Linkerd, Consul Connect) to provide mTLS, traffic management, and observability for agent-to-agent and agent-to-service communication.

Motivating Problem

For agent fabrics on Kubernetes, the network sub-concern is mostly solved by adopting a service mesh that’s already running for the rest of the platform. mTLS between agents and services, traffic shifting for canary deploys of new agent versions, fine-grained authorization policies tied to workload identity --- the same patterns the service mesh provides for microservice traffic transfer directly to agent traffic.

How It Works

In sidecar mode, a proxy (Envoy in Istio, the Linkerd2-proxy in Linkerd) is injected into each agent pod and handles mTLS, observability, and policy enforcement. Istio can also run in sidecar-less ambient mode, with a per-node ztunnel for mTLS and optional waypoint proxies for layer-7 policy. Either way the agent code remains unaware of the mesh; identity, encryption, and routing are operational concerns of the mesh layer. SPIFFE-compatible meshes (Istio, Consul Connect) integrate cleanly with workload identity (Volume 12, Workload identity systems).

Specific agent-adjacent features are starting to appear: AuthorizationPolicies tied to OAuth scopes the agent holds; per-agent rate limiting; tail-sampled traces that capture the full inter-agent call chain. These are mostly natural extensions of existing mesh features. In March 2026 Istio announced experimental support for agentgateway as part of its data plane, which brings MCP- and A2A-aware routing into the mesh (see Agent gateway below).

When to Use It

Kubernetes-shaped agent fabrics where a service mesh is already running. Teams that want mTLS between agents without writing the certificate-management code themselves. Multi-cluster agent deployments where the mesh handles cross-cluster traffic.

Alternatives --- cloud-vendor mesh products when on a single cloud: Google Cloud Service Mesh, or on AWS, ECS Service Connect or VPC Lattice (AWS discontinued App Mesh on 30 September 2026). mTLS hand-rolled into each agent when the operational tax of a service mesh isn’t justified.

Sources

• istio.io

• linkerd.io

Source: github.com/agentgateway/agentgateway (Apache-2.0, Rust; Linux Foundation project)

Intent

Put a proxy that understands MCP and A2A between agents, tools and models, so authentication, authorization, rate limiting and tracing apply to agent traffic without being coded into each agent or MCP server.

Motivating Problem

A service mesh secures connections but sees agent traffic as opaque HTTP: it cannot tell which MCP tool an agent called or which A2A task it delegated, so policy stops at the service boundary. Teams end up hardcoding authentication, routing and monitoring into each agent and each MCP server. An agent-aware proxy moves those concerns into the data plane, where one policy covers every agent-to-tool, agent-to-agent and agent-to-model call.

How It Works

agentgateway runs standalone from a YAML config, or on Kubernetes with its own controller and Gateway API support. It has four gateway roles: an LLM gateway that routes to providers (OpenAI, Anthropic, Gemini, Bedrock and others) behind one OpenAI-compatible API, with budget controls and failover; an MCP gateway that federates tools across MCP servers over stdio, HTTP, SSE and Streamable HTTP, with OAuth authentication and OpenAPI integration; an A2A gateway for agent-to-agent calls with capability discovery; and inference routing to self-hosted models through the Kubernetes Gateway API Inference Extension. Across all of them it applies JWT, API-key and OAuth authentication, fine-grained RBAC written in CEL, rate limiting, TLS, guardrail filters, and OpenTelemetry metrics, logs and traces.

Solo.io created the project in March 2025, building on its work on the proxy for Istio’s ambient mode, and donated it to the Linux Foundation in August 2025. In March 2026 Istio announced experimental support for agentgateway as a component of the Istio data plane. It fills the gap between a generic service mesh (above) and overlay networks such as Pilot Protocol (below).

When to Use It

Agent fabrics where many agents share MCP servers or model providers and need one place for authentication, tool-level authorization and spend control. Kubernetes platforms already on Istio that want agent-aware routing in the mesh. Teams exposing internal MCP servers to agents outside the cluster.

Alternatives --- a plain API gateway or service mesh when per-tool policy is not needed. An LLM-only gateway (LiteLLM, as in the AWS Sample Agentic Platform) when only model traffic needs routing. AgentCore Gateway (Section A) when the fabric runs on Bedrock AgentCore.

Sources

• github.com/agentgateway/agentgateway

• agentgateway.dev/blog/2026-03-25-agentgateway-one-year-anniversary/

• cncf.io/announcements/2026/03/25/istio-brings-future-ready-service-mesh-to-the-ai-era-with-new-ambient-multicluster-gateway-api-inference-extension-and-more/

Source: IETF Internet-Draft draft-teodor-pilot-protocol (Experimental, individual submission); github.com/pilot-protocol/pilotprotocol (Go, AGPL-3.0)

Intent

Issue agents encrypted tunnels and virtual addresses so they can communicate across networks and clouds without exposing routable IPs or requiring traditional service-discovery infrastructure.

Motivating Problem

Agents that run on personal devices, behind NATs, or across multiple clouds face the same problem peer-to-peer applications have always faced: how do two agents talk to each other when neither is directly reachable. Service mesh products assume Kubernetes; cloud-vendor mesh products assume one cloud. The Pilot Protocol and similar proposals target the heterogeneous case: an agent on a developer’s laptop talking to an agent in a partner organization’s cloud, with neither side needing to expose a public IP.

How It Works

Each agent registers with a Pilot Protocol rendezvous service, which assigns it a virtual address (analogous to a Tailscale or Twingate address) and helps with NAT traversal. Traffic then flows directly between peers over encrypted UDP tunnels rather than through a relay. The pattern is essentially WireGuard-style mesh networking adapted for the agent-population shape.

Pilot Protocol is an individual Internet-Draft (draft-teodor-pilot-protocol-01, April 2026) from one author, with Experimental status and one Go implementation. It is a proposal, not a standard, and no independent adoption is documented. The entry is here for the pattern: give every agent a virtual address, route through an encrypted overlay, expose nothing on the public internet.

When to Use It

Heterogeneous agent deployments where agents span personal devices, multiple clouds, and partner organizations. Privacy-sensitive workloads where exposing agent IPs is unacceptable. Early adopters who can tolerate moving standards.

Alternatives --- Tailscale or Twingate for the same shape without agent-specific framing. VPN-and-firewall for the classic enterprise pattern. Wait-and-see when the use case isn’t pressing --- the category will consolidate.

Sources

• datatracker.ietf.org/doc/html/draft-teodor-pilot-protocol-01

• github.com/pilot-protocol/pilotprotocol

Source: Pattern from Strata and from the AWS Arbiter Fabric Index

Intent

Maintain a source of truth for which agents exist in the deployment, their identity bindings, scopes, intent, TTL, audit trail, and risk level.

Motivating Problem

Public tool registries solve the discovery half. The other half is the agent population itself: who are the agents running right now, who do they act on behalf of, what scopes do they hold, when do their tokens expire, what have they done. Without this, the agent population is invisible to security and operations. With it, the agent fabric becomes auditable and governable.

How It Works

The implementation depends on the platform. The Strata Agent Fabric provides this as a commercial product with a UI. The AWS Arbiter Fabric Index is the sample’s agent-register DynamoDB table (the AgentRegisterTable construct) tracking identity bindings, scopes, and capability metadata, with the Control-Surface Band reading from it on every dispatch. Roll-your-own options exist on top of any datastore.

The shape across implementations: a per-agent record with identity (bound to IDP), scopes (current OAuth grants), intent (“purchase assistant”, “build bot”), TTL (when the agent’s authorization expires), audit trail (recent actions), risk (computed from behavior). The registry is consulted by governance, by observability, by compliance reporting; it’s a hub artifact.

When to Use It

Any agent fabric serious enough to need governance and audit. Required for regulated workloads. Increasingly required for non-regulated workloads as agent populations grow past dozens.

Alternatives --- putting up with invisibility for prototypes and pilots. The registry is the foundational compliance artifact for production deployments.

Sources

• strata.io/blog/agentic-identity/agent-fabrics-registries-central-2b/ (archived: web.archive.org/web/20260520095106/https://www.strata.io/blog/agentic-identity/agent-fabrics-registries-central-2b/)

• github.com/aws-samples/sample-agentic-fabric (see the agent-register table in app/lib/fabricStack.ts)

Source: keda.sh (CNCF graduated; Apache-2)

Intent

Scale Kubernetes deployments up and down in response to external event sources (queue depth, message backlog, HTTP request rate) rather than CPU/memory metrics alone.

Motivating Problem

Agent fabrics on Kubernetes face a load shape that traditional HPA (Horizontal Pod Autoscaler) handles poorly: bursts of work arrive as events on a queue or stream, the pod count needs to follow the queue depth rather than CPU, and idle periods should scale to zero. KEDA solves this with a scaler-per-event-source model: a SQS scaler watches an SQS queue, a Kafka scaler watches a Kafka topic, a Cron scaler triggers on schedule, and so on. Pod counts follow the event source’s metric.

How It Works

A ScaledObject resource binds a Kubernetes deployment to one or more scalers. Each scaler watches an external metric source and reports the current value; KEDA scales the deployment according to the desired-pods-per-metric-value relationship. Scale-to-zero is supported (the deployment scales to zero replicas when there’s no work, then back up when new events arrive). Over 70 built-in scalers cover most cloud and on-prem event sources.

For agent fabrics: the trigger that activates an agent (from Vol 4) is often the same event source that should drive its scaling. A SQS-triggered worker agent should have its pod count follow the SQS queue depth, not its CPU. KEDA makes this declarative.

When to Use It

Kubernetes-based agent fabrics with event-driven workloads. Cases where the agent pool size should follow the work backlog. Scale-to-zero workloads (cost-sensitive deployments).

Alternatives --- HPA when the metric is CPU/memory-shaped. Cloud-specific autoscalers (AWS Application Auto Scaling, Azure Service Bus auto-scale) when not on Kubernetes. Manual sizing when the load is predictable.

Sources

• keda.sh

• github.com/kedacore/keda

Source: github.com/kubernetes-sigs/agent-sandbox (Kubernetes SIG Apps subproject; Apache-2.0)

Intent

Give each agent or code-execution session its own isolated, stateful pod with a stable identity and persistent storage, managed declaratively through a Sandbox custom resource.

Motivating Problem

Kubernetes handles stateless replicated apps (Deployments) and numbered sets of stateful pods (StatefulSets) well, but an agent runtime is neither: it is one long-lived, stateful environment per session or per user, often running untrusted LLM-generated code. Teams approximate it with a StatefulSet of size one, a Service and a PersistentVolumeClaim, which is cumbersome and has no lifecycle management such as pausing or hibernation. Agent Sandbox gives that shape a first-class API.

How It Works

The project adds a Sandbox CRD (agents.x-k8s.io/v1beta1) and a controller. A Sandbox wraps a pod template and gives the pod a stable hostname and network identity, optional persistent storage that survives restarts, and lifecycle management: creation, scheduled deletion, pausing and resuming. Extensions add SandboxTemplate for reusable definitions, SandboxWarmPool for a pool of pre-warmed sandboxes, and SandboxClaim for taking a sandbox from a warm pool, which cuts start-up time.

Agent Sandbox orchestrates sandboxes; it does not isolate them itself. It delegates kernel-level isolation to a sandbox runtime such as gVisor or Kata Containers, selected through RuntimeClass, so the isolation tier (Chapter 3) depends on the runtime chosen. Go and Python SDKs and a Sandbox Router (an HTTP reverse proxy to sandbox pods) let agents create and call sandboxes programmatically. Deep hibernation and automatic resume on network connection are stated goals rather than shipped features.

When to Use It

Kubernetes platforms that run untrusted agent code and want sandboxes inside their own cluster rather than a hosted service. Per-user or per-session agent runtimes that need persistent state and a stable address. Reinforcement-learning and evaluation loops that need many isolated environments quickly from a warm pool.

Alternatives --- hosted sandboxes (E2B, Modal; Volume 3) when running the substrate is not worth it. A StatefulSet of size one when isolation and lifecycle features are not needed. kagent (below) when the goal is managing agents rather than their execution sandboxes.

Sources

• github.com/kubernetes-sigs/agent-sandbox

• agent-sandbox.sigs.k8s.io

Example artifacts

Schema / config.

apiVersion: agents.x-k8s.io/v1beta1
kind: Sandbox
metadata:
  name: my-sandbox
spec:
  podTemplate:
    spec:
      containers:
      - name: my-container
        image: <IMAGE>

Source: kagent.dev; github.com/kagent-dev/kagent (CNCF Sandbox project; Apache-2.0, Go)

Intent

Run AI agents, their tools and the MCP servers they use as Kubernetes custom resources, so agents are defined in YAML, reconciled by a controller and managed with the same kubectl and GitOps workflows as the rest of the platform.

Motivating Problem

Platform teams already run workloads, policy, identity and observability through Kubernetes, but agent frameworks usually arrive as application code with their own deployment story. Each team then wires models, tools, session storage and tracing by hand, and the agent population sits outside the platform’s inventory. kagent makes the agent itself a Kubernetes resource, so the cluster records which agents exist, what tools they can reach and how they run.

How It Works

An Agent custom resource brings together behavior (a system prompt, tools, sub-agents and an LLM configuration, shareable through an AgentTemplate) and runtime configuration. A Harness picks how the agent runs: kagent’s own Go or Python ADK, Codex, Claude, or a custom runtime. Agents reach tools through RemoteMCPServer resources shared across agents; kagent ships an MCP server with tools for Kubernetes, Istio, Helm, Argo, Prometheus, Grafana, Cilium and others. Supported LLM providers include OpenAI, Azure OpenAI and Anthropic.

The controller watches these resources, prepares agents to run and manages their sessions, exposing gRPC, A2A and MCP APIs to clients; a substrate layer runs the agents and handles suspension, resumption and snapshots. PostgreSQL stores sessions, tasks and conversation history so they outlive the running agent, and OpenTelemetry traces cover agent, model and tool calls. A web UI and a CLI sit on top. kagent was accepted into the CNCF at the Sandbox maturity level on 22 May 2025.

When to Use It

Platform and DevOps teams that run Kubernetes and want agents managed as cluster resources under GitOps. Operations agents that act on the cluster itself through the bundled Kubernetes, Istio and Prometheus tools. Fabrics that want A2A and MCP endpoints for agents without building the hosting layer.

Alternatives --- AWS Bedrock AgentCore (Section A) for a managed, non-Kubernetes runtime. Agent Sandbox (above) for isolated execution environments without the agent abstraction. A framework such as LangGraph deployed as ordinary pods when the cluster does not need to know about agents.

Sources

• kagent.dev

• github.com/kagent-dev/kagent

• cncf.io/projects/kagent/

Appendix A --- Fabric Sub-layer Reference Table

Cross-reference between the five fabric sub-layers and their representative technologies. Use this to quickly orient on which component answers which question.

Appendix B --- The Series

This catalog completed the original five-volume series, which describes agentic AI at five levels of abstraction; the series has since grown to nineteen volumes. Read top-down (Vol 1 → Vol 5) for the conceptual flow; read bottom-up (Vol 5 → Vol 1) for what an architect builds first.

• Volume 1 --- Patterns of AI Agent Workflows --- the temporal patterns by which LLM calls, tools, and sub-agents compose. The vocabulary for how an agent run is structured in time.

• Volume 2 --- The Claude Skills Catalog --- the SKILL.md-format instruction packs that tell the model when and how to use tools. The vocabulary for the model’s domain knowledge.

• Volume 3 --- The AI Agent Tools Catalog --- the function-calling primitives that the agent invokes. The vocabulary for what the agent can do.

• Volume 4 --- The AI Agent Events & Triggers Catalog --- the mechanisms by which agents are activated. The vocabulary for what makes the agent run.

• Volume 5 --- The AI Agent Fabric Catalog (this volume) --- the infrastructure substrate beneath orchestration. The vocabulary for where the agent lives.

The five levels are independent but composable. A production agent system makes choices at all five: a pattern (e.g. evaluator-optimizer from Vol 1), the skills that load when relevant (Vol 2), the tools the agent invokes (Vol 3), the events that trigger the agent in the first place (Vol 4), and the fabric on which all of it runs (this volume). Re-reading the prior volumes through the fabric lens is recommended once: most operational concerns documented across the series ultimately resolve to fabric properties.

A second observation worth keeping: the five layers don’t evolve at the same rate. Patterns are essentially stable (the same evaluator-optimizer loop will look much the same in 2027). Skills, tools, and events evolve quarterly. Fabric --- especially the identity and governance sub-layers --- is where the most active design work is happening in 2026, and where the catalog is most likely to be partially obsolete within a year. Plan for evolution at the fabric layer; expect stability above it.

Appendix C --- The Constitutional Substrate Pattern

The Architecting Autonomy series by Aaron Sempf (aaronsempf.substack.com; the site returned HTTP 404 as of October 2026), which produced the AWS Sample Agentic Fabric, articulates a design pattern worth abstracting from the AWS specifics. The pattern can be applied to any agent fabric regardless of cloud or framework choice; the four governance primitives carry over directly.

1. Authority as a first-class primitive --- not an afterthought. Every action an agent can take must trace back to an explicit Authority Scope. Implicit permissions accumulate ungoverned overreach; explicit permissions surface as denied requests when they’re missing, which is a feature.

2. Deterministic governance, not LLM-based oversight. The mechanism that decides what’s allowed should be a small, auditable, deterministic engine --- not another LLM. LLMs are appropriate for many things; deciding whether an action is authorized is not one of them.

3. Residual authority defaults to denial. Actions not covered by an Authority Scope are denied. The operational friction of “surfacing every gap” is the price of structural correctness.

4. Write-once audit (the Legibility Ledger). Every governance decision --- permit, deny, escalate --- is logged immutably. Compliance, debugging, and the case-law mechanism all depend on this artifact.

5. Case law for evolution. Conflicts the engine can’t resolve escalate to humans; the resolution is encoded as case law and applied deterministically on recurrence. The system’s governance improves through accumulated cases rather than through code changes.

The pattern is one design philosophy among several; it’s not the only valid answer. But the four primitives --- Authority Scopes, Composition Contracts, Arbitration Patterns, Legibility Ledger --- are sufficiently universal that any agent fabric serious about governance should have analogues, whether or not it adopts the names. The AWS Arbiter source (src/governance/) is the recommended reference implementation to study.

Appendix D --- Further Reading and Discovery

Hubs, lists and related projects that are not patterns in their own right:

• mfornos/awesome-agentic-ai (github.com/mfornos/awesome-agentic-ai) - a small link list started in January 2026, covering standards such as MCP and A2A and sandboxes such as E2B and Modal.

• kyrolabs/awesome-agents (github.com/kyrolabs/awesome-agents) - a general list of agent projects (frameworks, testing, software development, research, memory, automation); Pilot Protocol is one line under Frameworks.

• Azure Agentic App with Fabric (github.com/Azure-Samples/agentic-app-with-fabric) - a banking demo app showing OLTP, OLAP and LangGraph agents side by side on Microsoft Fabric, Microsoft’s analytics platform, set up through a dev container. Despite the name, it is unrelated to agent fabric.

• LifeOS, formerly Personal AI Infrastructure (github.com/danielmiessler/LifeOS) - Daniel Miessler’s installable personal AI harness built on Claude Code, with an identity layer, goals (TELOS), memory and skills kept as plain files.

• Fabric (github.com/danielmiessler/fabric) - Daniel Miessler’s CLI prompt library, unrelated to agent fabric despite the name: 260+ patterns, each a directory with a system.md prompt, with input on stdin (cat my_document.md | fabric —pattern summarize). For prompt libraries as a pattern, see Volume 15, Prompt registries and versioning.

• GitHub Topic: agentic-orchestration --- the official tag aggregating new orchestration repos; relevant to the fabric layer when the orchestrator dictates fabric choices.

• CNCF Cloud Native AI Landscape --- the CNCF’s map of cloud-native AI projects; useful for the substrate-as-CNCF-project view.

• Cloud-vendor reference architecture catalogs --- aws.amazon.com/architecture, learn.microsoft.com/azure/architecture, cloud.google.com/architecture --- increasingly include agent-specific reference designs.

Three pragmatic rules. First, the fabric layer moves faster than any one list can track --- use lists for discovery, then go to the source repository to evaluate currency. Second, agent fabric is the part of the stack where vendor incentives create the most lock-in risk; prefer projects with portable identity and observability stories even if specific compute choices are vendor-specific. Third, governance and identity are where investment compounds; investing in either pays off across many agent generations, while specific compute choices tend to be replaceable.

Appendix E --- Omissions

This catalog covers 13 substrates across six sections; general-purpose sandboxes and the MCP Registry are covered in Volumes 3 and 9, and workload identity and OAuth patterns in Volume 12. The agent fabric ecosystem is wider; a non-exhaustive list of what isn’t here:

• General Kubernetes and cloud-native infrastructure (Helm, ArgoCD, Crossplane, Terraform) when used without an agent-specific framing. The patterns transfer but the agent-specific angles don’t.

• Standalone IDPs (Okta, Entra, Auth0, Keycloak, CyberArk, Descope, Transmit) as products. They’re components of agent-fabric solutions but the IDP itself isn’t the agent-fabric story.

• Service mesh products in isolation (Istio, Linkerd, Consul Connect) when the agent angle is minimal. They appear in Section D as fabric components, not as standalone entries.

• Closed agent platforms that bundle the fabric with a product surface (OpenAI Assistants, Anthropic Managed Agents, vendor-specific copilot platforms). The fabric properties are real but inaccessible separately.

• Specialized agent fabrics for niche compute (edge agents, mobile agents, IoT agents). Each has its own substrate considerations; the patterns transfer but the inventory is large.

• Vendor-specific identity products in the agent space (Auth0 Fine Grained Authorization, Cerbos, OPA-as-a-product) when Volume 12’s OAuth-for-agents entry covers the architectural concept.

Appendix F --- A Note on the Moving Target

Anthropic published MCP in November 2024. The Linux Foundation’s AAIF took over MCP governance in December 2025. AWS published the Sample Agentic Fabric (Arbiter) in 2026. Microsoft’s Agent Framework reached 1.0 general availability in April 2026. Strata published its Agent Fabric framing in mid-2025, and Rubrik acquired Strata in June 2026. The Constitutional Substrate design pattern is months old as of this writing. The category is moving fast; this catalog captures a snapshot in mid-2026.

The deepest structural fact to internalize: the five sub-layers --- compute, identity, network, registry, sandbox --- are stable even though specific implementations move. An agent fabric always answers the same five questions about where agents run, who they are, how they talk, how they’re found, and how they’re contained. Choose well at each sub-layer and the specific product becomes replaceable.

Combined with the first five volumes of the series --- Patterns, Skills, Tools, Events, Fabric --- a working architect now has the vocabulary to talk about agentic AI at every layer: timing, instruction, primitive, activation, substrate. The technical landscape will keep shifting; the conceptual vocabulary will not.

--- End of The AI Agent Fabric Catalog v0.1 ---

— The Agentic AI Series —