Agentic Data Engineering Resources

Resource

Amazon Bedrock Agents Explained: What They Do and What Still Depends on Your Data Layer

Amazon Bedrock Agents handle orchestration, but unified records, permissions, freshness, and cross-system context still depend on your data layer.

Pedro Lopez

August 13, 2026

Summarize with AI:

Amazon Bedrock Agents is AWS's managed service for building AI agents. It uses foundation-model reasoning, where a model plans steps, while your data layer still must unify operational records across a company's SaaS systems. That boundary matters because sound orchestration cannot compensate for context that is stale, fragmented, or broader than the requesting user may access. An agent can plan the right steps and invoke the right tools, yet still make an incomplete decision if records have not been re-indexed, identities do not match across systems, or source permissions do not propagate into the answer.

TL;DR

Bedrock Agents can run a three-stage sequence (pre-processing, orchestration, post-processing).
Action groups execute tools, while Knowledge Bases retrieve context.
Knowledge Base sync is incremental, so indexed results reflect changes only after a re-index; live tools can retrieve current state instead.
Your data layer still handles permission propagation, cross-SaaS queries, and entity resolution, which recognizes the same account across systems.
Read-only agents can only describe work; write capability is what turns a Bedrock agent from a reporter into an operator.

Try Airbyte Agents

What Are Amazon Bedrock Agents?

Amazon Bedrock Agents is a managed orchestration service. You give it a foundation model, instructions, and tools, and it plans and executes tasks across multiple steps.

The InvokeAgent API can run a three-stage sequence. Pre-processing interprets the input and generates a rationale before orchestration predicts which action group or Knowledge Base to call. Post-processing then runs before the response reaches the caller. Knowledge Bases feed that loop with managed RAG, which retrieves material from connected sources and adds it to the model prompt.

That orchestration loop manages how the agent reasons and acts, but the tools and retrieval sources determine what data it can use.

What Do Bedrock Agents Handle Natively?

Classic provides managed facilities for prompt orchestration, session memory, monitoring, encryption, permissions, and action invocation. These facilities reduce, but do not eliminate, custom integration code; Lambda or return-control handlers still implement external operations. AgentCore separates these capabilities into services. Identity holds API keys and OAuth tokens, while Observability carries monitoring.

Action Groups Define Operations for Lambda or Caller Execution

An action group can define operations through an OpenAPI schema or function details, then invoke a Lambda function or return control to the application for execution. It is Bedrock Agents Classic's primary bridge to systems outside AWS. The schema or function details declare the operations and their parameters; the handler still manages permissions, joins, failures, and other integration behavior for each call.

Knowledge Bases Manage the Retrieval Pipeline

Knowledge Bases runs the RAG workflow, from ingestion through prompt augmentation. AWS tutorials use S3 as an ingestion source. Beyond S3, the Managed Knowledge Base ships six pre-built AWS data-source integrations. It uses document-level access control list (ACL) checks to enforce document access rules. For live tool access, AgentCore Gateway adds MCP support. It includes pre-built MCP integrations for Redshift, Aurora, and OpenSearch.

These native capabilities provide the runtime path, while data freshness, record identity, and source-level access remain separate concerns.

Which Data Dependencies Does Bedrock Leave Open?

Bedrock Agents Classic and AgentCore leave freshness, entity resolution, source permissions, and cross-system truth to the data layer.

Re-Indexing Creates Stale Answers

Indexed Knowledge Base retrieval leaves freshness unresolved because every add, modify, or delete waits for a re-index before the agent sees it there. For example, a refund-approval workflow can reason over the last re-index rather than the customer's current order status unless it uses a live tool to retrieve current operational data.

Entity Resolution Remains External

Fragmented truth remains because the same account exists as separate records in CRM, support, and billing. Your data layer still has to provide entity resolution, which recognizes that records in those systems describe the same account. In a hypothetical account-risk query, the answer may need the open opportunity in Salesforce, the escalated ticket in Zendesk, and the unpaid invoice in billing. AWS data-source integrations and action groups expose sources and APIs; they do not tell the agent those records describe one customer.

Source Permissions Must Propagate

Permissions also depend on the data layer because source-application row-level rules still have to reach every answer. Managed Knowledge Base enforces document-level ACL checks on files it ingests, and AgentCore Gateway provides fine-grained access control for tools and parameters. A rep's Salesforce sharing rules decide which opportunities they can see. For example, a hypothetical pipeline query for a territory that the rep cannot see may produce an answer from an index or tool response that never carried the sharing rule. Your AI data infrastructure must preserve and enforce source-system permissions because the runtime does not automatically own that job.

Write Capability Turns Reporters Into Operators

Read-only agents can only describe work. Without a write path, a Bedrock agent can summarize an overdue invoice or an escalated ticket, but it cannot post the update, create the record, or close the loop. Retrieval alone leaves the operator step to a human, so the data layer must expose governed write actions alongside reads for the agent to actually act on what it sees.

If those controls fail, the agent can combine contradictory records or expose data beyond the user's scope.

Where Does the Boundary Between Bedrock and Your Data Layer Sit?

Use the table to create a pre-production validation checklist before committing engineering time:

Inventory required sources, record types, and join keys.
Define freshness targets and source-permission requirements for each query class.
Test expired credentials, revoked access, partial API failures, and retry behavior.
Measure p95 task latency, prompt size, and TPM use across multi-step tasks.
Validate account and regional quotas before launch.
Choose live tools, indexed retrieval, or pre-materialized context for each query class.

Decision area	Bedrock-only fit	Add a data layer when
Orchestration and context budget	The application can budget and trim the input sent through Bedrock's configurable sequence	Multi-turn context growth requires smaller, pre-materialized payloads on every turn
Tool execution	Developers define action groups with an OpenAPI schema or function details and use Lambda invocation or return-control execution	Teams need maintained, typed agent connectors that reduce the agent-connector and API-integration code behind handlers and survive vendor API changes
Retrieval	Knowledge Bases can handle managed RAG from ingestion to retrieval and prompt augmentation	Operational questions require keyed lookups of specific records through tools
Source coverage	Knowledge Base data sources: S3, Confluence, SharePoint, Salesforce, Web Crawler, and Custom. Managed Knowledge Base data sources: S3, SharePoint, Confluence, Web Crawler, Google Drive, OneDrive. AgentCore Gateway adds MCP support, with pre-built AgentCore MCP integrations for Redshift, Aurora, and OpenSearch	The request path includes support, billing, messaging, or product analytics in one queryable layer
Freshness	Re-index delays meet the workload's requirements, or live tools can retrieve current state	Operational decisions require freshness measured in seconds, such as refund approval against current order status
Identity and access	AWS identity and access management (IAM), encryption, user permissions, and AgentCore Identity cover the required access model	Retrieval filters and tool responses must carry Salesforce sharing rules, Zendesk ticket visibility, or other source-system permissions
Cross-system truth	Each request can rely on one knowledge base or action group	One answer must recognize the same account across CRM, ticketing, and billing records
Write actions	Read-only retrieval satisfies the workflow	The agent needs to create, update, or close records to complete the task

Where several rows land on the right, teams can assemble context at runtime, turn by turn and API by API. They can also query a pre-materialized Context Store that already holds the pre-indexed records, though cross-source entity resolution across those records is still on the roadmap.

What Production Failures Do Teams Hit With Bedrock Agents?

Production failures often appear at the boundaries between runtime orchestration, account capacity, credentials, and growing context. Testing these boundaries before launch prevents a single failed dependency from invalidating a multi-step task.

Quotas Interrupt Multi-Step Tasks

A quota ceiling can reject or delay requests beyond available capacity, preventing the agent from completing a multi-step task inside an interactive latency budget. Teams should validate account and regional limits under expected concurrency before launch.

Sequential Calls Increase Latency

Latency increases as model invocations increase. Pre-processing and post-processing add work to the request path, so teams should turn off stages a use case does not need. Multiple sequential turns can increase total response time until an otherwise accurate workflow no longer fits interactive use.

Context Growth Raises Token Pressure

The context budget is the amount of model input the application sends per turn. The application owns context engineering, which determines what the agent sees per turn. Repeatedly carrying prior context increases token use and consumes more TPM, leaving less headroom under a fixed ceiling. Smaller pre-materialized payloads can reduce that pressure, but only if they preserve the records and permissions required for the decision.

Credential Failures Break Tasks Mid-Turn

An expired OAuth token or revoked source credential can cause a tool call to fail after earlier steps have already returned data. The handler should distinguish authentication failures from transient API errors, refresh the token only through the approved credential flow, and request reauthorization when refresh is unavailable. The agent should label the result incomplete rather than present partial source data as a complete answer.

Without prepared, governed context, latency or a mid-turn failure can leave the agent making an incomplete decision.

How Does Airbyte Agents Supply the Context Bedrock Doesn't Provide?

Airbyte Agents is the context layer for AI agents that sits underneath Bedrock's orchestration runtime. It gives you 50+ agent connectors, one Managed Auth flow, and pre-materialized context. Airbyte prepares those records before the runtime turn, so agents can query them instead of assembling context at runtime. The Context Store indexes records from each connected source into one queryable layer; cross-source entity resolution is on the roadmap. Teams can reach that context from the Agent CLI, Agent MCP at mcp.airbyte.ai/mcp, Agent SDK, the Web app, and API. Agent MCP works with Claude, Claude Code, ChatGPT, Codex, Cursor, VS Code, and Windsurf. Managed Auth covers both platform credentials and agent connector credentials, with automatic OAuth refresh.

In our launch benchmark across Gong, Linear, Salesforce, Slack, and Zendesk, pre-materialized context produced 40% fewer tool calls and up to 80% fewer tokens per query.

Agent connectors also expose typed write actions, so the same layer that feeds retrieval lets the agent create, update, and close records through a direct API request rather than a separate integration surface.

Airbyte's security and compliance posture includes SOC 2 Type II, ISO 27001, GDPR support, and HIPAA support. These programs and infrastructure capabilities support governed data access but do not replace source-level permission enforcement.

Should You Run Bedrock Agents Without a Separate Context Layer?

Run Bedrock without a separate context layer when each request can rely on one Knowledge Base or action group and its freshness and access model fit Bedrock's native controls. Add a separate layer when operational decisions require current records, source-permission propagation, entity resolution, write actions, or context spanning multiple SaaS systems. Bedrock handles planning, retrieval, and tool invocation, while the data layer determines whether the resulting context is current, unified, governed, and actionable.

Airbyte Agents fills that boundary with 50+ agent connectors, Managed Auth, and pre-materialized context available through the Agent CLI, Agent MCP, Agent SDK, the Web app, and API.

Get a demo to see how Airbyte Agents supplies pre-indexed context beneath a Bedrock agent runtime.

Frequently Asked Questions

How should teams test Bedrock account access before launch?

Teams should validate account access, regional availability, and quotas before production deployment. Tests should include expected concurrency, revoked credentials, partial API failures, and retry behavior.

What structural limits do Bedrock Knowledge Bases have?

Knowledge Bases and related APIs operate under regional service quotas. Teams should verify the current limits for the intended account and region before launch and test the workload against them.

What should teams measure before estimating AgentCore cost?

Teams should measure usage for the selected services, along with model invocations, tool calls, prompt size, and multi-step task volume. Production estimates should reflect the specific Runtime, Gateway, Memory, Identity, and Observability services the deployment uses.

Can a Bedrock Agent query Salesforce and Zendesk in one turn?

Structured, transactional records like open opportunities and ticket queues fit action groups better than a Knowledge Base, making the request a two-action-group design. The orchestration loop decides which tools to invoke, while the Lambda or return-control handler supplies the join key. The execution handler's response contract must also define whether to retry, degrade, or return an incomplete answer after a partial failure.

When should Bedrock use a Knowledge Base instead of an action group?

Use a Knowledge Base when the agent needs indexed retrieval across documents and the re-index schedule meets the workload's freshness requirements. Use an action group when the task needs a keyed lookup, a transaction, or the current state of an operational record. A single workflow can use both when document context and live operational data serve different parts of the task.

Try Airbyte Agents

Airbyte connects your agents to all of your data and assembles context before they run. Build agents that actually know your business.

Try it free Talk to sales

Amazon Bedrock Agents Explained: What They Do and What Still Depends on Your Data Layer

Related posts

Try Airbyte Agents