← Back to Blog
AI Architecture

Agentic AI Development Architecture Diagram on AWS: Local Emulation to Preview Environments

The March 26, 2026 post Architecting for agentic AI development on AWS, by Alan Oberto Jimenez, is design guidance, not a case study. An agent that writes and tests code needs a local loop, a small cloud check when nothing local exists, and a short-lived preview stack. The diagram is that path plus the repository shape.

Agentic AI Development Architecture Diagram on AWS: Local Emulation to Preview Environments
Laptop local emulation goes to a minimal SNS/SQS stack (CloudFormation or CDK), then an IaC preview with smoke tests and delete, then production CI/CD. Failed tests return on dashed arrows. The repo callout is /domain, /application, /infrastructure, .kiro/steering/, AGENT.md, RUNBOOK.md, and CONTRIBUTING.md. No AgentCore.

What this agentic AI development architecture diagram AWS shows

Four columns, left to right. A developer laptop runs emulators and unit tests. A narrow hybrid column deploys only the AWS APIs that have no local stand-in. A preview column is a full stack from infrastructure as code, used for smoke tests, then deleted. Production sits at the right, fed by a pipeline the post says should still require tests, automated review, and branch protection, with a person on high-impact decisions. Failed smoke tests return from the preview to the laptop. Failed production tests return to the preview box, not to the laptop. The post’s figure caption calls this local test loops, an ephemeral test stack, and a CI/CD pipeline triggered by AI.

The problem this architecture is solving

The post says most cloud layouts assume long-lived environments, manual testing, and rare deploys. An agent that must validate continuously stalls when every check waits on a pipeline or on a bug that appears only after deploy. It also says tight coupling between business rules and cloud APIs blocks local tests, and uneven repositories hide where a change goes. The proposed fix is not a better prompt. It is a default path that stays on the laptop, with the cloud used on purpose.

Main components and trust boundaries

Local tools the post names: AWS SAM’s sam local start-api for Lambda functions behind an emulated API Gateway; the same container image you would run on Amazon ECS or Fargate, started locally; Amazon DynamoDB Local for create, read, update, and delete calls against the DynamoDB API. For data jobs, AWS Glue’s Docker images so an agent can run ETL libraries on a sample and inspect intermediate rows before a cloud scale test. The post says the same idea applies to other data and ML jobs: isolate the logic, test on reduced data, promote later. It does not name those other services.

Where there is no emulator, the post points at Amazon SNS and Amazon SQS. The agent deploys a minimal stack with AWS CloudFormation or the AWS CDK, calls it through the AWS SDK, and avoids a full environment. Preview environments are separate: an on-demand copy of the application, smoke-tested, then torn down. Contract-first design, in this post, means OpenAPI specs written first so an integration can be checked before every service exists.

The post suggests /domain with no AWS imports, /application for orchestration, and /infrastructure for DynamoDB, SNS, and other adapters. Hexagonal architecture is the same idea. Kiro files under .kiro/steering/ state rules, such as database access only through repository classes. It also names AGENT.md, RUNBOOK.md, and CONTRIBUTING.md, and prefers YAML to long prose. A monorepo is recommended so the agent can see shared patterns. Those filenames are this article’s examples, not a separate AWS standard.

Request or data path, step by step

The agent edits domain code and runs unit tests, which the post calls the fast loop. Contract tests check that a service still matches the agreed interface. If the change is a Lambda or container behavior, the local emulator or local container is the next stop. The post says this validates AI-generated code in seconds rather than minutes and can potentially cut the cost and risk of experimenting. “Seconds rather than minutes” and “potentially” are the article’s own hedges. Do not turn them into a stopwatch result.

A Glue-style change uses the local Docker image and a sample dataset. An SNS or SQS change deploys the small stack, invokes it, and stops. An end-to-end change deploys the preview stack, runs smoke tests, and deletes it. Smoke tests are where the post expects IAM and configuration failures to show up, because those do not appear in a unit test. Only then does the delivery pipeline promote the change. The post says autonomy can grow later, but humans stay on high-impact decisions. It does not define which decisions those are.

The diagram: labeled boxes and failure or isolation edges

Keep the laptop, the minimal cloud stack, the preview stack, and production as separate trust zones. The dashed arrows are failed smoke tests from the preview back to the laptop, and failed production tests from production back to the preview. They are not a second data plane.

  • No cloud yet: domain tests and SAM, container, DynamoDB Local, or Glue Docker stay inside the laptop boundary.
  • Hybrid only when required: SNS or SQS get a small CloudFormation or CDK stack. The diagram does not show the rest of the account.
  • Preview dies: the post says the stack is torn down after smoke tests.
  • Pipeline gate: required tests, automated review, branch protection. The box says Human on high-impact. There is no separate edge for that box, and the post does not list the cases.

What the source does not claim (preview, case study, or limits)

This is evergreen architecture advice dated March 26, 2026, tagged intermediate, with Kiro in the byline topics. It is not a preview, a beta, or a customer result. It publishes no error rates, no dollar savings, and no team-size claim. Local emulation “reduces iteration time” only as a note under the pattern, not as a measured study. The Well-Architected Agentic AI Lens is not mentioned, so it does not belong on this drawing. Neither do Amazon Bedrock AgentCore, a specific model, or a production runtime diagram. Glue local images are for early checks; the post still sends scale tests to the cloud.

How this differs from a nearby pattern on ByteDiagram

The AgentCore diagram is a managed runtime: sessions, memory, a gateway, and policy around a running agent. This March 2026 post never names AgentCore. It is the development loop that produces code, from emulators to a preview stack. Gateway and Memory boxes are not on the laptop column.

FAQ

Which AWS tools does the March 26, 2026 post name for local agent tests?

AWS SAM with sam local start-api for Lambda and API Gateway, the same container image used for ECS or Fargate, DynamoDB Local for CRUD, and AWS Glue Docker images for ETL against a sample. SNS and SQS are the examples that still need a small CloudFormation or CDK stack.

What is a preview environment in this post?

A short-lived stack defined in infrastructure as code, deployed so an agent can run smoke tests, then torn down. The post pairs that with OpenAPI contracts so integrations can be checked before every service is implemented. It does not give a lifetime or a cost figure.

Does this architecture post specify Amazon Bedrock AgentCore or a Well-Architected lens?

No. The page is about feedback speed, repository layers, Kiro steering files, and CI/CD guardrails. It does not describe AgentCore, Memory, a Gateway, or a Well-Architected Agentic AI Lens. Those are outside this diagram.

Conclusion

Show the laptop emulators first, then a minimal SNS or SQS stack, then an IaC preview that is deleted, then production behind tests and a human gate. Keep “seconds rather than minutes” as the post’s wording. The only source is Architecting for agentic AI development on AWS. More diagrams are on the ByteDiagram blog.

Diagram the agent feedback loop on AWS

Separate local SAM, containers, and DynamoDB Local from the small cloud stack and the preview environment that gets torn down.

Open Diagram Editor