--- title: "Build AI Agents with Coder. Deploy Them with Amazon Bedrock AgentCore. - Blog - Coder" description: "AI agents are reshaping software development, but the infrastructure used to build agents is different from the infrastructure used to run them in production. This post explains how Coder and AWS Bedrock AgentCore support distinct stages of the AI lifecycle." image: "https://www.datocms-assets.com/19109/1778615446-agentcore-blog-thumbnail.png?fit=clip&fm=webp&w=800" canonical: "https://coder.com/blog/build-ai-agents-with-coder-deploy-them-with-amazon-bedrock-agentcore" --- May 20 20266 min read # Build AI Agents with Coder. Deploy Them with Amazon Bedrock AgentCore. [Matt Vollmer](https://coder.com/blog/author/matt-vollmer) Share this article ## How Coder and AgentCore support different stages of the AI development lifecycle AI agents are appearing across most parts of the development lifecycle, and the line between how agents are built, used, and deployed is understandably ambiguous. On one side, there are agents that help developers generate code. On the other, there are agents that get deployed to production, so end users can interact with them. These are fundamentally different needs, solved by different infrastructure. This post breaks down where Coder and AgentCore fit within the AI software lifecycle, and how the two platforms reinforce each other rather than compete. ## Let’s start with a use case ![Coder and AgentCore](https://www.datocms-assets.com/19109/1778614646-agentcore-1.png) A [financial services company](https://coder.com/success-stories/financial-services) wants to build a hypothetical AI-powered customer service chatbot. Customers will interact with it on the company's website to check account balances, ask questions about transactions, and get help with common requests. Before a chatbot can serve a single customer, someone has to build it. A developer needs a development environment with access to the company's codebase, internal APIs, and the right dependencies. They need to write the logic, test it, iterate, and get it reviewed. In a regulated enterprise, that development work doesn't happen on a developer's laptop. Source code doesn't live locally. The company centralizes development in governed environments where the platform team establishes access controls, network policies, and audit trails. That's what Coder does. ## Coder: Where the agent is developed ![Coder and AgentCore](https://www.datocms-assets.com/19109/1778614646-agentcore-2.png) [Coder](https://coder.com/docs/about) is an open-source platform for centralizing development environments on self-hosted infrastructure. While Coder is cloud-agnostic, many enterprises run it on [AWS infrastructure](https://aws.amazon.com/marketplace/pp/prodview-34vmflqoi3zo4) using services such as EC2 and EKS. Platform teams use Terraform templates to define standardized environments, and developers connect using their preferred tools, whether that’s VS Code, JetBrains, Cursor, or a web terminal. With Coder, developers can also use AI coding agents to delegate code generation work. If the idea of using agents to build other agents isn’t too meta, [you can skip ahead](#how-enterprises-operate-coding-agents-with-coder) to learn how Coder helps enterprises safely distribute coding agents to their developers. Getting back to our use case: the developer working on the customer service chatbot gets a Coder workspace with everything pre-configured, including the right language runtimes, access to internal APIs, credentials managed by the platform team, and network policies that keep source code inside the perimeter. They connect to the workspace and start building. The chatbot takes shape as the developer writes the agent logic, integrates it with the company's backend systems, and evaluates it against sample conversations. All of this happens inside Coder self-hosted workspaces. But at this point, the chatbot exists only in a development environment. It can't serve real customers. It needs to be deployed somewhere that's built for production workloads -- scalable, observable, and accessible to the outside world. ## AgentCore: Where the agent is deployed ![Coder and AgentCore](https://www.datocms-assets.com/19109/1778614646-agentcore-4.png) [Amazon Bedrock AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/) is a serverless platform for deploying and operating AI agents in production. It handles the infrastructure that the hypothetical customer service chatbot needs to run at scale: - Secure runtime with session isolation - Identity management so agents can authenticate with enterprise systems - Memory so agents retain context across conversations - Tool integration via MCP - Observability to monitor agent behavior at scale. These types of agents are typically short-lived, request-driven workloads. A customer opens a chat session, interacts with the agent for a few minutes, and the runtime scales up or down as needed. The same pattern applies to many production AI services, such as customer support assistants, internal helpdesk agents, ecommerce shopping assistants, travel booking agents, or automated banking workflows. When the developer's chatbot is ready, it gets deployed to AgentCore. Now it's no longer running in a Coder development environment. It's running in a production environment where thousands of customers can interact with it simultaneously. AgentCore manages the scaling, isolates each customer session in its own microVM, handles authentication, and gives the operations team visibility into how the agent is performing. The developer built the customer service agent in Coder. The agent runs in production on AgentCore. ## Different Roles in the AI Lifecycle This distinction matters because the market conversation often blurs "agents" into a single category. The infrastructure a developer needs to build an agent is fundamentally different from the infrastructure that agent needs to serve end users. | | Coder | AgentCore | | --- | --- | --- | | **Purpose** | Where agents (and all software) are built | Where agents get deployed and operated | | **Users** | Developers and platform teams | End users/customers, operations teams | | **Environment** | Development workspaces | Production runtime | | **Core concern** | Source code security, developer productivity, environment governance | Scalability, session isolation, production observability | | **Lifecycle stage** | Development | Deployment | The more AI applications developers build inside environments like Coder, the more those applications eventually need production runtimes where they can be securely deployed, operated, and scaled. A customer support chatbot developed in a Coder workspace may later be deployed to AgentCore. The same is true for internal copilots and other automated workflows. In that sense, development infrastructure and runtime infrastructure naturally reinforce one another. As organizations accelerate AI development workflows, both layers become increasingly important. ## How Enterprises Operate Coding Agents with Coder As coding agents become part of everyday software development, enterprises need more than access to the tools themselves. They use Coder as a secure and standardized way to govern and scale those agents across their development environments. Your browser does not support the video tag. Coder Agents is a conversational interface that developers use to collaborate with self-hosted coding agents Some organizations will use [Coder Agents](https://coder.com/docs/ai-coder/agents), Coder’s native agent experience that allows developers to delegate tasks to agents directly from the Coder platform using [any AI model](https://coder.com/docs/ai-coder/agents/models), including those provided via AWS Bedrock. Developers can ask agents to generate code, run tests, research changes, and prepare work for review, all while operating against governed development environments running on infrastructure the organization controls. Other organizations may choose to run [third-party coding agents](https://registry.coder.com/modules?search=tag%3Aai) such as Kiro, Claude Code, OpenAI Codex, Cursor, or Windsurf directly inside Coder workspaces. In this model, Coder provides the underlying self-hosted infrastructure layer where both developers and coding agents securely access source code, development tools, internal systems, and compute resources together. As AI adoption grows, governance becomes increasingly important. Coder’s [AI Governance](https://coder.com/docs/ai-coder/ai-governance) capabilities, including AI Gateway and Agent Firewall, help platform and security teams govern how coding agents interact with models, source code, enterprise systems, and development environments. Regardless of which coding agents an organization adopts, the core distinction remains: development still happens inside platforms like Coder, while production deployment happens on platforms like AgentCore. ## From Development to Deployment Coder and AgentCore occupy different parts of the software development lifecycle. Coder is where agents get built. AgentCore is where agents get deployed. One generates demand for the other. As AI coding agents accelerate how fast developers can produce software, the pipeline from development to production moves faster. More agents built means more agents deployed. The infrastructure on both sides of that pipeline has to be ready. To learn more about building and governing AI-powered development environments with Coder, [explore the docs](https://coder.com/docs) or [get started](https://coder.com/docs/tutorials/quickstart) with Coder today. ### Subscribe to our newsletter Want to stay up to date on all things Coder? Subscribe to our monthly newsletter for the latest articles, workshops, events, and announcements.