Bedrock Agents

This is the Lambda function that does the real work behind one of the agent's tools (an action group). You never call it yourself — Bedrock calls it for you whenever the agent decides to take an action. Bedrock passes in a big dictionary called event describing which action and what parameters, and your job is to do the work and hand back a result in the exact shape Bedrock expects.

1. def lambda_handler(event, context): is the fixed entry point AWS Lambda always calls. event holds the request Bedrock sent; context is runtime info you can usually ignore here.
2. action = event["actionGroup"] and api_path = event["apiPath"] read which tool and which operation the agent chose (e.g. the path /pods/{name}/status).
3. params = {p["name"]: p["value"] for p in event.get("parameters", [])} is a dictionary comprehension: Bedrock sends parameters as a list of {name, value} pairs, and this line flips them into an easy-to-use {name: value} dictionary. .get(..., []) means "use an empty list if there are no parameters" so it never crashes.
4. The if api_path == "/pods/status": block is where your logic lives. Here it just returns a fake pod status; anything Bedrock didn't recognise falls through to the else and returns an "unknown action" error.
5. The big return {...} is the contract Bedrock requires. It must include messageVersion and a response object echoing back actionGroup/apiPath, an HTTP-style httpStatusCode, and the answer inside responseBody. Get this shape wrong and the agent can't read your result.

What the output means: Nothing prints to a screen — a Lambda hands its return value straight back to Bedrock. For a status request the agent receives {"phase": "CrashLoopBackOff", "restarts": 7} wrapped in that response envelope, and folds it into its reasoning.

Try this: Trace what happens if the agent asks for /pods/logs instead: api_path won't match "/pods/status", so result becomes the error dict. Add a second elif api_path == "/pods/logs": branch to handle it.

This script creates the agent itself from your laptop using boto3 (the AWS SDK for Python). Three things happen in order: make the agent, give it a tool (action group), then prepare it so it's ready to answer. This is set-up you run once, not every time a user chats.

1. agent = boto3.client("bedrock-agent", region_name="us-east-1") opens a connection to the Bedrock control plane — the API for building agents (a different client than the one that runs them, which you'll see in the next lab).
2. agent.create_agent(...) makes the agent. The key inputs: foundationModel picks the brain (a Claude model), instruction is the system prompt telling it how to behave ("diagnose read-only first, confirm before destructive actions"), and agentResourceRoleArn is the IAM role granting it permission to call your Lambdas.
3. agent_id = a["agent"]["agentId"] pulls the new agent's ID out of the response so the next call can attach a tool to it.
4. agent.create_agent_action_group(...) gives the agent a tool. actionGroupExecutor={"lambda": "..."} says "run this Lambda when the tool fires" (the Lambda from W5.1), and apiSchema points to an OpenAPI schema in S3 that describes the tool's inputs so the model knows how to call it. It attaches to agentVersion="DRAFT" — the editable working copy.
5. agent.prepare_agent(agentId=agent_id) compiles that DRAFT into a runnable version. Until you prepare it, the agent exists but can't be invoked.

What the output means: No visible output, but afterwards AWS holds a prepared agent with one Lambda-backed tool, ready to receive questions. The ARNs and account number 123456789012 here are placeholders — swap in your own.

Try this: Read the instruction string closely: that plain-English sentence is the single biggest lever on agent behaviour. Rewrite it to also say "always cite the runbook you used" and notice you've changed the agent without touching any tool code.

Now the agent is built, this is how you actually talk to it. You send one question and read the answer back. Crucially, the answer doesn't arrive all at once — it streams in pieces, so the loop at the bottom stitches those pieces together as they come.

1. rt = boto3.client("bedrock-agent-runtime", region_name="us-east-1") opens the runtime client — the one for using a live agent (note it's bedrock-agent-runtime, not the bedrock-agent build client from the last lab).
2. resp = rt.invoke_agent(...) sends the turn. agentId + agentAliasId pick which agent/version to talk to, and inputText is the user's actual question.
3. sessionId="session-1" is the memory key. Reuse the same sessionId on the next call and the agent remembers the earlier turns — that's the "session state" the agent keeps for you, so you don't have to resend the whole history.
4. for event in resp["completion"]: loops over the stream of events coming back. The reply is delivered as a sequence of chunks, not one string.
5. if "chunk" in event: keeps only the text chunks, and print(event["chunk"]["bytes"].decode(), end="") turns each chunk's raw bytes into text and prints it with no line break, so the sentence builds up smoothly on one line.

What the output means: You'll see the agent's answer appear piece by piece, e.g. a diagnosis of the checkout-api pod. Behind the scenes the agent may have called your Lambda and read the Knowledge Base first — but you only see the final streamed words.

Try this: Call invoke_agent a second time with the same sessionId and a follow-up like "and what caused it?" — the agent uses the earlier turn as context. Change the sessionId to a new value and it starts fresh with no memory.