Amazon Bedrock Agents Orchestrate Foundation Models. The Agents Have No Structural Definition.
by Nick Clark | Published March 28, 2026
Amazon Bedrock Agents provides managed agent orchestration for foundation models with Action Groups, Knowledge Bases, Guardrails, the Bedrock Agent SDK, multi-agent collaboration, and authoring tooling through Bedrock Studio. Agents invoke APIs, query vector knowledge bases, and maintain session context across multi-turn interactions. The orchestration is capable, the integration with the broader AWS estate is deep, and the operational story is mature. But Bedrock agents have no canonical schema. Each agent is a configuration assembled from independent feature subsystems, not a structurally defined object whose capability, governance, identity, and memory live in typed fields of a single specification. The gap is between agent orchestration capability and a canonical schema that defines what an agent is in a portable, validatable form.
The orchestration is real, the structural definition is not
Bedrock Agents is not a thin wrapper around a foundation model. It performs ReAct-style reasoning loops, decomposes a user request into sub-tasks, selects which Action Group to call, parses model output into API invocations, and stitches results back into the conversation. Knowledge Bases ground responses in retrieval-augmented generation against OpenSearch Serverless or Pinecone. Guardrails filter prompts and completions against content policy. The Bedrock Agent SDK exposes invocation endpoints and trace events. Multi-agent collaboration allows a supervisor agent to delegate to specialist agents. Bedrock Studio provides a visual authoring environment. Each of these subsystems is operationally meaningful.
What none of them provide is a canonical, portable schema for the agent itself. The agent is defined by a service-side configuration record in the Bedrock control plane: an instruction string, a reference to a foundation model, a list of Action Group ARNs, an optional Knowledge Base ARN, an optional Guardrail ARN, a session timeout. That record is queryable through the Bedrock API, but it is not a structurally defined object with typed fields whose meaning is fixed by an interoperable specification. It is a configuration container whose semantics live inside the Bedrock service.
Action Groups expose capability without typing it
Action Groups are how a Bedrock agent acquires capability. An Action Group binds a set of API operations, described by an OpenAPI schema or a function-schema list, to a Lambda function or a return-control handler. The model reads the descriptions and decides when to invoke them. This works. The agent gains the ability to call a payment API, query a CRM, or execute a workflow.
But the Action Group is a configuration attachment, not a typed capability field of a canonical agent schema. Two Bedrock agents with the same logical capability — for example, the ability to issue a refund — express that capability through entirely different Action Group configurations, with no structural commonality that downstream systems can rely on. There is no canonical "capabilities" field whose contents are defined by a published schema and whose values can be validated, compared, or reasoned over by a tool that does not have privileged access to the Bedrock control plane. Capability is implicit in configuration, not explicit in structure.
Knowledge Bases and memory are attached, not structural
A Bedrock agent can be associated with a Knowledge Base for retrieval grounding, and recent additions to the platform expose session memory and long-term memory features that persist context across invocations. These are useful. They are also attachments. The Knowledge Base is a separate resource referenced by ARN. Memory is a service-side store keyed by session and agent identifier. Neither appears in the agent as a typed field with a defined relationship to capability or governance.
The consequence is that an agent's epistemic posture — what it knows, what it remembers, how those interact with what it can do — is not part of the agent's structural definition. It is a set of side-attached resources whose coupling to the agent is enforced by the runtime, not by the schema. A different platform receiving the same agent has no canonical way to reconstruct that posture.
Guardrails as external policy, not intrinsic governance
Bedrock Guardrails filter inputs and outputs against content policies covering harmful content, denied topics, sensitive information, and prompt-injection patterns. Guardrails are useful safety mechanisms and are independently versioned and reusable across agents. But guardrails are external filters applied to the agent's interactions. They are not intrinsic governance fields of the agent. The agent does not carry its governance; governance is applied from outside, by a runtime that knows to invoke a Guardrail ARN before and after model invocation.
If the Guardrail attachment is changed, removed, or replaced, the agent's behavior changes without any change to the agent's own definition. Conversely, an agent exported from Bedrock and rehosted on a different orchestration platform loses its guardrails entirely unless the receiving platform implements an equivalent external filtering mechanism and is configured to invoke it. Governance is bound to the deployment, not to the agent.
Multi-agent collaboration amplifies the schema gap
Bedrock's multi-agent collaboration feature allows a supervisor agent to route work to specialist agents, with the supervisor maintaining conversational state and the specialists handling sub-tasks. This works inside Bedrock because every participant is a Bedrock agent and the routing layer can introspect each participant's configuration through the Bedrock API. Cross the boundary, and the model breaks down. A specialist agent on a different platform cannot be addressed as a structurally typed object. Its capabilities, memory model, and governance posture are not legible through any shared schema. Integration becomes bilateral and bespoke, mediated by hand-written adapters that translate between proprietary configuration formats.
The same is true of Bedrock Studio. Studio is a productive authoring environment, but what it authors is a Bedrock-internal configuration. The artifact is not a schema-defined agent that other tools can validate, lint, diff, or deploy.
What a canonical agent schema provides
A canonical agent schema would make capability, governance, identity, and memory intrinsic typed fields of the agent rather than side-attached resources whose binding is enforced by a single vendor's runtime. Capabilities would be expressed in a defined structure that any compliant platform could parse and validate. Governance would be a field of the agent, not a separately attached filter. Identity would be intrinsic and verifiable. Memory and knowledge would have defined structural relationships to the rest of the agent.
Bedrock's orchestration substrate — Action Groups, Knowledge Bases, Guardrails, multi-agent collaboration, Studio — is a strong foundation. A canonical schema does not displace it. It provides a portable surface above it, so that an agent authored in Bedrock Studio is the same structurally defined object when it is operated on by a tool outside AWS, validated by a governance system that has no access to the Bedrock control plane, or migrated to a successor platform years from now. The orchestration is excellent. The schema is what would let it travel.
