Cheat Sheet: Agents and Orchestration

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

Options at a glance

The split that matters on the agent rows is who writes the loop. The harness takes a declaration and runs the cycle for you; the runtime takes an agent you wrote on any framework and runs the operational pieces around it. Both sit on the same memory, gateway, identity, and observability underneath.

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: the harness if a declared model, prompt, and tool list covers it, your own loop on the runtime if it does not.
• 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, expose each specialist agent as a tool and let a coordinating agent call them.
• If a Lambda or REST API backs the tool, attach it to the gateway as a target; if your own app must run the call, use an inline function tool so the harness hands execution back to you.
• If you are debugging why an agent did something, enable CloudWatch Transaction Search for the account and instrument the agent with ADOT; metrics arrive by default but spans do not.
• 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.
• An inline function tool does not mean no Lambda ever; it means the harness hands the call back to your application instead of the gateway invoking the target itself.
• A Lambda gateway target is always invoked with the gateway service role. If the tool must act as the signed-in user, that needs an OpenAPI or MCP-server target with on-behalf-of token exchange, or an inline function tool in your own code.
• 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. The AgentCore harness orchestrates the loop from a declaration; the runtime runs a loop you wrote yourself. Same capabilities underneath, different owner of the cycle.
5. A gateway target publishes an existing Lambda or REST API to the agent as an MCP tool; an inline function tool hands the call to your app instead.
6. Memory strategies decide what long-term memory gets extracted; a memory resource with none attached keeps the session and remembers nothing across them.
7. AgentCore emits metrics by default but spans only once you enable Transaction Search and instrument with ADOT.
8. Multi-agent on AgentCore is agent-as-tool: expose a specialist agent through the gateway and let another agent call it.
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.