Amazon Bedrock AgentCore: Who Owns Each Layer of the Stack?

Start with the ownership question

An agent stack is not one component with one owner. It is a chain of decisions and services: code must run somewhere, a caller must be identified, business rules must be applied, tools must reach systems, data may persist between steps, and someone must respond when a dependency fails. Amazon Bedrock AgentCore belongs within that wider design. Choosing it does not, by itself, assign those responsibilities to the right teams.

This distinction matters because a platform diagram can make boundaries look cleaner than they are in production. A runtime may execute an agent, while the application still decides whether a particular person can change a particular order. A tool may connect to a business API, while the API remains responsible for validating the requested operation. A persistent store may retain task context, while application and data owners determine what belongs there and when it should be removed.

AWS describes AgentCore as modular agent infrastructure and distinguishes a runtime from an agent framework. That distinction is useful when allocating ownership: a team can own the infrastructure boundary without owning every application behavior built on it. (AWS Prescriptive Guidance)

The practical objective is not to draw the most elaborate architecture. It is to name the person or team accountable for each decision, show where that decision is enforced, and establish what happens when the expected path fails. A smaller organization may assign several layers to one team. The responsibilities should still remain distinguishable, because different failures require different remedies.

Define the layers before assigning teams

A runtime is the execution boundary for agent application code: the place where a deployed task is carried out. The runtime owner is concerned with how code is packaged, configured, released, monitored and rolled back. That owner does not automatically decide what a user is allowed to do in the business domain.

A framework is the software structure used by developers to define agent behavior, such as coordinating model interactions and application logic. It shapes how the application is built; the runtime is where that application executes. Teams can choose or change these layers for different reasons, so treating them as synonyms tends to blur operational accountability. The framework and runtime may be managed by different teams, or by the same team under separate responsibilities.

Identity answers which user, service or workload is participating in an interaction. Authorization answers whether that identified principal may perform a specific action on a specific resource in a specific context. The second decision often depends on business facts that a shared platform cannot infer reliably, such as account ownership, order status, approval limits or a customer relationship.

A tool integration is the interface through which the agent can request work from another system. Its contract includes more than a name and a connection: it should define accepted inputs, permitted effects, validation, error behavior and the meaning of a successful response. State is information retained across steps or requests, such as a task identifier or a user-selected preference. Operations covers the people, signals and procedures needed to detect, investigate and recover from failures.

These definitions suggest a useful rule: assign ownership according to the decision being made, not just the service that hosts the code. The runtime owner can manage the execution environment. The application owner decides how the workflow interprets user intent. The system of record remains authoritative for its data and business operations. Operations needs a clear handoff between them.

Use a responsibility matrix, not a vague RACI label

The matrix below is a starting point for a production design review. “Primary owner” means the team expected to make the decision and drive remediation; it does not mean that team works alone. Record one named accountable role for each row, even where implementation is shared. A group label such as “engineering” is not specific enough when an incident is underway.

This matrix intentionally separates application behavior from runtime operations. A platform group may maintain a supported deployment pattern, but the product team should still be able to explain what the agent is meant to do and how the result is checked. Conversely, application teams should not each invent a different release and incident process if the organization needs common controls.

A useful design review asks each owner to name a concrete control point. “The platform handles security” is not a control point. “The application checks the caller’s account relationship before it requests an order change” is more specific. “The integration validates the order identifier and rejects a request without the required fields” is testable. Record the component where each check occurs, rather than relying on a team name or an architectural aspiration.

Keep identity and business permission separate

A workload identity identifies an agent workload; it does not replace per-user business authorization. (AWS AgentCore identity concepts) The distinction becomes especially important when one deployed agent handles requests for many employees or customers. The workload may need a controlled way to reach a service, while the application must still preserve the individual caller’s business context.

For example, a customer support workflow might receive a request from a signed-in user and use an application service to retrieve an account record. The agent’s ability to reach the account service is not evidence that the caller may inspect every account. The application must carry the relevant caller context into an authorization decision, and the downstream business service should validate the operation according to its own contract. The design should make it possible to tell apart “the workload can connect” from “this user may perform this action.”

Write that separation into the request path. Identify where the original caller is authenticated, how the caller’s relevant attributes or claims reach the application decision, and what happens if that context is missing or stale. Do not let a tool infer authority from the agent’s general ability to connect. Do not silently substitute a broad service identity when the caller-specific check cannot be completed.

This is also why delegation needs an explicit boundary. If an application acts on a user’s behalf, specify what is delegated, for which task, against which resource, and for how long. Avoid a design where the agent receives an open-ended credential or a general instruction to “act as the user” without a verifiable authorization decision. The detailed treatment of delegated access belongs in Identity for AWS Agents: Delegation Without Shared Credentials; this article’s concern is which team owns the boundary and its operational consequences.

Reference design: place business decisions beside the business workflow

The proposed design below has one caller, an application authorization decision, a workload identity, a runtime, an integration boundary, a business service and a state store. It is an architectural pattern to evaluate, not a claim that every named box is automatically supplied or configured by a product. Operations and incident response span the flow and are discussed separately rather than being treated as another execution hop.

flowchart TD
    accTitle: Proposed AgentCore responsibility boundaries
    accDescr: A caller passes through application business authorization and workload identity before reaching the agent runtime. The runtime requests approved operations through a gateway to a business service and may separately use a state store under application-defined rules.
    A["User or calling application"] --> B["Business authorization"]
    B --> C["Workload identity"]
    C --> D["Agent runtime"]
    D --> E["Gateway and tool boundary"]
    E --> F["Business service"]
    D --> G["Application-defined state store"]

Read the arrows as an intended request path, not proof that an upstream decision remains valid forever. The caller’s business authorization should be checked at the point appropriate to the action and the available context. The workload identity supports access to connected resources; it does not answer the business question. The gateway boundary limits and shapes the tool interface, while the business service remains responsible for its own records and operations. The state store is a separate dependency with its own data rules.

Gateway connects agent tools and target integrations, and its inbound and outbound authorization concerns are distinct. (AWS Gateway concepts) For this ownership design, record who controls access arriving at the tool boundary and who controls the integration’s access to its target. Do not assume that a decision made on one side automatically settles the other. A deeper treatment of tool interfaces and target integrations is available in AgentCore Gateway: Turning Existing APIs into Governed Agent Tools.

The application owner should define a narrow first tool contract. A request to retrieve one order’s current status is easier to constrain than a general-purpose operation that can search, edit and cancel orders. If a task changes a consequential record, define the preconditions, the exact requested change, the point at which authorization is checked, and how the application confirms the resulting business state. Put those decisions in the application and service contract; do not rely on a model’s natural-language explanation as proof that an operation succeeded.

State should be designed as deliberately as the tool path. Start by listing fields that are genuinely necessary between steps: perhaps a task identifier, a selected order identifier, a pending user confirmation, and a status indicating whether an operation was requested or verified. Avoid retaining whole prompts or broad record snapshots merely because they are convenient. Decide how state is partitioned between callers and tasks, who may inspect it, how long it remains useful, and how a support team corrects or removes it.

Worked example: an order-change agent

Consider a hypothetical mid-market retailer exploring an agent that can help support staff correct a delivery address before an order ships. The business goal is intentionally narrow: find the relevant order, confirm that the employee is permitted to handle it, submit a specific address change, and verify what the order system accepted. This is a design illustration, not a report of a deployed system or measured result.

The application team owns the workflow rules. It defines which support role may request a change, which order states permit it, what address fields must be supplied, and what confirmation the employee must see. It decides how to deal with ambiguous requests, such as two matching orders or a customer whose identity cannot be verified. Those are business decisions, not runtime configuration.

The platform team owns the execution pattern around the agent application: how a release is introduced, how configuration is separated by environment, how the team can roll back a bad version, and where operational signals are routed. Its responsibility is not to decide whether a particular employee may edit a particular order. It should provide an intelligible path for the application team to deploy and operate the workflow without making those business rules invisible.

The security and identity owners define how the application establishes the employee’s identity and how the workload reaches the approved downstream dependency. The application must preserve the employee context needed for its authorization decision. If the identity context cannot be validated, the workflow should stop before exposing order data or requesting a change. A fallback that uses a broad service credential and continues anyway would erase the separation the design is meant to preserve.

The order-system owner defines the authoritative change operation and the meaning of its responses. The integration owner documents which fields can be submitted, which validation errors may occur, and how to look up the resulting order state. If an address update is accepted by the order system, the application should verify the recorded address through an authoritative result before telling the employee that the task is complete. A model-generated sentence saying “updated” is not that verification.

State has a deliberately small role in the example. The application might retain a task identifier, the selected order identifier, a pending-change status and a reference to the employee’s confirmation. It should not keep a larger customer profile in conversational state when the workflow can retrieve the needed facts from the system of record. The application and data owners decide whether this small state is retained after completion and how a new task is prevented from inheriting an earlier task’s context.

Now consider the failure that deserves the most careful design: the order service accepts the change, but the connection fails before the application receives a response. The agent cannot safely infer that the operation failed and submit it again. Nor can it claim success simply because it issued a request. The application should mark the result as uncertain, preserve a stable reference for investigation, and use an authoritative read or an agreed reconciliation procedure before deciding whether another action is needed.

In that timeline, the platform owner supplies the relevant execution and dependency signals. The application owner decides what the user sees and whether the workflow is paused. The order-system owner determines whether the record changed. Operations coordinates the incident if the issue affects other tasks. Security becomes involved if the evidence suggests access outside the intended boundary, not merely because a normal dependency timed out. This assignment makes the response quicker because each team is asked to answer a different question.

The acceptance criteria should describe observable outcomes. An employee outside the permitted role cannot retrieve or change the order. An eligible employee cannot change an order in a disallowed state. A missing authorization context fails closed at the business decision point. A timeout after submission leads to reconciliation rather than an automatic repeat. The interface reports “pending verification” or an equivalent honest status until the order system confirms the result. The team can identify which owner must act on each failed criterion.

This example also shows why ownership cannot be reduced to a diagram. The important details are the authority to make a decision, the component that enforces it, and the evidence used to determine what happened. The diagram helps locate boundaries; the workflow contract and incident procedure make those boundaries operable.

Counterexample: a shared agent with a broad tool

A tempting design gives one agent a general tool that can retrieve and update customer records, then tells the model to follow the requesting employee’s permissions. The runtime team owns the deployment, and the integration has enough access to perform all supported operations. The application receives a user prompt but does not make a distinct authorization decision for each requested record and action.

This design has no clear owner for the most consequential question: whether this employee may perform this operation now. The platform team may reasonably assume the application team checked it. The application team may assume the tool or downstream service checked it. The system owner may see a valid request from an authorized service and have no way to distinguish which employee initiated it. Each component can appear healthy while the end-to-end business boundary is wrong.

The repair is not simply to add more instructions to the agent. Narrow the tool contract to the actions needed by the workflow, carry the relevant caller context into an application authorization decision, and have the business service validate the request under its own rules. If the system cannot enforce a necessary rule, document the compensating control and the accountable owner before exposing the operation. A control that exists only as an informal expectation is hard to test and harder to investigate.

There is a related counterexample at the other extreme: centralizing every business decision in a platform team. That can make shared infrastructure consistent, but it asks a team far from the process to interpret changing domain rules. The platform group should make safe patterns available and clarify shared boundaries; the application owner should remain accountable for business behavior. A well-designed split is not “centralized versus decentralized.” It is shared infrastructure with locally understood business decisions and explicit interfaces between them.

Plan for failure across team boundaries

A dependency failure often creates an ownership failure first. If a tool times out, the on-call responder needs to know whether to retry, reconcile, pause new tasks or ask the business-system owner to inspect a record. A runbook that says only “contact engineering” does not help answer those questions. For each consequential operation, name the owner who can determine whether the business effect occurred and the owner who can stop further attempts.

Retries deserve particular care. A request can fail before it reaches a service, after it reaches a service, or after the service changes the record but before the caller receives confirmation. Those cases are not equivalent. For a read-only request, a bounded retry may be acceptable under the application’s design. For a state-changing request, the application should first establish whether the prior attempt took effect. Never describe an external operation as exactly-once unless the complete downstream design establishes that property; the safer operational assumption is that an uncertain result requires reconciliation.

Authorization failures also need more than a generic error. Record which boundary denied the request without exposing sensitive information to the user. The application owner should define a safe user-facing explanation and the support path. Security should be able to distinguish a normal denied request from an unexpected access pattern. The platform and operations teams should know how to isolate the relevant workload or integration if the failure indicates an active exposure.

State failures can be less visible than tool failures. A task might resume with stale status, associate a prior user’s context with a new request, or present an old result as current. Define what state is authoritative and what must be fetched again before a consequential action. Set explicit transitions such as “requested,” “submitted,” “verified” and “needs reconciliation,” rather than using one ambiguous “complete” flag. The application owner defines the meaning; the state owner ensures the stored representation supports it.

Operational evidence should enable a responder to connect a user request to the relevant task, authorization decision, tool request and business result without relying on a model’s narrative. Decide which identifiers are safe and useful to record, which fields must be excluded, who may inspect diagnostic records, and how long they are needed. These are design recommendations for the operating model, not claims about default product behavior. The operations owner should test whether the evidence is actionable before a real incident makes that question urgent.

Finally, test the handoff itself. Give a support engineer a simulated incomplete operation and ask them to identify the application owner, determine who can check the system of record, locate the pause mechanism and find the user communication path. If the answer depends on one developer remembering an undocumented detail, the architecture is not operationally complete. Assign that gap to an owner and close it before expanding the workflow’s scope.

Decide what belongs in the first release

A first release should have a bounded business purpose, a small tool surface and an explicit state policy. A useful scope statement names the user group, permitted task, authoritative business system, consequential effects and conditions that require a human to continue the process. “An assistant for customer support” is too broad to assign or test. “Retrieve delivery status for an identified order and explain it without changing the record” is a more reviewable starting point.

For every proposed action, ask whether the agent needs to perform it or whether it can prepare information for a person to act. That choice affects the blast radius, the authorization design and the incident response. A read-and-explain workflow may still expose sensitive information, but it has different failure consequences from an automated change. Expand permissions only when the next action has a named business owner, an enforceable check and a recovery path.

Compare platform options through responsibility as well as capability. Ask which team operates execution, where caller authorization belongs, how integrations are bounded, who controls retained state, and whether existing operations can support the resulting dependencies. The answer should include the people and processes needed to run the design, not just the components shown in a product comparison. For a broader platform decision, see Microsoft Foundry, Bedrock AgentCore, or Gemini Enterprise: Choosing an Enterprise Agent Platform.

Operational effort also belongs in the decision. Runtime consumption is only one possible part of the work: teams may need to build integrations, define authorization, review retained state, monitor dependencies, investigate uncertain outcomes and support users. Use the workload’s expected call patterns and internal ownership model to make your own estimate rather than treating a platform price as the full cost. The related analysis, What an AI Agent Actually Costs on Bedrock AgentCore, examines cost considerations in more detail.

If several teams are building agent applications, a shared platform pattern can reduce repeated decisions about deployment, service boundaries, observability and escalation. That does not require the platform team to own business authorization or every application integration. Organizations that need help shaping those shared patterns can explore cloud platform engineering.

A usable ownership worksheet

Use this worksheet in a design review and keep the completed answers beside the workflow’s operating instructions. Replace role names with accountable teams or named on-call roles. If an answer is unknown, treat it as an unresolved design decision rather than assuming another layer will provide it.

• Workflow and limits: State the user group, business task, allowed actions and explicit out-of-scope actions. Name the business owner who can change those limits.
• Runtime and release: Name the team that deploys and rolls back the application. Record how a release is identified and what event triggers a pause or rollback.
• Caller identity: State how the application knows which person or calling service initiated the task. Record what happens when that identity context is absent, invalid or no longer current.
• Business authorization: Name the decision point for each consequential action. Identify the business rule owner, the input used to decide, and the behavior when permission is denied.
• Workload access: List the dependencies the running workload can reach. Name who grants and withdraws that access and how the application avoids treating it as permission for every user.
• Tool contract: For each tool, document accepted fields, allowed effects, validation, downstream owner and error meanings. Identify which operations are read-only and which may change a record.
• State: List the fields retained between steps, the purpose of each field, its user or task boundary, who may inspect it and when it is removed or refreshed.
• Business verification: Name the authoritative source used to confirm a result. Define how an uncertain or incomplete state is reconciled before another consequential attempt.
• Operational response: Identify who receives alerts, who can pause the workflow, who investigates downstream records and who communicates with affected users.
• Review evidence: Record the test owner and expected result for denied access, invalid input, unavailable dependencies, uncertain writes and state separation.

For a printable summary, copy the completed worksheet into the team’s design record with the workflow name, accountable application owner, platform owner, business-system owner, security contact and operations escalation route. The record should be concise enough to consult during an incident, but specific enough that a new responder can locate the enforcement point and decide whom to involve.

Revisit it when the workflow gains a new user group, tool, state field or consequential action. Each change can move a boundary: a tool that was read-only may become state-changing; a task that used to be single-user may become shared; a new source of data may introduce a different owner. Treat those changes as architecture and operations decisions, not merely prompt edits.

Close the loop between design and operations

The ownership model is working when teams can answer three questions without inference: who decides whether an action is permitted, where that decision is enforced, and who determines what happened if the result is uncertain. Runtime ownership, identity, integrations, state and operations are related, but they are not interchangeable. Keeping them distinct gives each team a tractable remit and makes the handoffs reviewable.

For a production workflow, start with the matrix and worksheet, then trace one normal request and one failed state-changing request from caller to authoritative result. Confirm that the application owner can explain business authorization, the platform owner can explain release and pause controls, and operations can locate the evidence needed to reconcile an incident. If any handoff depends on an unstated assumption, resolve it before broadening the workflow.

That is the practical answer to who owns each layer: the platform team owns shared execution boundaries; the application team owns business behavior and user-specific decisions; integration and data owners own their contracts and records; security helps define and review access boundaries; and operations owns the response path. The exact team chart will vary. The decisions, enforcement points and handoffs should not be left ambiguous.

WANT TO TALK THROUGH YOUR SITUATION?

Talk it through with us. Thirty minutes, no slides.