Cargando...
Cargando...
Stop confusing AI agent frameworks with workflow engines — know exactly which to reach for and why
AI reasoning agents vs. agent infrastructure runtime vs. deterministic workflow orchestration
| Feature | Amazon Bedrock Agents LLM-powered autonomous task agents | Amazon Bedrock AgentCore Runtime infrastructure for production agents | AWS Step Functions Deterministic visual workflow orchestration |
|---|---|---|---|
Primary Purpose Bedrock Agents = the 'brain' (LLM reasoning). AgentCore = the 'body' (runtime plumbing). Step Functions = the 'flowchart' (deterministic logic). These are complementary, not mutually exclusive. | Build AI agents that autonomously plan, reason, and execute multi-step tasks using foundation models and tools | Provide the managed runtime infrastructure (memory, sessions, tools, identity) that production-grade agents need to operate reliably | Orchestrate deterministic, auditable workflows across AWS services using state machines with explicit branching logic |
Decision-Making Model CRITICAL EXAM TRAP: If a question requires predictable, auditable, compliance-friendly execution paths, Step Functions wins. If the task requires dynamic reasoning over unknown inputs, Bedrock Agents wins. | Non-deterministic: the foundation model autonomously decides which actions to take, in what order, based on natural language goals | Infrastructure-agnostic: provides the runtime environment regardless of how decisions are made — supports both agentic and deterministic patterns | Fully deterministic: every transition, branch, and retry is explicitly defined by the developer in Amazon States Language (ASL) |
Underlying Technology AgentCore is NOT a model or an agent framework — it is the managed backend infrastructure layer that agents run on top of. | Foundation Models (FMs) via Amazon Bedrock — Claude, Titan, Llama, etc. — with ReAct-style reasoning loops (Reason + Act) | Managed runtime services: AgentCore Memory (persistent state), AgentCore Sessions, AgentCore Tools (browser, code interpreter), AgentCore Identity (OAuth/OIDC gateway) | Amazon States Language (ASL) — JSON-based state machine definition. Supports Standard and Express Workflows |
Workflow / Execution Type Step Functions Standard Workflows have exactly-once semantics — critical for financial transactions. Express Workflows sacrifice exactly-once for throughput. | Agentic loops: plan → act → observe → reflect → repeat. Non-linear, emergent execution path determined by LLM | Provides session management and memory so agentic loops can persist state across turns and across agent invocations | Standard Workflows: exactly-once, durable, up to 1 year. Express Workflows: at-least-once, high-throughput, up to 5 minutes |
Human-in-the-Loop For formal, auditable human approval gates in regulated workflows, Step Functions .waitForTaskToken is the canonical AWS answer. For conversational human-agent collaboration, Bedrock Agents Return Control is correct. | Supports 'Return Control' mode — agent can pause and return control to the caller application for human approval before proceeding | Session persistence enables multi-turn human-agent conversations; memory ensures context is not lost between human interventions | Native .waitForTaskToken pattern — workflow pauses indefinitely until a human (or external system) sends a task token callback; integrates with SES, SNS, SQS for notifications |
Tool / Action Integration Step Functions can call Bedrock models directly (InvokeModel) without Lambda — a common cost-optimization pattern tested on SAA-C03 and DVA-C02. | Action Groups backed by Lambda functions or OpenAPI schemas; Knowledge Bases for RAG; Guardrails for safety; supports inline agents and multi-agent collaboration | AgentCore Tools: managed browser tool (web browsing), code interpreter (sandboxed Python execution), custom tool registry; AgentCore Gateway for API federation | 200+ AWS service integrations via optimized SDK integrations (no Lambda needed); Lambda, ECS, Glue, SageMaker, Bedrock, DynamoDB, SNS, SQS, EventBridge, and more |
Memory and State Persistence AgentCore Memory is the AWS-managed answer to 'how do agents remember things across sessions without building custom persistence layers.' This is a new capability that differentiates AgentCore from raw Bedrock Agents. | Session-level context within a conversation; optional memory summarization across sessions (requires configuration); stateless between sessions by default | AgentCore Memory: purpose-built, managed persistent memory store for agents — stores episodic, semantic, and procedural memory across sessions without custom DynamoDB/S3 plumbing | Execution context held in state machine execution history; data passed between states via InputPath/OutputPath/ResultPath; not designed for long-term AI memory |
Security and Identity AgentCore Identity solves the 'how does my agent securely call a third-party API without hardcoding credentials' problem. This is distinct from Guardrails (which is content safety, not auth). | IAM roles for agent execution; Bedrock Guardrails for content filtering, PII redaction, topic denial; resource-based policies | AgentCore Identity: managed OAuth 2.0 / OIDC gateway — agents can authenticate to external APIs and services on behalf of users without exposing credentials in prompts | IAM execution roles; resource-based policies; supports VPC endpoints; CloudTrail logging for all API calls; no built-in OAuth delegation |
Observability and Auditing MISCONCEPTION TRAP: CloudWatch Logs show runtime behavior; CloudTrail records API calls made TO the service. For compliance audit trails proving WHO called WHAT API WHEN, CloudTrail is always the answer — not CloudWatch Logs. | CloudWatch Logs for agent traces (reasoning steps, action invocations); CloudTrail for API audit; Bedrock model invocation logging | Inherits Bedrock observability; AgentCore Sessions provide structured session-level logs; integrates with CloudWatch for metrics | Full execution history in console and CloudWatch; X-Ray tracing; CloudTrail for API calls; every state transition is logged — gold standard for compliance auditing |
Responsible AI / Guardrails CRITICAL MISCONCEPTION: Step Functions workflow orchestration does NOT provide responsible AI protections. Guardrails are a Bedrock-layer capability. Confusing workflow control flow with ethical AI safeguards is a top AIF-C01 exam trap. | Native integration with Amazon Bedrock Guardrails: content filtering, denied topics, word filters, PII redaction, grounding checks (hallucination detection) | Leverages Bedrock Guardrails through the agent runtime; does not add new guardrail capabilities but ensures guardrails are applied consistently in production | No built-in AI safety mechanisms — Step Functions orchestrates deterministic logic and has no concept of LLM content filtering or bias detection |
Multi-Agent Orchestration For multi-agent AI systems, Bedrock Agents (with AgentCore backing) is the correct answer. Step Functions can sequence Bedrock API calls but cannot implement agent-to-agent reasoning delegation. | Supports multi-agent collaboration: a supervisor agent can invoke sub-agents as action groups, enabling hierarchical agent architectures | Provides the runtime infrastructure (sessions, memory, tools) for each agent node in a multi-agent system; agents share the same managed backend | Can orchestrate multiple Lambda functions or ECS tasks that each call Bedrock independently, but has no native concept of AI agent collaboration or LLM reasoning delegation |
Pricing Model Step Functions optimized SDK integrations (e.g., directly calling DynamoDB or SNS) are cheaper than routing through Lambda. This is a frequent cost-optimization question on SAA-C03 and DVA-C02. | Pay for: (1) Foundation model tokens consumed during reasoning and generation, (2) Knowledge Base retrieval costs if RAG is used, (3) Lambda invocations for action groups | Pay for: AgentCore-specific capabilities (Memory storage, Sessions, Tools usage, Identity gateway calls) — pricing is per-use for each managed capability consumed | Standard Workflows: per state transition. Express Workflows: per execution duration and memory. First 4,000 state transitions/month free (Standard). No charge for AWS SDK integrations vs. Lambda reduces cost significantly |
Latency Profile For real-time, low-latency orchestration (IoT event processing, streaming pipelines), Express Workflows are the answer. Bedrock Agents are inherently higher latency due to LLM inference. | Higher latency: each reasoning step requires an LLM call (seconds per step); multi-step tasks can take 10s to minutes depending on model and complexity | Infrastructure adds minimal overhead; latency is dominated by the agent's LLM reasoning steps and tool calls, not the AgentCore runtime itself | Express Workflows: sub-second to seconds (optimized for high-throughput). Standard Workflows: designed for durability over speed; not optimized for real-time |
Execution Duration Limits TRAP: Lambda cannot run longer than 15 minutes regardless of how it is invoked — including from Bedrock Agents action groups or Step Functions. Design around this with ECS tasks or Step Functions for long-running work. | Agent session timeout is configurable; individual action group Lambda functions are subject to Lambda's maximum timeout (15 minutes per invocation) | Session duration governed by AgentCore Session configuration; designed for long-running agentic interactions spanning multiple turns | Standard Workflows: maximum execution duration of 1 year. Express Workflows: maximum duration of 5 minutes |
Ideal Use Cases | Customer service bots, IT automation agents, research assistants, code generation pipelines, autonomous data analysis, dynamic Q&A over enterprise data | Production-hardening any Bedrock Agent deployment: adding persistent memory, secure external API access, managed code execution, and browser-based tool use without building custom infrastructure | ETL pipeline orchestration, microservices choreography, order processing workflows, ML training pipelines (SageMaker Pipelines alternative), compliance-required audit trails, long-running business processes |
Anti-Patterns (When NOT to Use) AgentCore is NOT a replacement for Bedrock Agents or Step Functions. It is an additive infrastructure layer. Exam questions may try to position it as a standalone orchestrator. | Do NOT use when: execution path must be 100% deterministic and auditable for compliance; when latency SLA < 1 second; when no LLM reasoning is needed | Do NOT use as a standalone service — it is a runtime enhancement layer for agents, not a standalone orchestration or agent-building tool | Do NOT use for: open-ended natural language task completion; dynamic tool selection based on LLM reasoning; conversational AI applications requiring semantic understanding |
Complementary Usage Pattern The MOST POWERFUL pattern: Step Functions (outer deterministic orchestration) → invokes Bedrock Agent (inner AI reasoning with AgentCore runtime) → returns structured result → Step Functions continues. Know this architecture for SAA-C03 and SAP-C02. | Bedrock Agents can be invoked as a task within a Step Functions workflow — e.g., Step Functions triggers an agent for a reasoning-heavy subtask, then continues deterministic processing of the result | AgentCore wraps Bedrock Agents to add production capabilities; the combination of Bedrock Agents + AgentCore is the full production AI agent stack | Step Functions orchestrates the outer workflow (trigger → validate → invoke agent → process result → notify) while Bedrock Agents handles the inner AI reasoning loop |
Summary
Amazon Bedrock Agents provides the LLM-powered reasoning engine for autonomous, goal-directed AI tasks. Amazon Bedrock AgentCore is the managed runtime infrastructure layer that makes those agents production-ready by adding persistent memory, secure identity, and managed tools — think of it as the operational backbone you would otherwise build yourself. AWS Step Functions is the right choice when you need deterministic, auditable, and visually traceable workflow orchestration across AWS services, and it complements both Bedrock services by providing the outer workflow shell within which AI agents can be invoked as intelligent subtasks.
🎯 Decision Tree
If the task requires NATURAL LANGUAGE UNDERSTANDING and AUTONOMOUS REASONING over dynamic inputs → use Amazon Bedrock Agents. If those agents need PERSISTENT MEMORY, SECURE EXTERNAL API ACCESS, or MANAGED TOOL USE in production → add Amazon Bedrock AgentCore. If the workflow requires DETERMINISTIC EXECUTION, COMPLIANCE AUDIT TRAILS, EXACTLY-ONCE SEMANTICS, or ORCHESTRATING MULTIPLE AWS SERVICES with explicit branching → use AWS Step Functions. If you need BOTH AI reasoning AND deterministic orchestration → use Step Functions as the outer orchestrator invoking Bedrock Agents for reasoning-heavy steps.
CRITICAL — Responsible AI vs. Workflow Orchestration: Step Functions provides workflow control flow and audit trails but has ZERO built-in AI safety mechanisms. Bedrock Guardrails (attached to Bedrock Agents) provide content filtering, PII redaction, and hallucination grounding checks. A question asking 'how do you prevent an AI agent from generating harmful content' → Bedrock Guardrails. A question asking 'how do you ensure each step of a business process is logged and auditable' → Step Functions. Never conflate these two.
CRITICAL — CloudTrail vs. CloudWatch for Audit: CloudWatch Logs captures runtime application logs and agent reasoning traces. CloudTrail captures API-level audit records (who called which AWS API, when, from where). For compliance questions asking about audit trails proving API access — the answer is ALWAYS CloudTrail, not CloudWatch Logs. This misconception appears across SAA-C03, SAP-C02, and AIF-C01.
CRITICAL — Lambda 15-Minute Hard Limit: Lambda functions used as Bedrock Agent action groups, Step Functions tasks, or standalone invocations CANNOT run longer than 15 minutes. If an exam question describes a task that might run longer (large file processing, ML training, long-running ETL), the correct answer involves ECS Fargate, AWS Batch, or Step Functions Activity Tasks — NOT Lambda with a higher timeout.
IMPORTANT — AgentCore is Infrastructure, Not an Agent: Amazon Bedrock AgentCore is the managed runtime layer that makes agents production-ready. It does NOT replace Bedrock Agents (the reasoning engine) or Step Functions (workflow orchestration). Exam questions may describe a scenario where an agent 'needs persistent memory across user sessions' or 'needs to authenticate to external OAuth APIs' — the answer is AgentCore capabilities, not building custom DynamoDB/Secrets Manager solutions.
IMPORTANT — Step Functions Optimized SDK Integrations for Cost: Step Functions can call 200+ AWS services directly via optimized SDK integrations without invoking Lambda. This eliminates Lambda cold starts, reduces cost, and simplifies architecture. Exam questions about 'reducing cost and complexity in a Step Functions workflow that calls DynamoDB and SNS' → remove Lambda intermediaries and use direct SDK integrations.
NICE-TO-KNOW — Standard vs. Express Workflow Selection: Standard = exactly-once execution semantics, up to 1 year, full execution history, priced per state transition — use for business-critical workflows requiring idempotency. Express = at-least-once, up to 5 minutes, high-throughput (millions/second), priced per duration — use for IoT event processing, streaming data transformation, and high-volume microservice orchestration.
The #1 exam trap is assuming that AWS Step Functions workflow orchestration automatically provides responsible AI protections (content safety, bias prevention, ethical AI guardrails) when used with AI workloads. It does NOT. Step Functions is a deterministic workflow engine with no AI safety capabilities. Responsible AI features come exclusively from Amazon Bedrock Guardrails, which must be explicitly configured and attached to Bedrock Agents. Similarly, candidates confuse 'model evaluation tools' (Amazon Bedrock Model Evaluation) with 'runtime protection' (Bedrock Guardrails) — evaluation is offline assessment, Guardrails is live runtime enforcement.
CertAI Tutor · SAA-C03, AIF-C01, SAP-C02, DEA-C01, DOP-C02, DVA-C02, CLF-C02 · 2026-03-07
Services
Comparisons
Guides & Patterns