Amazon Bedrock supplies managed foundation-model inference, Guardrails and Knowledge Bases. Amazon Bedrock AgentCore supplies the agent platform around that model layer. In regulated delivery, the distinction matters. Model invocation, agent execution, tool mediation, memory and authorization have different evidence and control requirements.
That said, "Bedrock" is a family of decisions, not a single choice. Here is how I make those decisions in production.
Model choice: portfolio, not pageant
Bedrock's core proposition is multiple model families (Anthropic Claude, Amazon's Nova line, Meta Llama, Mistral and others) behind one API and one set of controls. Treat that as a portfolio strategy:
- Reasoning and orchestration tier. The planner, tool-use loop and final customer-facing composition. Select the smallest model that clears the workflow's tool-selection, grounding, latency and safety thresholds on representative evaluations. A provider or model-family preference is not a substitute for that evidence.
- Volume tier. Routing, classification, extraction, summarisation of tool outputs. Smaller, cheaper models (a fast Claude tier or Nova models) handle the 80%+ of calls where flagship reasoning is waste.
- Embeddings. Titan or other embedding models for Knowledge Bases; pick once, because re-embedding a corpus is a project.
Two operational notes outrank a benchmark. First, cross-region inference can route across a defined region set for throughput and resilience; confirm that set against data-residency commitments and use an appropriate geography-scoped profile. Second, capacity is a real constraint: load-test quota, throttling and recovery behaviour before launch. Consider supported provisioned-throughput options or an explicit quota plan only after measuring the production demand shape.
Keep the model identifier a configuration value. The portfolio only pays off if switching tiers is a deploy, not a rewrite.
Agentcore harness or code-defined runtime
Amazon Bedrock Agents, launched in 2023, is now Amazon Bedrock Agents Classic. AWS states that it will no longer accept new customers from 30 July 2026. Existing customers may continue to use it, but AWS recommends migration to AgentCore. Classic should therefore be treated as existing-estate and migration material.
AgentCore Harness is the greenfield default when a config-defined managed loop fits. Builders declare the model, tools and instructions. Harness supplies the orchestration loop and integrates with Runtime, Gateway, Identity, Memory and Observability. Action groups from Classic map to MCP tools exposed through Gateway. Knowledge Bases can be reached through Gateway or a retrieval tool.
Code-defined agents on AgentCore Runtime retain ownership of the loop while using AgentCore's isolated serverless runtime. LangGraph, Strands, CrewAI and custom code can run there. ECS or EKS remains appropriate when a workload needs container or cluster controls that Runtime does not provide. Step Functions remains valuable above either pattern for durable waits, compensation and explicit business state.
My decision rubric, earned the hard way:
- Choose Harness for a bounded managed loop whose tool, memory and human-interaction needs fit its declared interfaces.
- Choose code-defined Runtime when stage-specific orchestration, advanced multi-agent routing or custom state logic is material.
- Add Step Functions when the business trajectory must survive long waits, explicit compensation or a runtime lifecycle.
- Keep Classic only while migrating an existing estate. Do not select it for a new platform after AWS has announced maintenance mode.
The cost of code-defined orchestration is ownership of loop behaviour, dependencies and application security. Runtime manages hosting and isolation, not the correctness of the agent code. Use Harness unless a named requirement justifies owning the loop.
Guardrails and cedar policy solve different problems
Bedrock Guardrails is a policy layer applied to model inputs and outputs: content filters by category and threshold, denied topics in natural language, word and phrase blocks, PII detection with masking or blocking, and contextual grounding checks that flag responses unsupported by the retrieved source material. Crucially, it applies across models, and via the ApplyGuardrail API, even to flows where the model call is not the integration point.
Policy in AgentCore, generally available since 3 March 2026, is the deterministic authorization layer for tools served through Gateway. It evaluates Cedar policies against principal, action, Gateway resource and tool-input context. Policy uses default-deny and forbid-wins semantics. Natural-language authoring can generate candidate Cedar, but reviewed Cedar is the enforced artefact.
How I deploy it in banks:
- Guardrails are defence-in-depth, not the defence. Prompt design, tool-level authorisation, and output validation in the orchestration layer come first; Guardrails is the platform-level backstop.
- Denied topics carry the compliance load. "No investment advice," "no rate promises": expressed declaratively, versioned, and reviewable by non-engineers. That reviewability is the feature: your compliance team can read the control.
- PII filters on the way in, grounding checks on the way out. Mask customer identifiers before they reach the prompt where the use case allows; gate low-groundedness answers to a fallback response rather than letting them ship.
- Log every intervention. Guardrail trigger events are risk telemetry. A spike in denied-topic hits is a product signal, not just a blocked request.
- Enforce business authority in Cedar and the tool. Guardrails can filter content. They do not decide whether this user may refund this transaction for this amount.
Knowledge bases: managed RAG that earns its keep
Bedrock Knowledge Bases handles ingestion, chunking, embedding, and retrieval against a vector store: with Amazon OpenSearch Serverless as the default and several alternatives (Aurora PostgreSQL/pgvector among them) supported. The RetrieveAndGenerate and Retrieve APIs give you grounded answers with citations back to source chunks, which in a regulated shop is the non-negotiable feature.
Field guidance: chunking strategy matters more than vector store choice. Test hierarchical and semantic chunking against real documents. Keep trust domains and ownership explicit. Filter by metadata at retrieval time, then test the entitlement path. In AgentCore, expose retrieval through Gateway or a code-level tool so the same identity, Cedar policy and trace can follow the request.
Private networking: the part that gets you approved
None of the above reaches production in a bank without this section.
- PrivateLink for AgentCore and Bedrock model APIs. Use interface endpoints where supported and constrain deployment with AgentCore VPC condition keys.
- Private tool egress. AgentCore Gateway can reach private APIs and MCP servers through managed or self-managed VPC Lattice resource gateways.
- Identity-aware ingress and egress. Choose OAuth when downstream calls need end-user delegation. Use workload identity for autonomous access. Do not assume a SigV4 call propagates an end user.
- KMS and retention controls. Apply them to Knowledge Bases, Memory, S3 evidence, and CloudWatch destinations according to data classification.
- Joined telemetry. AgentCore Observability provides OpenTelemetry-compatible traces in CloudWatch. CloudTrail records AWS API activity. Bedrock model invocation logging is separately configured. Join them by a trajectory identifier and filter sensitive payloads.
The report card
AgentCore is AWS's forward platform for regulated agentic AI. Begin with Harness, then move to code-defined Runtime only when the loop requires it. Put tools behind Gateway, credentials in Identity, deterministic rules in Policy and governed continuity in Memory. Feed traces into Observability and use Evaluations for CI/CD and sampled production assessment. Treat Agents Classic as a migration source.
A reference control flow
The regulated pattern places deterministic controls around the reasoning loop. The model proposes steps. Identity, data perimeter, Cedar policy and the tool decide which steps can execute.
| Control boundary | AWS mechanism | What it proves | What it does not prove |
|---|---|---|---|
| Network path | VPC endpoints and endpoint policy | Calls use approved private paths | User authority for the action |
| Runtime identity | AgentCore Identity, IAM or inbound OAuth | Workload or represented user is authenticated | Proposed action is permissible |
| Content policy | Bedrock Guardrails | Configured input or output policy was applied | Tool call is business-permissible |
| Grounding | Knowledge Base citations and metadata | Response points to retrieved material | Source is current unless governed |
| Tool authorization | Gateway plus Policy in AgentCore | Cedar allowed this principal, tool and input | Downstream business state is valid |
| Reconstruction | AgentCore Observability, CloudTrail and invocation logs | Sequence and API activity can be joined | Behaviour quality without evaluation |
| Behaviour assurance | AgentCore Evaluations | Defined evaluators scored test or sampled traces | Regulatory acceptability by itself |
Managed or custom: a consequence matrix
| Bounded consequence | Material consequence | |
|---|---|---|
| Simple control flow | AgentCore Harness with Gateway tools | Harness plus Cedar Policy and approval gate |
| Complex control flow | Code-defined AgentCore Runtime | Checkpointed workflow with explicit state and deterministic execution |
The orchestration choice should follow control complexity, not development convenience. Managed services remove undifferentiated operations. They do not remove accountability for the decision.
Draw the agentcore boundary by responsibility
AgentCore is a set of composable services. Treating it as one opaque agent service produces weak ownership and muddled evidence. A regulated platform should state which responsibility remains in application code and which one is delegated to each managed component.
Harness owns a configuration-defined reasoning loop. Runtime hosts code-defined agents in isolated serverless sessions. Gateway presents tools through a governed MCP interface. Identity gives workloads stable identities and manages inbound and outbound authentication patterns. Policy evaluates Cedar authorization for Gateway tool requests. Memory retains short-term events and derived long-term records. Observability supplies trace integration. Evaluations scores behaviours on demand or against sampled production traces.
The application boundary is still load-bearing. It resolves the business journey, authenticates the channel, classifies consequence, owns durable case state and decides when a person must intervene. Runtime isolation does not supply those decisions. Gateway mediation does not remove the downstream API's obligation to validate live business state.
The resulting responsibility model is precise:
| Concern | Agentcore or bedrock responsibility | Application or domain responsibility | Release evidence |
|---|---|---|---|
| Reasoning loop | Harness-managed loop or Runtime hosting | Instructions, state logic, limits and terminal states | Route coverage and bounded-loop tests |
| Model safety | Bedrock Guardrails application | Business prohibitions and output handling | Block, mask and grounding test cases |
| Tool exposure | Gateway tool discovery and invocation | Tool schema, side effects, idempotency and owner | Contract tests and inventory approval |
| Tool authorization | Cedar evaluation through Policy | Principal attributes, business rules and resource recheck | Allow, deny, forbid and stale-state tests |
| Identity | Workload identity and supported credential flows | User-session mapping, purpose and entitlement | Impersonation and revocation tests |
| Continuity | Memory events and records | Durable workflow checkpoints and retention decision | Resume, deletion and provenance tests |
| Assurance | Traces, metrics and evaluation execution | Acceptance criteria, evaluators and risk decision | Release scorecard linked to traces |
A managed component should remove operational work, not erase the accountable owner. Put that owner beside every box on the architecture diagram.
Authorize the tool call, then recheck the business action
The most important AgentCore control path runs through Identity, Gateway and Policy. It is tempting to stop at IAM because the calling workload has an AWS principal. IAM answers whether the workload can invoke an AWS surface. It does not necessarily answer whether the represented employee can close this alert or refund this transaction.
Policy in AgentCore evaluates each Gateway tool request against Cedar. A sound policy uses trusted principal attributes, the Gateway resource, the named tool and selected input fields. Default deny means unmatched requests fail. A forbid policy takes precedence, which is useful for categorical restrictions such as prohibited operations, geographies or risk states.
Keep model-produced identity claims out of the trusted context. A tool argument such as employee_id is data, not proof. The channel or identity tier should supply the represented person. The gateway or policy integration should use that trusted value. The domain tool should intersect it with live entitlements.
Natural-language policy authoring can accelerate Cedar creation. The output is a candidate policy, not an approval. Review the generated Cedar, test it against positive and negative cases, and retain the reviewed version. Readable authoring does not remove the need for deterministic policy testing.
For actions that must execute once, add a business nonce or idempotency key at the tool. A valid Identity credential and a Cedar permit do not prove that an earlier retry failed before applying the mutation. The system of record owns that fact.
Separate conversation memory from workflow state
AgentCore Memory supports short-term events and long-term records. That distinction is useful, but neither should silently become the authoritative state of a regulated business process. A credit decision, complaint status or payment disposition belongs in the domain case system or durable workflow store.
Short-term memory can preserve conversational events needed across turns. Long-term strategies can extract durable records for future use. Both require provenance, retention, purpose and deletion rules. A derived “customer prefers digital contact” record must point to its source and should not override a formal channel restriction.
Use a three-store pattern. The system of record holds authoritative business state. The workflow checkpoint holds resumable technical state, including completed steps and idempotency markers. AgentCore Memory holds governed conversational continuity and selected derived records. The context assembler retrieves from each according to its authority.
This separation prevents memory consolidation from changing legal or financial truth. It also makes deletion practical. A privacy request can target memory records without erasing the transaction ledger. A workflow retention rule can remove technical checkpoints while preserving required business evidence.
Memory supplies continuity; the case system supplies truth. Confusing the two creates subtle state conflicts that a fluent model can conceal.
Turn traces into a release decision
AgentCore Observability and Evaluations are complementary. Observability captures spans, metrics and logs through OpenTelemetry-compatible instrumentation and CloudWatch. Evaluations applies built-in or custom evaluators on demand and online. Neither decides whether a bank should release a use case. The team must define the scorecard and consequence thresholds.
Build a release set around complete trajectories. Include an ordinary success, ambiguous request, stale knowledge item, malformed tool input, denied authority, prompt injection, tool timeout, retry after an uncertain mutation and human referral. Each trace should retain component versions and the expected control outcome.
Use on-demand evaluations in CI/CD for proposed changes. Use online evaluation on a controlled production sample to detect drift. Pair quality measures with deterministic control measures: missing policy decisions, uncorrelated tool calls, loop-limit hits, absent citations and failed reconstructions. A high answer score cannot offset a missing authority event.
The deployment gate should compare the candidate with the current version by route. Aggregate scores can hide a material regression in a low-volume journey. The scorecard should show the change, confidence in the evidence, affected route, owner and disposition.
Migrate classic by control surface, not feature name
An Agents Classic migration is not a direct search-and-replace exercise. Action groups, knowledge access, session state, traces and authorization may map to different AgentCore components. Start with the control inventory, then select Harness or Runtime.
Catalogue each Classic agent's instructions, action groups, Lambda functions, Knowledge Bases, session attributes, Guardrails, aliases and operational logs. For every action group, decide whether it becomes a Gateway MCP tool and what Cedar policy applies. For every session attribute, decide whether it belongs in workflow state, short-term Memory or trusted identity context.
Run the old and new paths in a non-executing comparison first. Compare tool proposals, retrieved sources, refusal behaviour, latency and token use. Then canary bounded traffic with mutation disabled or routed through approval. Preserve an explicit rollback path until the new trajectory evidence is complete.
Migration is also the time to remove accidental authority. Classic Lambda functions often combine business logic, credential use and broad data access. Split them into narrow tools with typed schemas and local precondition checks before exposing them through Gateway. Do not carry an old blast radius into a newer control plane.
The forward choice is clear, but the migration sequence should remain evidence-led. AgentCore offers stronger composable primitives. The application still has to turn those primitives into a controlled business journey.
Select a deployment pattern by business state
Three patterns cover most regulated deployments. The first is an advisory agent. It reads governed evidence, performs analysis and returns a draft or recommendation. It has no mutation tools. Harness is a strong fit when the loop is bounded and tool access is simple. The main controls are source entitlement, grounding, output policy and trace quality.
The second is a supervised action agent. It can prepare a material tool call, but execution waits for deterministic checks or human approval. Harness or Runtime can supply reasoning. Gateway and Cedar constrain the tool proposal. The application workflow owns the approval and creates a proposal-bound execution event. The domain tool rechecks live state.
The third is a durable case agent. It spans long waits, multiple approvals, compensating actions or events from external systems. Code-defined Runtime may own the reasoning segments, while Step Functions or another durable workflow owns business state and waiting. AgentCore Memory supports conversational continuity, not the workflow ledger.
Do not let a pilot slide from the first pattern into the second by adding a Lambda function. Mutation changes the threat model, recovery model and evidence standard. The tool needs an owner, action classification, idempotency contract, Cedar policy, negative-path evaluation and rollback procedure.
The pattern can also vary within one journey. A complaint assistant may run advisory analysis, propose a redress amount under supervision and then enter a durable wait for customer acceptance. The execution envelope should change only at explicit workflow transitions. Each transition records who authorized the new capability.
Choose the smallest pattern that can represent the business state without hiding it inside model memory. A more managed loop is valuable when its limits match the journey. Explicit workflow is valuable when the state itself is consequential.
Treat the data perimeter as a tested route
A regulated network diagram should identify every ingress, model call, retrieval, tool call and telemetry destination. PrivateLink and VPC configuration can reduce public exposure, but they do not establish data entitlement. Conversely, strong Cedar policy does not prove that traffic followed the approved network path.
Begin with ingress. Authenticate the channel before the request reaches the agent. Decide whether AgentCore receives a workload identity or a delegated user context. Keep the mapping between the channel session and the AgentCore session outside model-editable state.
For model calls, document the Bedrock region and any inference profile. Cross-region inference may improve resilience and throughput, but the profile's destination regions must fit residency and processing commitments. Treat a profile change as a data-routing change and review it accordingly.
For retrieval, classify the Knowledge Base source, embedding store, ingestion bucket and returned metadata. Network isolation does not prevent one entitled agent from retrieving another business unit's content. Metadata filters and domain authorization must align with the source ownership model.
For tools, test both private routing and authorization. AgentCore Gateway can connect to private targets through supported VPC Lattice patterns. The target should still validate the credential, resource scope, request schema and current business preconditions. Record the route and policy result under the same trajectory identifier.
For telemetry, decide which payload fields may reach CloudWatch, model invocation logs and the evaluation store. A complete trace does not require unrestricted prompt retention. Hashes, field-level redaction, selected payload capture and controlled replay stores can preserve causality while respecting data classification.
Finally, test the perimeter through failure. Deny the endpoint policy. Remove the private route in a non-production environment. Present a cross-tenant source identifier. Use a revoked outbound credential. Confirm that the system stops, emits a usable reason and does not fall back to an undocumented path.
A private architecture is a set of verified paths and denied alternatives, not a collection of VPC icons. Put the path evidence in the go-live pack and repeat it after network or identity changes.
Operate agentcore with explicit degradation modes
Production dependencies will weaken independently. A selected model can throttle. Gateway can reach the tool while the downstream service is unhealthy. Evaluations can lag without affecting the live call. Memory can be unavailable while the authoritative case record remains sound. The application should define the permitted degraded state for each dependency.
An advisory journey may fall back to a smaller approved model and label the route in the trace. A consequential journey may allow drafting but disable execution when Cedar Policy, entitlement or audit correlation is unavailable. A durable workflow may pause while preserving its checkpoint. No path should replace missing evidence with model inference.
Operational alarms should follow the journey, not only the AWS service. Monitor unresolved cases, policy denials, failed tool preconditions, replay protection, memory retrieval errors, evaluator drift and missing trace joins. Service availability can look healthy while business outcomes deteriorate.
Runbooks should name the authority to disable a tool, route, model, memory strategy or use case. They should include the customer and operations response for work already in flight. Runtime restart guidance alone is insufficient when a transaction may have reached a system of record.
This operating model completes the report card. AgentCore supplies current managed building blocks. Production readiness is the institution's ability to constrain, observe and safely reduce the capability built from them.
Primary AWS references
- AWS, Agents Classic maintenance mode and migration map.
- AWS, AgentCore overview.
- AWS, AgentCore Harness versus Runtime.
- AWS, AgentCore Runtime.
- AWS, AgentCore Memory.
- AWS, Policy in AgentCore.
- AWS, AgentCore Observability.
- AWS, AgentCore Evaluations general availability.
- AWS, Bedrock Guardrails.
- AWS, Model invocation logging.
- AWS, Private connectivity for AgentCore.
AgentCore is the platform. Production readiness comes from the contracts wrapped around each identity, memory record, evaluation, retrieval and action.