AgentCore, Bedrock Agents and Strands: Which Layer Does What?

Overview: three choices at different layers

AgentCore, Bedrock Agents and Strands can all appear in an AWS agent architecture, but they are not three interchangeable products competing to perform one job. The useful distinction is the layer at which each choice operates: infrastructure, managed orchestration or application-level SDK. Choosing between them starts with deciding which of those responsibilities your team needs to acquire, retain or operate.

AWS describes AgentCore as modular agent infrastructure and distinguishes a runtime from a framework. AWS Prescriptive Guidance Bedrock Agents is managed agent orchestration built around action groups and knowledge sources. Amazon Bedrock Agents documentation Strands offers application SDKs and an assembled harness. This comparison examines its SDK-led development route; choosing its assembled harness shifts more defaults to the package, while hosting remains a separate concern. Strands SDK repository

Those distinctions do not imply that every organization should choose one option exclusively. A team might use a managed orchestrator and separately decide how to host and operate its agent. Another team might build orchestration into application code using an SDK, then make a separate infrastructure choice. A third might find that its existing workflow already handles the job and that adding any of these choices would create more moving parts than value.

This comparison focuses on the decision boundaries: who owns the control flow, how much behavior is expressed in application code, and what infrastructure needs to be selected separately. It does not attempt to rank every AWS agent-related product or explain the detailed ownership of each AgentCore component. For that separate question, see Amazon Bedrock AgentCore: Who Owns Each Layer of the Stack?.

Start with the layer, not the product name

An agent system has multiple responsibilities that are easy to conflate. It needs a way to decide what to do next, a way to connect a model-driven process to business capabilities, and an environment in which the application can run. It also needs explicit decisions about data, identity, failure handling and ownership. One product choice may address part of this work, but the architecture still has to account for the rest.

Orchestration is the control logic that determines the next action in a task. It may involve model-directed tool selection, application-defined steps, or a combination of both. The important architectural question is who owns that logic and how the team can inspect, test and change it.

An SDK gives developers a programming interface for building software. It can help structure application code, but choosing an SDK does not, by itself, choose where the software runs or who manages its orchestration. Those are separate decisions.

Infrastructure is the environment and supporting capabilities on which an agent application depends. An infrastructure choice does not automatically mean the application’s task-specific control flow is supplied for it. In particular, a runtime and an agent framework are not synonyms: the former concerns running software, while the latter concerns how agent behavior is constructed.

This separation helps prevent two common errors. The first is comparing a managed orchestration service directly with an SDK as if each were a complete deployment architecture. The second is assuming that selecting infrastructure settles application design. In practice, each choice creates boundaries: the service or library may handle some responsibilities, while the team remains responsible for other decisions.

A compact decision path

Use the diagram as a first-pass sorting tool, not as a product-selection algorithm. The first branch concerns who should own orchestration; the final node asks a separate infrastructure question, which should not be treated as an automatic requirement to select AgentCore.

flowchart TD
  accDescr: Workflow stages and decisions: Does managed orchestration fit the workflow?, Consider Bedrock Agents, Should orchestration live in application code?, Consider Strands as an SDK, Retain or design another orchestrator, Plan application operations, Assess additional infrastructure needs. The adjacent text explains the conditions and exceptions.
  accTitle: AgentCore, Bedrock Agents and Strands — Which Layer Does What? workflow
%%{init: {'flowchart': {'defaultRenderer': 'dagre'}}}%%
    A["Does managed orchestration fit the workflow?"] -->|Yes| B["Consider Bedrock Agents"]
    A -->|No| C["Should orchestration live in application code?"]
    C -->|Yes| D["Consider Strands as an SDK"]
    C -->|No| E["Retain or design another orchestrator"]
    B --> F["Plan application operations"]
    D --> F
    E --> F
    F --> G["Assess additional infrastructure needs"]

accTitle: A decision path for orchestration and infrastructure accDescr: First decide whether managed orchestration fits. If not, decide whether application code should own orchestration or another orchestrator should. Then assess hosting and infrastructure separately, including whether AgentCore fits.

The first branch does not assert that a managed service is always simpler or more capable. It asks whether its approach matches the workflow and the team’s desired control boundary. If the answer is no, the next branch separates SDK-based application orchestration from a different orchestration design. Each route reaches infrastructure only after that decision has been made.

Feature-by-feature comparison

Decision dimension	AgentCore	Bedrock Agents	Strands
Primary layer considered here	Agent infrastructure	Managed orchestration	Application SDK; assembled harness also available
Central question	What infrastructure boundary does the application need?	Does managed orchestration fit this task?	Should developers express agent behavior in application code?
Control-flow ownership	Depends on the application architecture	More orchestration is assigned to the managed service	More orchestration choices are made in application code
Separate decisions still required	Framework or orchestration choice, business behavior, state and identity boundaries	Application-specific behavior, hosting and operational boundaries	Hosting, identity, persistence, observability and application behavior
Strongest reason to consider it	Infrastructure needs are a distinct design concern	The workflow aligns with managed orchestration	The team wants code-level design control and can own it
Main caution	Infrastructure does not equal a complete agent design	Managed orchestration does not remove the need to define the workflow and its effects	SDK choice does not supply deployment or operational ownership

The table compares responsibilities, not a feature checklist. It deliberately avoids implying that one option has a particular deployment capability, integration, model choice or operating characteristic unless that is established for the specific design under consideration. Treat claims beyond the stated layer as questions to verify against current service details and your own architecture constraints.

Control-flow ownership

Bedrock Agents is the direct candidate when the question is whether managed agent orchestration is appropriate. Its documented concepts include action groups and knowledge sources. That gives a team a concrete starting point for evaluating whether its task can be expressed through the service’s managed approach. The architecture still needs to define what each action is permitted to do and what happens when the requested work cannot be completed.

With Strands, the decision shifts toward code ownership. An SDK-centered design is attractive when engineers want application code to define more of the agent’s construction and flow. The tradeoff is that the engineering team must decide how that code is tested, changed, deployed and observed. A library can make implementation more structured without making the system’s operational responsibilities disappear.

AgentCore sits on a different axis. It is relevant when infrastructure is an explicit part of the design, but selecting an infrastructure layer does not answer whether the application uses managed orchestration, a framework or another control-flow approach. Teams should write those choices on separate lines in an architecture decision record rather than placing them under one product heading.

How much behavior should be explicit?

A managed orchestration approach can reduce the amount of orchestration logic the application team needs to implement directly. That is useful when the managed model maps cleanly to the business process and the team values a defined service boundary. It is less persuasive if the workflow’s critical behavior must be expressed in ways the team cannot clearly inspect or validate in that boundary.

An SDK approach puts more design decisions in the application. That can suit a team with established software engineering practices for branching, testing and maintaining business logic. It can also produce a larger burden: developers need to maintain a coherent control flow as task types, tool behaviors and failure cases grow. More control is not a benefit unless the team has a reason to exercise it and capacity to support it.

Infrastructure is neither the same as code control nor a substitute for it. A team can change where its application runs without changing the policy for deciding which business action should happen next. Conversely, it can change the orchestration design while retaining a stable infrastructure boundary. Keeping these axes independent makes later changes easier to reason about.

Pros and cons by option

AgentCore: infrastructure as a separate decision

Pros. AgentCore is worth considering when the organization wants to make agent infrastructure a deliberate, modular design decision rather than assuming that an SDK or an orchestration choice also settles operations. Treating infrastructure as its own layer encourages the team to state what it expects the runtime and surrounding environment to own, and what remains application responsibility.

Cons. The label alone does not choose an orchestration approach, define business rules or establish how state is represented. If a project selects infrastructure before clarifying its control flow, it may make progress on an adjacent concern while leaving the central application decision unresolved. A team must also verify the exact component responsibilities it intends to rely on rather than generalizing from the category name.

Best fit. Consider AgentCore when infrastructure requirements are material and the team can name the boundary it wants to evaluate. Do not select it merely because the workload is described as an agent. If the immediate problem is deciding how a task chooses and invokes business actions, first compare orchestration approaches; infrastructure remains a separate follow-up.

Bedrock Agents: managed orchestration

Pros. The managed-orchestration framing gives teams a specific alternative to implementing all orchestration behavior in application code. Action groups and knowledge sources provide concrete concepts around which to assess the fit of a proposed task. This can help narrow an evaluation: map the workflow’s actions and information needs, then check whether the resulting design is understandable and acceptable to its owners.

Cons. Managed orchestration does not eliminate the need to specify what the business process means. Teams still need clear action boundaries, rules for ambiguous requests, expected outcomes and procedures for unsuccessful work. If a service boundary obscures a critical decision or makes a required operating practice hard to implement, the apparent reduction in custom code may not compensate for the mismatch.

Best fit. Consider it when the process can be described in terms that map cleanly to managed orchestration and the team prefers not to own as much of that control logic itself. The right validation is a small, representative workflow, including its ordinary failure paths—not a demonstration limited to the happy path.

Strands: SDK-led application design

Pros. An SDK is a natural candidate when developers want to shape agent behavior in application code and have the engineering discipline to maintain it. Code ownership can make it easier for a team to align task-specific logic with its existing software practices, review changes alongside related application code and write tests for deterministic parts of the flow.

Cons. The team becomes responsible for the design consequences of that code. It has to decide how to represent state, how to prevent unbounded or inappropriate tool use, how to handle retries and partial completion, and how to expose enough diagnostic information for operators. These are architecture responsibilities, not evidence that any particular SDK lacks a feature.

Best fit. Consider Strands when code-level control is an explicit requirement and a named engineering team will own the application after launch. If the team cannot identify who will maintain the orchestration logic or how it will diagnose a stuck task, an SDK choice is premature.

Worked example: a supplier invoice exception

Consider a hypothetical North American distributor with an internal workflow that handles supplier invoices. The system receives an invoice, checks it against a purchase order, identifies discrepancies and, in some cases, prepares a request for a human reviewer. The hypothetical business wants to reduce manual sorting but does not want an agent to change a supplier record or release payment without a separately authorized business process.

The example is intentionally bounded. The agent may classify an invoice and assemble a proposed exception packet. A separate business application remains responsible for any final action. The workflow is not a general-purpose assistant, and its success is not defined by producing fluent text. Its useful result is a correctly categorized case containing the fields a reviewer needs, with no unintended change to a financial record.

Start by separating deterministic checks from uncertain interpretation. Required fields, amount comparisons and purchase-order matching should be handled by existing business logic wherever practical. The agent’s proposed work is limited to interpreting an explanation such as “freight charge differs from the order,” mapping it to a known exception category, and preparing a concise rationale tied to source fields. This split reduces the number of places where model judgment can affect a consequential outcome.

Next, ask whether the orchestration fits a managed approach. If the task is a bounded request to review information and invoke a small set of well-defined actions, the team can test whether Bedrock Agents’ managed orchestration model maps to the process. It should examine how the action boundaries represent read-only lookup and draft preparation, and whether failure and human review are clear in the resulting design.

If the workflow instead requires application-owned branching—for example, different rules by invoice class, separate validation paths for currencies, and a precise sequence of internal checks—the team may prefer to implement that control flow in code with an SDK. That is not an automatic endorsement of Strands; it is a reason to evaluate whether a code-centered design gives the engineers the necessary control, and whether they can support it.

Either path leaves an infrastructure question. The team should state where the application runs, which identity it uses for each operation, where case state is stored, and how operators find a failed case. It can then evaluate whether AgentCore is relevant to those infrastructure requirements. The answer should follow from a written need, not from the assumption that an agent infrastructure choice is required whenever an agent SDK or managed orchestrator is used.

A useful acceptance test for this hypothetical design would include an invoice with a missing purchase-order number, one with a currency mismatch, a duplicate submission and a malformed explanation. For each, the team would specify the expected classification or escalation, the exact business records that may be read, and the changes that must not occur. It would also test a timeout after a draft is prepared but before the case status is updated, because a partial result is an operational condition, not an edge case to hide.

The acceptance record should distinguish model output from business outcome. “The system suggested freight discrepancy” is a model-level observation. “The case was saved with the correct invoice identifier and appears in the reviewer queue without changing payment status” is an outcome that can be checked independently. That distinction matters even if the agent’s explanation sounds convincing.

For this workload, the first decision is not a universal winner. If the task maps cleanly to managed orchestration and the business can define the actions narrowly, evaluate Bedrock Agents first. If intricate, changing rules need to be explicit in application code, evaluate an SDK-led approach. In either case, assess infrastructure separately and keep the final financial action outside the agent’s proposed scope until the business process explicitly assigns it elsewhere.

AWS reference design: identity, state and service boundaries

The following is a proposed reference design, not a claim about a particular product’s implementation. It is AWS-specific at the organizational boundary: deploy the workload within the organization’s AWS account structure, use a workload role with a narrowly defined permission set, and keep business-data access behind an application-owned service boundary. The precise AWS services and deployment topology should be selected against current requirements rather than assumed from this comparison.

Identity boundary. Assign the running workload an identity distinct from a developer’s personal credentials. Give it only the access needed for the defined task: for example, read the invoice and purchase-order fields required for classification, and write a draft case to the designated case service. Do not give the agent’s general reasoning loop a broad capability to modify supplier records or initiate payments. If an operation needs a different authority, make that a separate, explicit boundary in the business application.

State boundary. Store workflow state in a system the application team owns and can inspect. A minimal case record might contain case_id, invoice_id, workflow_status, exception_code, evidence_fields, draft_version, created_at, and last_attempt_at. Keep the source invoice separate from the agent’s summary. Record enough to resume or investigate a case, but avoid treating conversational history as the authoritative business record.

Service boundary. Place business operations behind a small internal interface with distinct read and draft-write operations. The read operation returns only fields needed for the current task. The draft operation accepts a typed case payload and validates identifiers and allowed status transitions. The agent should receive the narrow operation it needs, not an unrestricted database connection. A later implementation could expose these operations through a governed tool boundary; the separate AgentCore Gateway guide covers that topic rather than this layer comparison.

Execution boundary. Separate the step that interprets an invoice from the step that commits a consequential business change. In this example the agent produces a draft, while an independent reviewer or established business process determines what happens next. If approval is part of a future design, it should bind to the exact proposed payload, occur before execution and expire if the payload or relevant context changes. This is a design principle for the hypothetical workflow, not a claim about a platform feature.

Failure boundary. Treat a timeout as an unknown result, not proof that an operation did not happen. Give each draft a stable application-level identifier, read the current case state before retrying a write, and make the receiver reject a conflicting second draft rather than blindly applying it. These measures can make retries safer, but they do not justify promising exactly-once effects across external systems.

Identity delegation is deliberately not expanded here. For the distinct design question of how AWS agents receive delegated identity without shared credentials, see Identity for AWS Agents: Delegation Without Shared Credentials. The choice among an SDK, managed orchestration and infrastructure does not answer that question by itself.

Operational failure analysis

The process gets stuck before an action is called. Possible causes include an ambiguous task, a missing required field or a control-flow decision that cannot be resolved. The system should mark the case as requiring attention, preserve the input and record the step reached. If an operator sees only a generic “agent failed” status, they cannot distinguish incomplete input from an infrastructure problem. Define failure categories at the application boundary before production use.

An action returns an error after a partial response. The agent may have enough information to produce a plausible answer even though the business operation failed. The application should treat the action result as authoritative for whether the operation succeeded. A narrative response must not overwrite a failed status, and the task should not be reported as complete solely because the model produced a confident explanation.

The request times out after a write. A caller may not know whether the receiving service completed the operation. A naive retry can create duplicate records or conflicting drafts. Use a stable request identifier and a receiver-side check for an existing result. If the status remains uncertain, route it to reconciliation rather than repeating an external effect automatically.

State and conversation disagree. Suppose a case record says “draft saved,” while a later model turn claims no draft exists. The application-owned case record should govern workflow state. The model’s context can help compose the next response, but it should not be the sole source of truth for whether a business action occurred. Persist the minimum state needed to continue and reconcile it with the service that owns the action.

A service boundary is too broad. If a tool can perform several unrelated operations, a defect in task interpretation may have consequences beyond the current workflow. Narrow the operation set and validate payloads where the business action is enforced. Adding an SDK or choosing a managed orchestrator does not repair a boundary that grants more authority than the task requires.

These failure modes provide a useful comparison test. A design is not operationally ready merely because it completes a clean example. Ask whether the team can identify the failed step, prevent an unintended repeat, reconcile persistent state, and route unresolved work to a human process without pretending it succeeded.

A practical decision worksheet

Use this worksheet in an architecture review. Write concrete answers rather than selecting a product name first.

• Name the task boundary. State the input, the intended result and the business outcome that can be independently verified. If the task is described only as “use an agent,” it is not yet specific enough to compare approaches.
• List the actions. Separate information retrieval, draft creation and consequential writes. Identify which action is read-only, which changes state and which should remain outside the agent’s authority.
• Assign orchestration ownership. Decide whether a managed orchestration model fits, application code should own more of the flow, or another orchestrator is already the best fit. Record the workflow conditions that led to the decision.
• Identify code ownership. If choosing an SDK-led approach, name the team that will maintain the flow, its tests and its operational runbook. If that ownership is unclear, resolve it before increasing application-code responsibility.
• Write the infrastructure question separately. Describe the hosting, identity, persistence and operational requirements that matter. Then assess whether an infrastructure option addresses a stated need. Do not treat infrastructure selection as a substitute for deciding control flow.
• Define state authority. Name the system that determines whether an action actually happened. Specify which fields are persisted and how the application recovers after a timeout or restart.
• Exercise a bad input and a partial failure. Include at least one missing or contradictory input and one failure after an attempted write. Record the expected status, operator action and safe retry behavior.
• Set a pilot exit criterion. Choose observable conditions such as correct routing of a defined sample set, no prohibited writes, inspectable failure states and a named operational owner. Do not substitute a fluent answer or a successful demonstration for those conditions.

Printable summary

Task: ______________________________ Business outcome: ______________________________

Orchestration owner: ______________________________ Reason: ______________________________

Infrastructure need to evaluate: ______________________________ Reason: ______________________________

Authoritative state system: ______________________________ Permitted actions: ______________________________

Failure tested: ______________________________ Expected recovery: ______________________________

Operational owner: ______________________________ Pilot exit condition: ______________________________

A completed worksheet is useful even when the decision is to use none of the three options. It captures the reasons behind the architecture choice and makes future changes easier to evaluate against the same task and failure criteria.

Verdict: choose by responsibility and use case

Choose Bedrock Agents for evaluation when the central need is managed orchestration and the proposed task maps cleanly to a bounded set of actions and information needs. Its advantage in that situation is the opportunity to avoid owning as much orchestration directly in application code. Its limitation is that the team must still define safe actions, business outcomes and the operational handling of incomplete work.

Choose Strands for evaluation when developers need to own more of the agent behavior in code and have the capability to support that choice. Its advantage is application-level design control; its cost is a continuing engineering responsibility for control flow, testing, state and operations. The SDK decision should be accompanied by an ownership plan, not treated as a deployment plan.

Choose AgentCore for evaluation when infrastructure is the unresolved architectural concern and the team can identify what it expects that layer to address. It is not a replacement label for orchestration, and choosing it does not determine the application’s behavior. State the framework or orchestration choice separately, then verify infrastructure fit against actual requirements.

Choose an existing or different approach when the process already has a reliable orchestrator, when the work is better represented as deterministic software, or when the organization cannot yet name an accountable owner for the new system. Adding an agent layer is not a goal in itself. A narrow automation that is easier to inspect and recover may be a better fit than introducing model-directed decisions into a task that does not need them.

The most reliable decision is therefore layered: first define the workflow and its permitted effects, then choose who owns orchestration, then assess infrastructure, identity and state. Teams comparing a broader enterprise platform decision can also consult Microsoft Foundry, Bedrock AgentCore, or Gemini Enterprise: Choosing an Enterprise Agent Platform. For a separate implementation and operating-cost discussion, see What an AI Agent Actually Costs on Bedrock AgentCore.

If your team has reached the point of turning these boundaries into an AWS deployment and operating model, a focused cloud platform engineering engagement can help translate the decisions into practical service, identity and state boundaries. The immediate next step is to complete the worksheet for one bounded workflow and test the chosen path against a partial failure before expanding its authority.