AgentCore vs. Bedrock Agents vs. Flows

When you search "Bedrock agents" you hit three different products, and conflating them is the single most common beginner mistake. They are not versions of one thing — they sit at different layers and solve different problems.

The "AgentCore" brand sits under the Bedrock umbrella but is explicitly not limited to Bedrock models or to one framework. Treat it as a sibling platform, distinct from the classic managed Amazon Bedrock Agents product. The mental shorthand for the rest of this lesson:

• Classic Bedrock Agents = managed simplicity — you configure, AWS operates.
• AgentCore = modular control — you code, AWS supplies infrastructure.
• Bedrock Flows = visual workflow — you draw deterministic pipelines.

Classic Amazon Bedrock Agents is fully managed and configuration-first. You define the agent in the console or API, attach a Knowledge Base for retrieval, and give it action groups (the functions it can call). Then AWS runs the orchestration — the ReAct (reason + act) loop — for you. You don't write the agent loop; you describe its pieces and AWS executes them.

That design buys you speed and simplicity, and it comes with two structural constraints:

1. You're tied to Bedrock-hosted models. The orchestration runs against models hosted in Bedrock — you can't point a classic agent at the OpenAI API, Gemini, or a self-hosted model.
2. You're tied to AWS's managed loop. The reasoning loop is AWS's, not yours. You can shape it with instructions, action groups, and Knowledge Bases, but you don't own the orchestration code, so deeply custom control flow (branching across frameworks, bespoke tool-selection logic, multi-agent topologies you design yourself) isn't your call to make.

Conceptually, a classic agent is assembled like this:

  Classic Bedrock Agent (AWS runs the loop)
  ┌───────────────────────────────────────────┐
  │  Instructions  +  Bedrock-hosted FM         │
  │        │                                    │
  │        ├── Action groups   (functions)      │
  │        └── Knowledge Bases  (retrieval)     │
  └───────────────────────────────────────────┘

If your use case fits the managed shape — a Bedrock model, a handful of actions, a knowledge base, and you'd rather not operate any infrastructure — classic Bedrock Agents is the fastest path from idea to a working agent.

AgentCore is the modular, code-first, framework-agnostic alternative. You bring your own framework, model, and orchestration; AgentCore supplies the production infrastructure — secure serverless hosting with per-session isolation, identity, memory, a governed tool gateway, sandboxes, and observability. It solves the prototype-to-production gap: it's easy to build an agent on your laptop with LangGraph or Strands, but hard to operate it safely at scale. AgentCore hands you those operational primitives as managed services so you keep your agent logic and offload the plumbing.

Two foundational properties define it:

• Framework-agnostic — Runtime hosts a container that speaks a known protocol, not a framework. Your framework lives inside the container; the @app.entrypoint decorator is the seam between AWS's managed HTTP server and your agent object.
• Model-agnostic — the model is just a config value inside your code. AgentCore never inspects it.

A minimal AgentCore agent — note that the framework call is yours, not AWS's:

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent

app = BedrockAgentCoreApp()
agent = Agent()  # your framework, your orchestration — swap for LangGraph/CrewAI/etc.

@app.entrypoint
def handler(payload):
    result = agent(payload.get("prompt"))  # the loop runs in YOUR code
    return {"result": result.message}

if __name__ == "__main__":
    app.run()

Versus classic Bedrock Agents, AgentCore explicitly adds:

• MCP support — expose APIs/Lambda/services as Model Context Protocol tools (via Gateway) and connect to existing MCP servers.
• VPC connectivity — run inside your own VPC with PrivateLink, for private backends and network controls.
• A2A — agent-to-agent protocol support for multi-agent topologies.

And because it's modular, you don't have to adopt the whole platform. Services "work together or independently": you can use only Gateway, only Code Interpreter, or only Memory while your agent runs on EKS, Lambda, or ECS. Each service has its own SDK/API surface and is independently billable.

A natural assumption is that AgentCore replaces classic Bedrock Agents. AWS is explicit that it does not. From the AgentCore FAQ:

"If you are using Amazon Bedrock Agents today, you can continue to do so… AgentCore is an agentic platform that provides enhanced capabilities including support for any open-source framework."

The practical implications:

• Classic Bedrock Agents is not deprecated. Existing managed agents keep running; nothing forces a rewrite.
• Migration is optional. You move to AgentCore when you need what it adds — your own framework/model, MCP tools, VPC connectivity, A2A, custom orchestration — not because a deadline is looming.
• They can sit side by side. Some workloads stay on the managed product; others, that have outgrown the managed shape, run on AgentCore. The same team can use both.

So the question is never "which one survives?" — it's "which one fits this workload?" That's a per-project decision, which is exactly what the decision rule in the next section is for.

Bedrock Flows is the third thing people confuse with AgentCore, but it lives at a different layer. Flows is visual, drag-and-drop orchestration of (often predetermined) steps and AWS services for a generative-AI application — you wire nodes (prompts, foundation models, Knowledge Bases, Lambda functions, conditions) into a graph that executes in a defined order.

The distinction that matters:

• Bedrock Flows orchestrates steps you decided in advance. The control flow is the diagram you drew; it is deterministic by design.
• AgentCore is the runtime/operational platform for autonomous, code-defined agents that decide their own next steps. The control flow emerges from the model's reasoning at run time.

  Bedrock Flows                         AgentCore agent
  (you drew the path)                   (the agent picks the path)

  [Input] → [Classify] ─┬─ yes → [KB] ──┐      [Input] → reason → choose tool → act
                        │               ├─→ …          ↑___________________________│
                        └─ no  → [Lambda]┘             (loop until the goal is met)

Because they're different layers, they can be complementary rather than competing. A predetermined pipeline might call an autonomous agent as one of its steps; conversely, an agent might invoke a deterministic flow when a task is best handled as a fixed sequence.

There is no single official side-by-side comparison page for these three products — the layering framing here is an editorial synthesis, while each product's individual definition is sourced from AWS. When you cite specifics, link the product's own page (Flows, the AgentCore docs, the FAQ).

Map the three products onto three questions, in order. Stop at the first "yes."

1. Is the task a fixed sequence of known steps? → Bedrock Flows. Visual workflow; deterministic; auditable; no autonomous reasoning about what to do next.
2. Is it an autonomous agent that fits the managed shape — a Bedrock model, action groups, a Knowledge Base, and you want zero infrastructure? → Classic Bedrock Agents. Managed simplicity; AWS runs the loop; fastest path to a working managed agent.
3. Do you need your own framework or a non-Bedrock model, MCP tools, VPC connectivity, A2A, custom orchestration, or production primitives (session isolation, memory, identity, observability) at scale? → AgentCore. Modular control; you own the loop, AWS owns the infrastructure.

A compact reference:

And remember the meta-rule from the previous section: this is not a one-time platform bet. Because the products coexist, you can pick per workload — a deterministic flow here, a managed agent there, an AgentCore agent for the one that outgrew the managed shape — and revisit the choice as a project's needs change.