Amazon Bedrock or AgentCore: Which Architecture Should You Choose?

AWS now offers a spectrum of ways to build agents: the Bedrock Agents Classic experience, the managed AgentCore Harness, code-defined agents on AgentCore Runtime, and fully custom application orchestration using services such as API Gateway, Lambda, and Amazon Bedrock model invocation.

To make the comparison concrete, this article uses a consistent enterprise knowledge retrieval layer across all four patterns. The agent can search indexed content, retrieve relevant passages, and use that context to produce a grounded response. Holding the retrieval layer relatively constant allows the comparison to focus on the orchestration layer.

The implementation examples use Coveo’s Hosted MCP Server and Passage Retrieval capabilities as the retrieval layer. 

After implementing all four patterns for the same use case, my recommendation is to start with AgentCore Harness when the workflow is primarily conversational and tool-based . Move to AgentCore Runtime when you need custom planning, graph workflows, multi-agent systems, or human approval flows. Use a custom API approach for applications that already own the end-to-end product workflow, and treat Bedrock Agent Classic as a migration path rather than a new foundation.

At a glance

Why this decision matters

A year ago, many AWS agent discussions started and ended with Bedrock Agents. Today, the decision space is broader. AgentCore introduces a platform for deploying and operating agents at scale, while the distinction between  Harness and Runtime forces teams to decide how much of the orchestration they want AWS to own.

Enterprise assistants are only useful if they can retrieve trusted, permission-aware business knowledge. That retrieval layer may be provided through enterprise search, content repositories, business APIs, or MCP-compatible tools. In the implementation discussed here, Coveo’s Hosted MCP Server exposes search and retrieval capabilities to the agent without requiring a separate custom integration for each client. [6].

The result is a useful architecture question: if the enterprise knowledge layer can remain relatively consistent, what should own the agent loop?

The common goal: an agent grounded in enterprise knowledge 

All four patterns solve the same problem: a user asks a question, an agent decides whether enterprise knowledge is needed, a retrieval system provides  the relevant context, and a foundation model produces a grounded answer.

The implementation details differ, but the high-level flow is stable: User -> AI Agent -> Retrieval Layer-> Enterprise Knowledge -> Grounded Answer.

This is why the four architectures are comparable. They are not four different products; they are four different responsibility boundaries around the same enterprise AI use case.

The four architectures

Figure 1 summarizes the four patterns discussed in the rest of the article. Read it horizontally as a data flow and vertically as an architectural ownership comparison.

Architecture 1 – Bedrock Agent Classic

This is the pattern many early Bedrock agent experiments used: Bedrock Agent Classic owns the agent loop, a tool or gateway layer handles the retrieval request, and the retrieval system returns passages or search results to ground the final answer.

This remains useful if you already have working Bedrock Agents. It is simple to explain, requires little orchestration code, and maps well to the earlier retrieval action-group pattern demonstrated on the AWS Machine Learning Blog [7]. The referenced example uses Coveo Passage Retrieval.

The strategic concern is lifecycle. AWS documentation now describes Amazon Bedrock Agents as Bedrock Agents Classic and points customers toward AgentCore for similar or expanded agent capabilities [3]. That does not mean existing workloads stop working; it does mean I would avoid using Classic as the foundation for a new long-term architecture.

The tradeoff: easiest path for existing Classic users, weakest strategic fit for new work.

Architecture 2 – Custom API + Lambda

In the custom architecture, your application becomes the orchestrator. API Gateway exposes the endpoint, Lambda controls the workflow, an enterprise retrieval system provides relevant context, and Amazon Nova or another model generates the answer.

This pattern is not really an agent platform; it is an application backend with AI capabilities. That can be exactly right when the product already owns authentication, business workflow, release management, and user experience.

The advantage is control. You decide precisely when to call the retrieval system, which prompt to use, how to validate the answer, how to retry, how to fail closed, and how to route between models. The cost is that you now own the orchestration code, test harnesses, runtime behavior, and much of the operational burden.

The tradeoff: maximum control, maximum custom engineering.

Architecture 3 – AgentCore Harness

AgentCore Harness is the closest conceptual successor to the managed Bedrock Agent experience. You declare the model, instructions, tools, memory, and limits, while AWS runs the agent loop.

AWS documentation describes Harness as a managed agent harness where the orchestration loop is provided. Switching models or adding tools is primarily a configuration change rather than a code redeploy [4]. AWS’s Classic migration guidance also identifies the managed harness as the config-based starting point for declaring model, tools, and instructions while AgentCore handles compute, memory, identity, and observability [3].

For a  conversational enterprise assistant that relies on external knowledge or tools, Harness is often  the cleanest default. The team can focus on instructions, retrieval quality, response style, security, and answer quality rather than re-implementing an agent loop.

The tradeoff: strong productivity and operational simplicity, less control over the orchestration internals.

Architecture 4 – AgentCore Runtime

AgentCore Runtime is often misunderstood. It is not the same thing as managing everything yourself. Runtime provides a serverless hosting environment for agent code, while the orchestration loop remains yours.

The AWS Harness-vs-Runtime documentation is explicit: Runtime provides infrastructure such as isolation, scaling, sessions, authentication gating, and observability plumbing, while the agent logic is code you write [4]. AgentCore Runtime also provides agent-specific tracing, streaming, and access to AgentCore capabilities such as Memory, Tools, and Gateway through a unified SDK [5].

That makes Runtime the right choice when your agent stops being a single conversational assistant and becomes an AI system: custom planning, graph workflows, multiple tools, specialized agents, approvals, validation stages, or model-routing logic. You still benefit from AWS-managed runtime capabilities, but you own the brain of the workflow.

The tradeoff: substantial flexibility for custom orchestration, with AWS-managed runtime capabilities that would otherwise need to be built and operated by the application team.

Decision matrix

The table below keeps the comparison intentionally practical. The ratings reflect architecture fit for an enterprise assistant grounded in external knowledge and tools,  not a universal judgment of each AWS service.

These ratings are directional and depend on implementation requirements, service evolution, and the specific tools or frameworks used. 

Decision tree

When stakeholders ask for the ‘best’ architecture, I use the following routing logic. It avoids technology-first decisions and starts with the question of who should own the agent’s responsibilities.

My practical recommendation

Lessons learned from implementing all four

1. The retrieval layer is often the least volatile part of the architecture.

Whether retrieval  is exposed  through a classic action group, an MCP server, or another interface,  the  objective stays the same: fetch precise, permission-aware enterprise context that the model can use to answer.

2. The real design choice is ownership of the loop.

Teams often ask “Which AWS agent service should we use?” A better question is ”Who should own planning, tool routing, retries, validation, and workflow branching?” That question quickly separates Harness from Runtime and Custom API architectures.

3. Runtime is not DIY infrastructure.

The diagram should not say that Runtime makes you manage scaling and observability. Runtime gives you AWS-managed agent infrastructure. What you manage is the orchestration code.

4. Harness is the strongest default, but not the end state for every team.

Harness is excellent when the workflow is mostly conversational and tool-based. Runtime becomes more attractive when the agent starts to look like a workflow engine, a multi-agent platform, or an enterprise automation layer.

5. Gateway and identity deserve early design attention.

It is tempting to treat the gateway as plumbing. In production, it becomes a key boundary for authentication, authorization, tool exposure, policy enforcement, and auditability.

6. Classic is useful context, not the future center of gravity.

The Classic pattern is still valuable for understanding the evolution of Bedrock agents and for migrating existing workloads. I would not make it the centerpiece of a new reference architecture.

Migration path: from Classic to AgentCore

For existing Bedrock Agent Classic customers, I would not recommend an immediate rewrite unless there is a specific blocker. I would, however, start designing the migration boundary now.

A pragmatic path is to keep the retrieval integration stable, move the managed orchestration experience to AgentCore Harness first, and only move to Runtime when the requirements clearly exceed configuration-driven orchestration.

In other words: migrate the orchestrator first, not the entire retrieval architecture. The goal is to avoid changing every layer at once.

Final recommendation

If I were publishing a reference architecture today for a new conversational enterprise  assistant on AWS, I would make AgentCore Harness the recommended default. It has the right balance of implementation speed, managed operations, and integration with MCP-compatible tools. 

I would present AgentCore Runtime as the code-defined path: for teams building custom planners, multi-agent systems, graph workflows, approval flows, or an AI platform that coordinates many enterprise systems. Teams still benefit from AWS-managed runtime capabilities, but they own the orchestration logic. 

I would keep the Custom API + Lambda architecture in the decision guide because it is still the right answer for some product teams. Not every AI assistant needs to be an AWS-managed agent. If your application already owns the user experience, business logic, and release cycle, the custom architecture may be the most appropriate fit.

Finally, I would treat Bedrock Agent Classic as a migration story. It is historically important and useful for existing deployments, but it should not be the default starting point for new work.

References

[1] Amazon Bedrock AgentCore Documentation: Open source

AWS describes AgentCore as a fully managed service for deploying and operating agents securely at scale using any framework and model.

[2] AgentCore Harness: Open source

AWS documentation for Harness, including configuration-driven agents, versions, endpoints, and export options.

[3] Amazon Bedrock Agents Classic maintenance mode: Open source

AWS guidance describing Bedrock Agents Classic, migration options, and AgentCore as the recommended path.

[4] AgentCore Harness vs. Runtime: Open source

AWS comparison explaining that Harness provides the orchestration loop while Runtime is a serverless hosting environment for code-defined agents.

[5] Host agent or tools with AgentCore Runtime: Open source

Runtime capabilities including agent-specific observability, streaming, and SDK access to AgentCore capabilities.

[6] Coveo Hosted Model Context Protocol Server: Open source

Coveo documentation for accessing Search, Fetch, Answer, and Passage Retrieval through Hosted MCP.

[7] Enhancing LLM accuracy with Coveo Passage Retrieval on Amazon Bedrock: Open source

AWS Machine Learning Blog post showing Coveo Passage Retrieval deployed as a Bedrock Agents action group.

[8] AgentCore Gateway Quickstart: Open source

AWS starter toolkit documentation describing Gateway as a way to expose APIs, Lambda functions, and existing services as MCP-compatible tools.