Exam Room · Advanced GenAI

Cheat Sheet: Agents and Orchestration

August 03, 2026 · 11 min read

Generative AI Development · part of The Exam Room

Fast revision for choosing between model-decided and deterministic control flow, and the Bedrock services that back each one.

Options at a glance

Approach Control flow Use when
Plain Converse call You, in code Single prompt in, single answer out; no tools, no loop
Converse loop with tool use Model picks the tool, you run it Model needs live data or actions; you keep the orchestration
Structured output via a tool schema You constrain the shape You want typed JSON back, not prose
Single Bedrock Agent with one action group Model orchestrates One task, a handful of tools plus maybe a knowledge base
Bedrock Agent with knowledge base Model orchestrates, retrieves The agent needs grounding from your documents
Multi-agent (supervisor and collaborators) Supervisor routes to specialists Distinct sub-tasks each need their own tools and instructions
Bedrock Flows Deterministic, visual Fixed low-code pipeline of prompts, conditions, and steps
AWS Step Functions Deterministic, durable Long-running, retries, parallel branches, human-approval waits
Bedrock AgentCore You bring the agent, it runs it Production runtime: memory, gateway, identity, observability

Decision rules

  • If there is no loop and no external data, use a plain Converse call.
  • If the model needs to fetch data or take an action, use tool use in the Converse loop.
  • If you want typed JSON out, define a tool whose input schema is your target shape and read the tool-use arguments.
  • If one model should decide the order of steps at runtime, that is model-decided control flow, so reach for an agent.
  • If the sequence is fixed and you own it, that is deterministic control flow, so use Flows or Step Functions.
  • If the pipeline is low-code, Bedrock-native, and mostly prompt-plus-condition, use Bedrock Flows.
  • If you need durable state, retries, timeouts, parallel branches, or a pause for human approval, use Step Functions.
  • If the agent needs grounding from your own content, attach a knowledge base rather than stuffing documents into the prompt.
  • If work splits into distinct specialisms, use a supervisor agent over collaborator agents.
  • If a Lambda backs the tool, use an Action groupThe bundle of API operations a Bedrock agent is allowed to call, described by a schema so the model knows what each one does. with a Lambda; if your own app should run the call, use return of control.
  • If you are debugging why an agent did something, turn on the agent trace.
  • If you promote an agent to production, pin an alias to a version rather than calling DRAFT.
  • If you run a third-party framework agent in production, host it on AgentCore for the runtime, memory, and gateway.
  • If a tool must never exceed a permission, put that limit in the tool’s own IAM role, not the prompt.

Traps

  • An agent is not always the answer; a fixed workflow is cheaper, faster, and more predictable as Flows or Step Functions.
  • The model does not run your tools. It emits a tool-use request; your code executes and returns a toolResult.
  • Every toolResult must echo the toolUseId from the request, or the turn will not stitch together.
  • Structured output is not a separate API; it is tool use with a schema you then read from the arguments.
  • Return of control does not mean no Lambda ever; it means Bedrock hands the call back to your application instead of invoking Lambda itself.
  • An agent alias points at a version. Calling DRAFT in production gives you unpinned, shifting behaviour.
  • Tool permissions live in IAM. A prompt saying please do not delete is not a control; the tool’s role is.
  • Agent memory is not the context window. Short-term is the session; long-term persists across sessions and is a distinct feature.
  • Flows are Bedrock-native and low-code. Reaching outside Bedrock for retries, waits, and broad service calls is Step Functions territory.
  • AgentCore is framework-agnostic runtime, not a model or an agent builder. You bring the agent; it provides memory, gateway, identity, and observability.
  • Knowledge base grounding is retrieval, not fine-tuning. It changes what the agent can look up, not the model weights.
  • A supervisor does not merge into one giant prompt; it routes to collaborators that keep their own instructions and tools.

Say it in one line

  1. Model-decided control flow means an agent; deterministic control flow means Flows or Step Functions.
  2. Tool use: the model requests, your code executes, you send the toolResult back keyed by toolUseId.
  3. Structured output is a tool schema you read from, not prose you parse.
  4. A Bedrock Agent orchestrates with the model, backed by action groups and optionally a knowledge base.
  5. An action group is Lambda-backed or uses return of control to hand the call to your app.
  6. Agent versions are immutable snapshots; aliases point production traffic at a chosen version.
  7. The agent trace is your observability into each reasoning and tool step.
  8. Multi-agent uses a supervisor to route sub-tasks to collaborator agents.
  9. Bedrock Flows is a deterministic, visual, low-code, Bedrock-native pipeline.
  10. Step Functions is durable orchestration: retries, parallel, timeouts, human-approval waits, broad integration, model as one step.
  11. AgentCore is a production runtime that is framework-agnostic and adds memory, gateway and tools, identity, and observability.
  12. Short-term memory is the session; long-term memory persists across sessions.
  13. Least privilege lives on the tool’s IAM role; the model can never exceed the tool’s permissions.
  14. Pick the least powerful option that fits: plain call, then tool loop, then agent, and orchestrate the rest deterministically.

These posts are LLM-aided. Backbone, original writing, and structure by Craig. Research and editing by Craig + LLM. Proof-reading by Craig.