Amazon Bedrock Agents, Flows and Orchestration

Everything in this course so far has been about one model call: write a prompt, get a completion, evaluate it. Production AI is rarely one call. It is a sequence, look something up, check a condition, call an API, ask the user a follow-up question, try again, and the exam has a dedicated vocabulary for who owns that sequence: you (your application code), the model (an agent that chooses actions at runtime), a graph you drew (Amazon Bedrock Flows), or a state machine (AWS Step Functions). Lesson 11 is about that ownership decision, and about the AWS services that implement each answer.

By the end of this lesson you will be able to:

• name the four build-time components every agent needs and the optional ones AWS lists alongside them;
• walk the runtime loop, pre-processing, orchestration, post-processing, and say which of the four base prompt templates is editable at each phase;
• choose between an OpenAPI schema and function details, and between a Lambda executor and RETURN_CONTROL;
• state the InvokeAgent contract: required parameters, the 2,048-character inputText ceiling, sessionState scopes and what happens to inputText on a return-control resubmission;
• describe agent memory (SESSION_SUMMARY, 1 to 365 days) and the session-management quotas;
• configure multi-agent collaboration (≤ 10 collaborator aliases, two modes) and explain why custom orchestration is incompatible with it;
• list the 16 Flows node types, the two connection kinds and the execution limits (1 h sync, 5 min/node and 24 h async preview);
• defend the comparative verdict: agent vs. simple prompt vs. workflow vs. code.

---

1. Three names, three services: Agents Classic, AgentCore and Flows

1.1 The renames that decide the exam

Two renames carry more marks than any other fact in this lesson:

1. "Amazon Bedrock Agents" / "Agents for Amazon Bedrock" → Amazon Bedrock Agents Classic. AWS placed it under Services moving to Maintenance in its 30 June 2026 Service Availability Update: closed to new customers from 30 July 2026, no new features, and a foundation-model catalog frozen at 30 July 2026. Existing customers are unaffected, and Amazon Bedrock models, Knowledge Bases and Guardrails are explicitly not affected. There are no exceptions to the new-customer cutoff.
2. "Prompt Flows" → Amazon Bedrock Flows, generally available on 22 November 2024, adding per-step execution visibility and Guardrails support on prompt and knowledge-base nodes. The old name survives only in some certification in-scope lists.

The documented migration target for Agents Classic is Amazon Bedrock AgentCore: a set of six components (Runtime, Gateway, Identity, Memory, Observability and Harness) that previewed in July 2025, reached GA in nine regions, and kept shipping through 2026 (Managed Knowledge Base GA in June 2026, Agent Registry GA in August 2026).

📚 Did you know? AgentCore is not a renamed agent; it is a decomposition. Its six components map onto pieces that used to live inside a single agent: Runtime (the invocation loop), Gateway (tool/API exposure), Identity, Memory, Observability (traces and telemetry) and Harness (packaging). That is why AWS's migration guidance talks about moving capabilities, not about a one-click upgrade of an existing agent ID.

1.2 What the exam officially asks about agents

The AIF-C01 exam guide is the authority for scope, and its agentic content sits in two places:

Two scope changes were published for this exam version: AgentCore, Kiro, Strands Agents, Amazon Q, SageMaker JumpStart and AWS Transform were added, and Amazon MemoryDB was removed. Amazon A2I, once listed in exam guide v1.4 (2024), is no longer in the current scope list.

---

2. Anatomy of an agent

2.1 The build-time minimum

AWS's own wording for what an agent is made of is precise and worth memorizing as a sentence: a foundation model, instructions, optionally base or advanced prompt templates, and at least one of: action groups or knowledge bases. Memory, Guardrails, code interpretation and multi-agent collaboration are all optional add-ons.

Two rows deserve their own emphasis. First, alias: InvokeAgent requires agentAliasId, never a bare agent ID: a draft agent you have never prepared and aliased cannot be called. Second, function details vs. OpenAPI: they are alternatives, not layers. An action group uses exactly one of the two schemas, and the executor union (Lambda ARN | RETURN_CONTROL) applies to both.

2.2 Example 1: building a travel agent (build time)

1. Create the agent and give it instructions: "You are a travel agent. Book the cheapest compliant flight. Never invent prices; always call FlightsAPI."
2. Choose a foundation model from the catalog available to Agents Classic in your account.
3. Add an action group FlightsAPI with an OpenAPI schema describing searchFlights and bookFlight.
4. Set the executor to a Lambda ARN (the Lambda validates IAM, calls the airline API and returns JSON).
5. Optionally attach a knowledge base of corporate travel policies, a guardrail that blocks card numbers, and memory with storageDays = 90.
6. PrepareAgent → note the version → create an alias (for example T1).
7. Hand the application agentId + agentAliasId and call InvokeAgent.

Nothing above is autonomous yet: the autonomy appears only at runtime, in the loop the model drives.

---

3. Runtime: the orchestration loop

3.1 The three phases, in order

Every InvokeAgent call passes through pre-processing, then an orchestration loop that repeats until an answer exists or the user is re-prompted, then post-processing (disabled by default). The loop itself has a fixed internal rhythm: the model produces a rationale, predicts an action group call or a knowledge-base query, the parameters go to Lambda or back to your application via return control, the result comes back as an observation, the observation is appended to the base prompt, and the loop repeats.

Three consequences fall out of that diagram and each one has been tested:

• Cost scales with iterations, not with requests. Every loop turn is another foundation-model invocation against the augmented prompt; which is why an agent is more expensive than a single prompt for the same question.
• Return control is a second InvokeAgent call, not a field you can fill in later on the same request. Your application executes the tool and resubmits.
• Observations, not chat history, drive tool results. The result of an action is appended to the base prompt so the model can reason over it in the next iteration.

3.2 The four editable base templates

AWS documents four base templates as overridable. Advanced prompts let you replace the text entirely; promptCreationMode and parserMode in the trace tell you whether a value came from DEFAULT or OVERRIDDEN; which is your audit evidence that an override is live.

3.3 Trace types: seven objects that answer seven questions

With enableTrace = true the runtime streams trace events alongside chunk events. There are 7 trace object types:

3.4 Example 2: a booking request, trace by trace

1. The application calls InvokeAgent with agentId, agentAliasId, sessionId = S1, inputText = "Book the cheapest flight to Denver next Friday" (≤ 2,048 characters) and enableTrace = true.
2. Pre-processing validates the request → PreProcessingTrace { isValid: true, rationale }.
3. Orchestration, iteration 1: rationale → predict FlightsAPI.searchFlights → InvocationInput { apiPath, parameters } → Lambda executes → Observation containing the JSON list of flights.
4. Iteration 2: a required parameter (travelerId) is missing → the returned Observation reprompts the user: "Which traveler should I book for?" (AWS documents this behaviour explicitly).
5. The user replies in the same sessionId → the action executes → new Observation.
6. Post-processing (if enabled) formats the answer → the application receives chunk.bytes such as "Booked UA 512…", plus an attribution object if a knowledge base was used. Traces stream alongside the chunks.

📚 Did you know? The OrchestrationTrace is where you can prove what your agent actually did: InvocationInput records the action group, HTTP verb, apiPath or function name, the resolved parameters and the executionType, and Observation records what came back. When a stakeholder asks "why did the agent call the payment API?", the trace, not CloudTrail, is the first place to look, because CloudTrail sees the Lambda invocation but not the model's rationale for choosing it.

3.5 Reading a trace: symptom → trace object → fix

---

4. Action groups, return of control and raw tool use

4.1 Two schema styles, two executors

An action group is defined by exactly one schema style and exactly one executor:

Two limits worth quoting: an action group's description runs 1 to 200 characters, and an executor is a union type: a Lambda ARN or customControl: RETURN_CONTROL, never both.

4.2 Example 3: return of control, the official weather scenario

Use return control when your application must execute the call: a private payment rail, an on-premises system, a credential Bedrock may not hold.

1. Create action group WeatherAPIs with function getWeather(location, date) and executor customControl = RETURN_CONTROL.
2. The user says "Plan a day in Seattle this weekend." → orchestration predicts getWeather.
3. The response carries returnControl.invocationInputs with invocationId = abc-123 and parameters {location: seattle, date: 2024-09-15}.
4. Your application calls the real weather API → the answer is rain.
5. You call InvokeAgent again with the same sessionId, supplying sessionState.returnControlInvocationResults = [{ functionResult: { actionGroup, function, responseBody: { TEXT: { body: "{\"cond\":\"rain\"}" } } } }] with the matching invocationId, and inputText is ignored because returnControlInvocationResults is present.
6. Orchestration resumes: "Carry an umbrella; here is an indoor plan…". Variants: responseState = REPROMPT feeds a failed tool result back for a retry; responseState = FAILURE fails the run with a dependency error; confirmationState = CONFIRM | DENY implements a pre-action user confirmation gate.

4.3 Example 4: slot filling with function details

1. The function is BookHotel(HotelName/required, CheckinDate/required, NumberOfNights/optional, Email/required, AllowMarketingEmails/required).
2. The user says "Book Hotel X for tomorrow" → the agent fills HotelName and CheckinDate.
3. Two required parameters are unknown → the agent asks the user: "What is your email? May we send promotions?"
4. The user answers across two turns (turn-scoped values live in promptSessionAttributes) → all required parameters are present → the action executes → a confirmation is returned.

Slot elicitation is the canonical agent-versus-prompt discriminator. A plain prompt cannot wait for a missing required parameter, call an API, and then resume: an agent does exactly that, driven by the observation that a parameter is missing.

4.4 Raw tool use without an agent

Function calling also exists without any agent, on the Converse API: you pass toolConfig.tools[].toolSpec { name, description, inputSchema.json } (plus toolChoice), the model returns JSON with stopReason = toolUse, your application executes the function, and you send a toolResult back. The model never executes the function; that boundary is the whole point, and it is the most reliable way to distinguish a tool question from an agent question.

---

5. InvokeAgent, session state and memory

5.1 The request contract

The response streams chunk + trace + attributions + returnControl, and the response headers include x-amz-bedrock-agent-session-id and, when memory is used, x-amz-bedrock-agent-memory-id.

5.2 sessionState: five scopes, one override rule

5.3 Example 5: memory across sessions

1. In session S1 the user says "I'm allergic to shellfish"; the application calls InvokeAgent with endSession = true.
2. S1 folds into memoryId = M-user-42 and asynchronous summarization writes a summary using the (editable) summarization template.
3. Later, InvokeAgent(sessionId = S2, memoryId = M-user-42, inputText = "Suggest a starter") loads the stored summaries → the answer excludes shellfish; the response header x-amz-bedrock-agent-memory-id confirms memory was used.
4. storageDays = 90 means older summaries are purged after 90 days; disabling memory returns the default single-session context.

Memory facts in one place: the only memory type is SESSION_SUMMARY, retention is 1 to 365 days (storageDays), the fold triggers are endSession = true on the same sessionId or the idleSessionTimeout expiry, summarization runs asynchronously with an editable template, and you read summaries with GetAgentMemory (or the console Memory tab).

5.4 Session-management quotas (separate from memory)

📚 Did you know? The AWS CLI cannot stream InvokeAgent. Streaming chunk and trace events requires an SDK with event-stream handling (for example boto3/Java/Node with the response stream reader). This is a real operational gotcha, and a favourite distractor: "enable streaming with aws bedrock-agent-runtime invoke-agent --no-cli-pager" is not a thing. Use enableTrace = true plus an SDK stream reader, and read the session back from the x-amz-bedrock-agent-session-id response header.

---

6. Multi-agent collaboration

6.1 One supervisor, at most ten collaborators, two modes

6.2 Example 6: a triage supervisor

1. Deploy collaborators ReturnsAgent and BillingAgent and create an alias for each.
2. Promote TriageAgent to supervisor, choose mode Supervisor with routing, and attach both aliases (never more than 10).
3. The customer asks "Why was I charged twice in March?" → RoutingClassifierTrace records the decision → the supervisor invokes BillingAgent with sessionState.conversationHistory.
4. BillingAgent's action group calls Lambda → the final answer is synthesized and streamed back.
5. Had the requirement been "investigate returns and billing, then summarize", the correct mode would be plain Supervisor, which decomposes the request and coordinates collaborator responses instead of picking one.

---

7. Amazon Bedrock Flows (formerly Prompt Flows)

7.1 What a Flow is

A Flow is a visual, declarative graph of nodes you draw in the Flow builder and invoke through CreateFlow → PrepareFlow → InvokeFlow (with versions and aliases, exactly like agents). The model does not choose the steps: the graph does. Flows GA'd on 22 November 2024 as "Amazon Bedrock Flows, previously known as Prompt Flows", adding per-step execution visibility plus Guardrails on prompt and knowledge-base nodes.

7.2 The 16 node types

Connections come in two kinds: data connections (solid) that always carry values, and conditional connections (dotted) that fire only when a Condition node evaluates true. Guardrails can be attached to prompt and knowledge-base nodes; which is how you get policy enforcement inside a graph rather than around it.

7.3 Example 7: an invite pipeline with a branch

1. CreateFlow with a name and an IAM role; wire the nodes: Input → Prompt (draft the email body) → KnowledgeBase (attendee addresses) → Condition (attendees > 50?).
2. Yes branch → Lambda bulk-send node; No branch → Lambda single-send node; both converge on Output. Data connections are solid; the two condition branches are dotted.
3. PrepareFlow → test inside the Flow builder, inspecting per-node input/output.
4. Create a version and an alias; the application calls InvokeFlow (synchronous, 1-hour ceiling) or starts an async flow execution (preview: ≤ 5 minutes per node, ≤ 24 hours per flow, snapshot via GetExecutionFlowSnapshot, errors such as ExecutionTimedOut).
5. Read FlowTraceEvents for per-step visibility; swap the Prompt node for an Agent node when reasoning is required: the multi-turn conversation API is in preview (INPUT_REQUIRED → your reply → SUCCESS).

7.4 What a Flow costs, and what it does not do

Flows are billed per node transition, on top of the foundation-model, Lambda and knowledge-base usage inside the nodes. AWS's own pricing walkthrough counts a run as 2 + 10×2 + 3 = 25 transitions; a $0.035 per 1,000 transitions rate was announced for 1 February 2025, and the current rate should be confirmed on the Bedrock pricing page before you quote it. Two limits to memorize: InvokeFlow synchronous executions time out at 1 hour, and long-running work belongs to async flow executions (preview: 5 minutes per node, 24 hours total) or to Step Functions.

Worked example: counting node transitions. AWS's pricing walkthrough charges a run as 2 + 10×2 + 3 = 25 transitions: 2 to enter and branch, a loop body of 10 iterations × 2 nodes, and 3 more to converge and exit. The lesson is that transitions, not nodes, are the billable unit:

📚 Did you know? The pricing example's arithmetic, 2 + 10×2 + 3 = 25 node transitions, is a reminder that loops are not free in a graph: a node revisited ten times is billed ten times. That is the opposite of an agent, where iterations are billed as foundation-model tokens, and the opposite of Step Functions, where transitions are billed as state-machine transitions plus the services you call. Three orchestrators, three different cost unit.

---

8. Choosing: prompt, agent, Flows or Step Functions

8.1 The decision tree

8.2 The decision matrix

8.3 Example 8: three requirements, three answers

1. Deterministic extract → condition → write, with A/B rollback → Amazon Bedrock Flows: draw the graph, publish version v2, alias points at v1, roll back by moving the alias. A Flow version alias is exactly the A/B mechanism an agent does not have.
2. Open-ended multi-turn task where the FM decides what to call → an agent (AgentCore for a new build in October 2026). Slot elicitation, re-prompts and observations are the giveaways.
3. "Wait 3 days for approval, retry 5 times, then notify" → AWS Step Functions, whose optimized Bedrock integration (announced November 2023) includes InvokeModel, CreateModelCustomizationJob .sync and a documented "Perform prompt-chaining with Bedrock" sample. Neither Flows (1-hour sync ceiling) nor an agent (no native long timers) fits.

---

9. Comparative verdict

9.1 Human review today

Amazon A2I is in maintenance: "no longer open to new customers… we do not plan to introduce new features", it was part of the 30 June 2026 maintenance batch, and it has been removed from the current AIF-C01 scope list (it was present in exam guide v1.4, 2024). For workflows, the documented human-intervention pattern is Step Functions with its optimized Bedrock integration (2023). AWS documents no Bedrock-agent-native A2I hook, so an option describing "attach A2I to a Bedrock agent as a human review step" is testing whether you know the service left the exam scope.

---

10. Exam traps and the numbers worth memorizing

Flags on facts this lesson deliberately did not assert as verified: the current per-transition flow price; the exact GA date of multi-agent collaboration (aggregators show both 3 Dec 2024 and 10 Mar 2025 items); the current supported-model list for multi-agent; the executionId field name used to resume a multi-turn flow (the INPUT_REQUIRED / SUCCESS states are documented, the field name was not located); and the preview-vs-GA status of the InlineCode node.

10.1 2025 to 2026 Updates

Everything in this subsection was read on docs.aws.amazon.com, an AWS What's New post, an AWS News Blog post or the AIF-C01 exam guide itself: nothing here comes from a third-party tracker. Two groups of change matter for this lesson: what shipped inside Amazon Bedrock AgentCore and Amazon Bedrock Flows, and what AWS did to the exam guide and to the services that sit around an agent.

AWS states that exam-guide updates reach the live exam about one month after publication, so v1.1's new objectives have been fair game since roughly late May 2026. Also inside this window: standalone Bedrock Studio was folded into SageMaker Unified Studio (workspaces closed 28 Feb 2025, documentation moved 25 Mar 2025), so the Flow builder and the prompt tools are now found there rather than in a separate studio.

📚 Did you know? AgentCore's SDK passed 2 million downloads in its first five months after GA, and AgentCore Evaluations ships with 13 evaluators, the adoption figure AWS itself published to show where new agent work is expected to land. It also explains the shape of the exam questions: scope items ask about capabilities (Runtime, Gateway, Identity, Memory, Observability, Harness, now joined by Policy and Evaluations) instead of about one "agent" object, because AWS decomposed a service into components rather than renaming it.

---

11. Real-World Case Studies

AWS publishes few customer stories about orchestration as such, an internal loop is rarely photogenic, so these four are chosen because each one names its services, its numbers and its source, and each one maps onto a different branch of the decision tree in §8. Read every percentage as a customer- or AWS-claimed, unaudited figure, and read "up to" as a ceiling.

11.1 The four stories

Epilot: a queue, not an agent, owns the sequence (energy software, Cologne, 2026). Long email chains across 170+ utility customers were draining staff time. The published pipeline is an API → Amazon SQS → AWS Lambda → Amazon Bedrock (Claude Sonnet), with the model chosen using Amazon Bedrock Evaluations (human ratings across prompt versions) before production, and a later agent that writes records with humans verifying. Reported outcome: −87% email handling time, 55,000 summaries per month at a negligible failure rate, 80% of users saying it simplifies their work, an MVP in 2 months, and processed data kept in an EU Region. This is §8's "your code owns every step" branch in production, plus two habits this lesson repeats: evaluate the model before you ship, and keep a human at the end of an automated write. Source: AWS case study, solutions/case-studies/epilot-genai-case-study (2026).

Prime Focus Technologies: agents where the steps differ per asset (media, 2025). Localization (subtitling, translation, transcripts) across 14 million+ assets on CLEAR: Disney Star, CBS, Lionsgate: is labour-heavy, and live cricket tagging needed low latency. The published architecture runs Amazon Bedrock + AWS Lambda agents that automate and re-review those workflows. Reported outcome: localization cost −20 to 30%, accuracy +20 to 30%, turnaround −30 to 40%. The caution inside the source is the examinable part: the first attempt used external LLM APIs, whose latency was too high for live tagging, and latency "dropped dramatically" once the calls ran on AWS. It is §8's "the model chooses what to do next" branch, with model placement as a hard requirement. Source: AWS case study, solutions/case-studies/prime-focus-case-study (2025).

Alnylam Pharmaceuticals, citations as the compliance feature (biotech, 2025). Complaint triage took 3 to 4 days and internal information search 15+ minutes. From June 2023 the team built an intake/triage prototype on Amazon Bedrock + Amazon S3 with RAG in about 3 months under GxP constraints, plus AskALNY, a Slack assistant on Amazon Q Business that returns source links. Reported outcome: triage 3 days → hours, search 15 min → 30 s, 2,000 employees + 1,000 contractors served, 250+ use cases identified. The mechanism is a knowledge base underneath whatever owns the loop, and it is why §3.3 treats KB attributions as first-class: in a regulated answer, the citation is the audit trail. Source: AWS case study, solutions/case-studies/alnylam-case-study (2025).

Sun Finance: a state machine, and a rejected LLM-only prototype (fintech lending, 9 countries, 2026). 60% of microloan applications needed manual review, taking 10 minutes to 20 hours each. The shipped pipeline, built with the AWS Generative AI Innovation Center, is Amazon Textract OCR → Amazon Rekognition fallback and face masking → Claude Sonnet 4 structuring → validation rules → Titan Multimodal Embeddings in S3 Vectors for fraud similarity, coordinated with AWS Step Functions and AWS Lambda. Reported outcome: accuracy 79.73% → 90.80%, cost per document −91%, processing 20 hours → under 5 seconds, fraud detection 81%. It is §8's state-machine branch and §4's lesson read backwards: deterministic services extract, the model structures, and every step stays auditable. Source: AWS Machine Learning Blog, blogs/machine-learning/sun-finance-automates-id-extraction-and-fraud-detection-with-generative-ai-on-aws (2026).

11.2 Services, numbers and sources at a glance

11.3 What each case proves against this lesson

📚 Did you know? Sun Finance's rejected prototype is the cleanest OCR-versus-reasoning lesson in the course: attempt 1, Claude Sonnet 4 alone, reached only 61.8% overall and 43% on ID numbers and was discarded, because the model's privacy protections block direct PII extraction. Attempt 2 (Textract + Claude) hit 85%, and the shipped pipeline with validation rules reached 90.80% at −91% cost per document. The takeaway matches §4 exactly: let a deterministic service do extraction, let the model do structure, and let a state machine keep the receipt.

---

Practice Questions

---