The Agent Factory

The Agent Factory concept

An AI Agent Factory is the people, patterns, and platform that let an organization turn ideas into production agents reliably and at scale. The hard part is everything around the model: governed access, reusable tools, security and authorization, observability, and a repeatable way to ship agents to production.

This repository's README describes its four projects as enterprise samples for building, governing, and operating agentic AI on AWS, centered on Amazon Bedrock and Amazon Bedrock AgentCore (README introduction (opens in new tab)). Together, it says, they show how enterprises move from learning to agent operations at scale (What This Is (opens in new tab)).

How this site groups the four projects

This grouping is this site's reading of the repository, not a structure the project READMEs use. It exists to show which project answers which need.

How an engineer ships an agent (Blueprint)

The Enterprise Agentic AI Platform Blueprint (the Blueprint, in the rest of this page) describes this flow in its README. It is the Blueprint's pull-request-and-pipeline path; the other three projects ship an agent differently, as the next section shows. Step titles below are the README's own and the first step is quoted; the other descriptions are condensed. Source: README.md: 1.2 How an engineer ships an agent (opens in new tab).

1. Discover a paved road. Select a task, chatbot, supervisor/worker, LangGraph, or CrewAI template maintained by the platform team.
2. Create in a team-owned repository. The template supplies approved Gateway clients, prompt and tool extension points, an evaluation corpus, and a metadata contract.
3. Select governed capabilities. Models come from the Platform allow-list. Tools come from approved Registry records. Guardrail profiles come from the supported catalog.
4. Open a pull request. Source review, static checks, manifest hashing, image scanning, policy validation, and evaluation run before deployment.
5. Deploy to the Workstream cell. The pipeline creates stable roles, completes the Platform permission handoff, and deploys nonproduction resources.
6. Prove behavior. The deployed Runtime is exercised with authorized and adversarial twins. Quality, tool success, refusal, latency, cost, rollback, and telemetry gates fail closed.
7. Approve production. A human reviews evidence rather than a generic "pipeline succeeded" signal.
8. Operate with the fleet. The team owns its application SLOs and data; the platform team owns shared service health and common controls.

In the Blueprint, the Platform team is not in the application deployment loop. It owns the contracts that make independent deployment safe.

How each project actually ships an agent

• Learn

  Workshop

  Nothing ships through a pipeline. You work in the browser-based Code Editor IDE that the workshop provisions and run each module section either as a CLI walkthrough or as a notebook. The final module deploys a FAST travel agent onto AgentCore Runtime with the AWS CDK from inside that IDE.

  Hands-on time: 1.5 to 4 hours depending on the track (source (opens in new tab))

• Build

  Self-Service

  You design the agent on the drag-and-drop canvas, optionally starting from a template, and press Deploy. A Step Functions pipeline validates the workflow, generates the code, creates the IAM role, deploys the AgentCore Runtime and runs an evaluation step. Versioning and rollback are built in.

  First deploy of the platform: Roughly 15 to 20 minutes for a first-time deploy (source (opens in new tab))

• Govern

  MCP Gateway

  There is no agent to ship. You run cdk deploy once for the gateway stack, seed the demo users, mint a JWT and connect an MCP client such as Kiro or Claude Code. From then on every tool call from that client passes through the gateway, its Cedar policies and its interceptors.

  First deploy: About 5 minutes for the five quickstart steps; the gateway stack itself takes about 2 minutes (source (opens in new tab))

• Scale

  Blueprint

  Agents ship through the Blueprint flow above: a golden-path template in a team-owned repository, a pull request, and a Workload pipeline that deploys to the Workstream cell, proves behavior against authorized and adversarial twins, and waits for a human approval before production.

  First deploy: not documented

The projects are independent. Each is self-contained with its own deployment instructions and can be adopted in any order; none requires another to be deployed first (root README (opens in new tab)). To pick one, use Which project is for me.