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