Agentic AI FactoryGitHub

Concepts

Architecture

The repository map, the two reference diagrams of the Enterprise Agentic AI Platform Blueprint (the Blueprint), and the architecture figures the Workshop and Self-Service projects publish. Each project diagram shows where Amazon Bedrock AgentCore sits in that design, and every diagram is labelled with the project it belongs to.

Agentic AI Factory Atlas: four complementary projects for enterprise agentic AI on AWS. In the centre sits a hub labelled Agent Factory Capabilities: LLM Gateway, Tool Gateway, Identity and Registry, Policy and Observability. Around it, four stages in order. Learn: Workshop, hands-on platform patterns. Build: Visual Workflow Platform, drag-and-drop agent builder. Govern: MCP Governance Gateway, per-tool-call authorization. Scale: Enterprise Blueprint, multi-account reference blueprint. A legend distinguishes the sequential journey path, a skip-ahead path, and the shared-capability links from each project to the hub. A footer reads: Each project is self-contained. Start anywhere based on your role and goals.

The repository at a glance

The atlas in the page header shows the four projects in their Learn, Build, Govern, Scale order around the capabilities they share. The figure uses its own labels: it calls the Self-Service project the Visual Workflow Platform and the Blueprint the Enterprise Blueprint. The list below carries the same information as text, with the names this site uses.

The same map as a list:

  1. 1. LearnWorkshop Learn the platform patterns hands-on
  2. 2. BuildSelf-Service Build and ship agents visually
  3. 3. GovernMCP Gateway Govern every tool call
  4. 4. ScaleBlueprint Evaluate the enterprise reference

Shared capabilities hub: LLM Gateway, Tool Gateway, Agent Runtime, Agent Memory, Identity, Registry, Policy Engine, Delivery, Observability, Cost.

Blueprint: two reference diagrams

Both figures belong to the Blueprint. Its README explains that Figure 1 is the operating-model view: people, ownership, shared capability planes, repeatable cells, and governed flows. Figure 2 is the AWS reference-implementation view: the concrete services the repository deploys and the numbered release and run cycle used by its live evidence. Source: README.md: Two complementary architecture views.

Enterprise Agent Factory operating model and governed flow: enterprise governance, people and ownership, an Agent Factory control plane, and repeatable isolated Workstream cells connected by software delivery, inference, tool, telemetry and governance flows.
Figure 1 (Blueprint). Enterprise operating model and governed flow. AWS labels illustrate the repository's reference choices; the capability boundaries are the architecture. Open the editable Draw.io source
Enterprise Agent Factory AWS service-level reference architecture: Management, Security, Observability, Platform and repeatable Workstream accounts; the AWS services mapped to each capability; and numbered software delivery, identity, inference, tool and telemetry flows.
Figure 2 (Blueprint). AWS service-level reference implementation. Account IDs are documentation placeholders. Open the editable Draw.io source

Workshop: the landing-zone pattern and the LLM Gateway

The Workshop opens with the first diagram in Module 1. It is the multi-account pattern the modules teach; the self-paced deploy script stands up the Platform-account pieces in a single account. Module 2 adds the second diagram, the LLM Gateway that the workshop deploys as a LiteLLM proxy.

Workshop platform architecture: a multi-account AWS landing zone. An AWS Organization holds governance accounts (Management with Organizations, Control Tower and IAM Identity Center; Log Archive with organization CloudTrail, WORM S3 and Bedrock invocation logs; Audit with Security Hub, GuardDuty, Config, Inspector and CloudWatch OAM). A central Platform account hosts the auth boundary (API Gateway, WAF, Cognito), Bedrock AgentCore (Gateway, Registry, Cedar), the inference gateway (LiteLLM on ECS Fargate), and security and cost controls (Guardrails, CUR, KMS). Per-application Workload accounts run AgentCore services, agent blueprints, RAG and knowledge stores, and PrivateLink egress. A CI/CD pipeline runs from source through build and test, non-production deploy, an evaluation gate, a canary stage, production, and a teardown test.
Workshop (Module 1). Agentic AI platform architecture: governance accounts, a central Platform account, per-application Workload accounts, and the CI/CD pipeline. Source page.
LLM Gateway architecture in one AWS region. Tenant clients reach the gateway through distribution options (Amazon CloudFront or Route 53), AWS WAF and an Application Load Balancer with an ACM certificate. Inside a cluster VPC, an ECS cluster or EKS cluster runs API middleware tasks and the LiteLLM proxy, pulling images from Amazon ECR and reading credentials from AWS Secrets Manager. LiteLLM routes requests to AWS model providers (Amazon Bedrock, Amazon Nova, Amazon SageMaker AI) and to external model providers (OpenAI, Anthropic, Vertex AI, Cohere), stores state in Amazon RDS and Amazon ElastiCache for Redis OSS, and writes logs to Amazon S3. Numbered steps mark the request path from client to model provider.
Workshop (Module 2). LLM Gateway architecture, shown under the heading "Why an LLM Gateway?": a LiteLLM proxy on ECS or EKS behind WAF and a load balancer, routing to AWS and external model providers. Source page.

Self-Service: platform architecture

The Self-Service project (AgentCore Visual Workflow Platform) publishes this diagram in its README: the serverless control plane, the Step Functions deployment pipeline, and the resources the pipeline creates for each agent.

AgentCore Visual Workflow Platform architecture in one AWS region. A React single-page app served by CloudFront and S3 calls API Gateway. Lambda workflow and deployment APIs store workflows, flows and deployments in DynamoDB and start a Step Functions deployment pipeline. Cognito, IAM, CloudWatch and Systems Manager provide identity, permissions, logs and configuration; a single CDK stack deploys everything and a CloudFormation export is available. The pipeline runs steps such as validate, guardrails, MCP server, knowledge base, gateway, memory, policy, code generation, IAM role, runtime configure and launch, evaluation, JWT auth and status update. For each agent it creates an Agent Runtime, an MCP Gateway with JWT auth, an MCP Server Runtime, tool Lambdas, AgentCore Memory, Knowledge Base, Evaluation, Policy and Observability, and a per-agent Cognito user pool.
Self-Service (AgentCore Visual Workflow Platform). Architecture from the project README. Source section. Open the editable Draw.io source

Concepts from the Blueprint

The three ideas below come from the Blueprint's README and describe the Blueprint only. The Workshop, Self-Service and MCP Gateway projects do not use them.

Four planes

The Blueprint treats the Agent Factory as a product with four planes:

  1. Developer experience planeVersioned agent templates, CLI and repository workflows, approved extension points, and self-service onboarding.
  2. Platform control planeRegistry governance, model and Guardrail policy, shared inference, release orchestration, and reusable account baselines.
  3. Workstream execution planeIsolated cells containing team-owned Runtime, Memory, Tool Gateway, tools, and application data.
  4. Assurance and operations planeOrganization policy, evidence gates, fleet telemetry, audit, incident response, quota management, and chargeback.

Source: README.md: 1. Overview

Workstream cells

The unit of scale is a workstream cell, not a manually configured agent. A cell can represent a product, business domain, regulated boundary, or portfolio team. Each cell is an isolated execution boundary with a team-owned repository and Workload pipeline, stable IAM roles, and nonproduction and production AgentCore Runtime and Memory. It also holds an AWS_IAM Tool Gateway, Registry-approved targets, team-owned tools and data, local alarms, budgets, KMS keys, tags and retention policy, and an OAM link into the observability plane. A cell can deploy, roll back, or fail without another team coordinating its release.

Source: README.md: 2.3 Repeatable Workstream cell

Four governed flows

  1. Software delivery flowFrom pull request through source, build and synth, policy and image gates, stable roles, the permission handoff, nonproduction, deployed-runtime evaluation and human approval to production. No direct developer deployment path writes into a Workstream account.
  2. Inference flowA governed LLM Gateway sits between agent workloads and model providers. The agent obtains a short-lived token through AgentCore Identity and Cognito M2M, calls the AgentCore Gateway inference endpoint, a request interceptor applies the stage Bedrock Guardrail, and the Gateway role invokes only an allow-listed Bedrock model.
  3. Tool flowA governed Tool Gateway sits between agents and enterprise actions. AgentCore Gateway authenticates the Runtime role with AWS_IAM, targets come from approved Registry records, and the Gateway role invokes only subscribed Platform Lambda aliases. AgentCore PolicyEngine can enforce per-tool policy, with the Lambda Cedar wrapper as rollback and defense in depth.
  4. Telemetry and assurance flowEvery cell emits common logs, metrics, traces, deployment evidence and allocation dimensions. OAM links make Platform and Workstream telemetry queryable from Management, and CloudTrail plus retained audit data corroborate control-plane actions.

Source: README.md: 2.4 Four governed flows