Build a Production AI Agent on AWS with Bedrock

A production AI agent on AWS is not a model with a few tools attached. It is an application with identity, policy, state, failure handling, observability, and an operating owner. Amazon Bedrock supplies managed model access and several agent-building components, but the application still has to decide who may ask for what, which actions are allowed, what requires approval, and how to prove what happened.

This guide presents a practical reference architecture for an agent that uses Amazon Bedrock, AWS Lambda, APIs, enterprise data, and human approval. It focuses on the decisions that remain after a playground demonstration succeeds. Product capabilities and availability change, so the implementation should verify current model, Region, quota, and feature support during design.

Start with an operating contract

Before selecting a model or framework, write a one-page operating contract:

Goal: the outcome the agent is allowed to pursue.
Users: the human and workload identities that may invoke it.
Data: the sources it may read and the classifications it may process.
Tools: the actions it may propose or execute.
Limits: financial, temporal, resource, network, and concurrency boundaries.
Approvals: the decisions that must pause for a person or another policy authority.
Evidence: the logs, traces, decisions, and outcomes that must be retained.
Stop conditions: when the run ends, escalates, or is disabled.

This contract prevents “helpful” scope growth during implementation. It also gives security, operations, and business owners something concrete to review. Bluegrass Cloud’s AI advisory and consulting work begins with the same questions because platform selection is downstream of the use case and its controls.

Choose the Bedrock execution pattern

Managed orchestration with Amazon Bedrock Agents

Amazon Bedrock Agents can orchestrate a selected foundation model, instructions, action groups, and optional knowledge bases. An action group describes functions or an OpenAPI-based interface. Bedrock can invoke a Lambda function for the action or return control to your application with the proposed action and parameters.

This pattern is useful when the managed agent lifecycle matches the requirement and the team wants AWS to handle the core plan-and-tool loop. “Return control” is particularly valuable for sensitive operations because the application can place deterministic authorization and approval between the model’s proposal and the real API call.

Application-owned orchestration with Bedrock model APIs

A custom orchestrator can call Bedrock through the Converse APIs or a supported agent framework, then execute tools itself. This provides more control over state, retries, model routing, approval UX, and vendor portability, but it also makes the team responsible for the loop and its edge cases.

Amazon Bedrock AgentCore can provide production-oriented runtime, gateway, identity, policy, memory, and observability components for custom agents. It is not a requirement for every application. A short synchronous workflow may fit Lambda; a long-running or stateful agent may be better suited to a dedicated runtime. Select the runtime based on execution duration, isolation, concurrency, networking, and operational requirements rather than novelty.

Use deterministic orchestration around either option

Keep durable business state outside the prompt. A workflow engine, queue, or application database should record request state, approval state, retries, and final outcome. Model context is useful working memory, but it is not a transaction log. For broader architecture planning, Bluegrass Cloud’s cloud strategy and architecture service can help place the agent inside the surrounding application rather than treating it as an isolated component.

A production reference architecture

Client and identity layer: A web application, internal tool, or service authenticates the caller. The application carries the caller’s identity and relevant authorization context into the request.
API and request service: An API endpoint validates schema, size, content type, rate, and tenant boundaries. It assigns a correlation ID and writes an initial immutable event.
Orchestrator: A Lambda function, container service, Step Functions workflow, or AgentCore Runtime manages the agent turn, tool loop, timeout, and state.
Amazon Bedrock: The orchestrator invokes an approved model or Bedrock agent alias in an approved Region or inference profile.
Knowledge and data layer: Retrieval services access only the sources authorized for the caller and task. Results are labeled as untrusted data before entering model context.
Tool boundary: Action groups, Lambda functions, an AgentCore Gateway, or application APIs expose narrow operations. Policy evaluates every proposed action.
Approval service: Consequential actions are stored as proposals and presented with target, parameters, evidence, expected effect, expiration, and approver identity.
Execution service: Deterministic code performs the authorized operation with a scoped workload identity and verifies the downstream response.
Observability and audit: Application logs, metrics, traces, CloudTrail events, and selected Bedrock telemetry connect the request to tool calls and final outcome.

The important boundary is between proposing an action and authorizing it. The model may choose a tool, but a trusted service should decide whether this caller, agent, action, resource, and set of parameters is allowed now.

Model access and regional design

Bedrock model availability and access rules vary by provider, account, and Region. Some serverless models sold through AWS Marketplace can be enabled automatically on first invocation when the caller has the required Marketplace permissions. Organizations should separate that one-time administrative capability from the runtime role. A production agent should not be able to subscribe itself to new models.

Pin the application to an approved model identifier or inference profile through configuration. Test the specific model for task quality, tool selection, structured output, latency, and refusal behavior. Do not select solely from a general benchmark.

Inference profiles can route requests across Regions and can also help track model usage and cost. Geographic and global cross-Region profiles have different data-location implications. Review the destination Regions, service control policies, IAM requirements, and data-residency obligations before enabling cross-Region routing. Availability improves only if the routing policy is acceptable to the organization.

Use separate IAM roles for separate responsibilities

A common early mistake is one execution role with permission to invoke models, read every data source, retrieve every secret, and perform every tool action. That role turns any agent error into a large blast radius.

At minimum, separate these identities:

Caller role: allowed to invoke one deployed API or agent alias.
Agent service role: allowed to invoke only approved model resources and required orchestration services.
Tool execution roles: one per tool or risk group, scoped to specific actions and resources.
Deployment role: allowed to create or update agent resources, but not used at runtime.
Logging delivery roles: allowed to write to designated destinations, not read application data.

The following illustrative policy lets an application invoke one Bedrock agent alias. Replace every placeholder and validate the policy for the deployed Region and account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeOneProductionAgentAlias",
      "Effect": "Allow",
      "Action": "bedrock:InvokeAgent",
      "Resource": "arn:aws:bedrock:us-east-1:111122223333:agent-alias/AGENT_ID/ALIAS_ID"
    }
  ]
}

This is intentionally narrower than a policy used to build or edit an agent. Use explicit resource ARNs and applicable condition keys. Validate policies with IAM Access Analyzer, and use organization-level controls when model or Region access must be constrained across accounts.

Design tools as production APIs

A tool name and description are an interface presented to a probabilistic caller. The implementation behind it should still behave like a defensive API:

Use a small schema with clear types, bounds, and descriptions.
Separate read operations from writes and destructive operations.
Validate and normalize every argument outside the model.
Derive tenant, user, and authorization context from trusted identity, not model-supplied fields.
Make writes idempotent with a request key where possible.
Set timeouts and bounded retries; return structured errors.
Return only the data needed for the next decision.
Record the proposed call, policy result, execution result, and downstream identifier.

Bedrock action groups can request user confirmation before invoking a function. That can reduce risk, but the confirmation should be only one layer. Sensitive business rules still belong in the tool or policy service. If a refund limit is $500 for a particular role, enforce that in authorization code; do not rely on a prompt telling the model to remember it.

Keep secrets out of prompts and tool schemas

Use IAM roles and temporary credentials for AWS access. Store third-party API credentials in AWS Secrets Manager when that service’s rotation and lifecycle fit the requirement. Let the tool runtime retrieve the secret at execution time through its scoped role. The model should receive neither the secret value nor permission to request arbitrary secret names.

Cache secrets in the runtime only when appropriate, avoid writing them to logs, and redact them from exception messages. Environment variables can hold non-secret configuration, but placing a long-lived secret directly in a Lambda environment variable increases exposure to anyone or anything that can read function configuration.

Retrieve data with an authorization filter

Retrieval-augmented generation does not automatically enforce access control. If a knowledge base contains records for multiple departments or customers, the application must filter retrieval by the caller’s authorized scope. Do not retrieve broadly and ask the model to ignore records the user should not see.

Preserve source identifiers and access labels with retrieved chunks. Limit the number and size of results, remove unnecessary sensitive fields, and make citations available to the user where appropriate. Treat retrieved content as untrusted: documents can contain instructions that conflict with the application’s policy.

Build human approval as a real transaction

An approval gate should persist a canonical proposal, not merely repeat a model-generated summary. Store:

the exact action and normalized parameters;
the target resource and affected identity or tenant;
the requesting user and agent run;
the evidence used to propose the action;
the expected effect and rollback path;
an expiration time and single-use nonce; and
the approving identity, decision, timestamp, and any comment.

Reauthorize at execution time. The world may have changed after approval, and the approver’s authority may have expired. If parameters change, require a new approval. This prevents the agent from obtaining approval for one action and executing another.

Observability needs three different views

Application behavior

Measure requests, successful outcomes, incomplete runs, validation failures, approval rates, tool error rates, time to completion, and human corrections. A model response with HTTP 200 is not a successful business outcome.

Agent behavior

Trace model calls, tool selections, policy decisions, loop count, token use, latency, and stop reason. AgentCore provides built-in metrics for several resource types and supports richer traces and custom metrics through AWS Distro for OpenTelemetry instrumentation. CloudWatch Transaction Search requires explicit setup for the full trace view.

Security and platform behavior

Use CloudTrail for relevant AWS API activity and alert on changes to agent configuration, IAM, gateways, guardrails, and logging. Bedrock model invocation logging can send request, response, and metadata to CloudWatch Logs or Amazon S3, but it is disabled by default. Enabling it may store sensitive prompts, outputs, images, or documents. Decide deliberately what to capture, encrypt it, restrict readers, set retention, and redact at the application boundary where feasible.

Bluegrass Cloud’s managed cloud operations service can help define the monitoring and operating ownership for an agreed AWS workload after the implementation scope is established.

Engineer for throttling, partial failure, and bad plans

Production traffic will encounter quotas, transient service errors, downstream timeouts, malformed model output, unavailable tools, and runs that do not converge. Design explicit behavior for each:

Use exponential backoff with jitter for retryable calls, within a total deadline.
Do not blindly retry a write unless the operation is idempotent.
Limit agent turns, tool calls, wall-clock duration, and per-run spend.
Use a dead-letter or review queue for requests that need intervention.
Expose a truthful status to the user: queued, running, awaiting approval, completed, partially completed, or failed.
Deploy a kill switch that blocks new runs and tool execution independently of the model.
Keep a deterministic fallback for critical read paths where possible.

Evaluate before and after deployment

Create a versioned evaluation set from representative tasks. Include ordinary cases, ambiguous input, missing data, conflicting sources, tool failures, unauthorized requests, prompt injection attempts, and actions near approval thresholds. Score the whole system: final correctness, tool choice, argument validity, policy compliance, citation quality, refusal behavior, latency, and cost.

Run the same set when the model, instructions, tool descriptions, retrieval pipeline, or policy changes. In production, sample completed runs for review and convert novel failures into regression cases. Model behavior can shift even when application code does not, so release management must cover configuration and model dependencies too.

Production readiness checklist

The use case, users, data, tools, and stop conditions are documented.
Model and Region access are approved and pinned through configuration.
Runtime and deployment roles are separate and least-privileged.
Tools validate arguments and enforce authorization outside the prompt.
Secrets are retrieved by scoped runtimes and never sent to the model.
Retrieval applies source-level access controls before data reaches context.
Consequential operations create durable, expiring approval proposals.
Retries, idempotency, deadlines, loop limits, and failure states are defined.
Logs, traces, metrics, alerts, retention, and redaction are reviewed.
Evaluation covers routine, failure, security, and adversarial cases.
A kill switch and incident owner exist, and operators have tested them.

Build the system, not just the agent loop

Amazon Bedrock can reduce the infrastructure required to access models and assemble agent capabilities. Production quality still comes from the surrounding engineering: bounded authority, narrow tools, durable state, explicit approvals, truthful status, and evidence an operator can use.

For help designing or implementing a controlled agent on AWS, contact Bluegrass Cloud with the intended workflow, connected systems, data constraints, and production ownership model.

Building a Production AI Agent on AWS with Amazon Bedrock