A 311 resident-services assistant must call several municipal backend APIs — pothole reporting and utility billing lookup among them — as part of answering a citizen's question. What should the team configure to support this?
Select an answer to reveal the explanation.
Short Explanation
Answering a real citizen question sometimes means the assistant has to go do something — check a bill, log a pothole — not just talk about it. A Bedrock agent with action groups gives it defined, callable actions for each backend system it needs to reach. That's how it goes from chatting to actually getting things done.
Full Explanation
A Bedrock agent configured with action groups defines discrete, callable actions mapped to specific backend APIs, letting the model decide during a conversation which action to invoke and with what parameters, which is exactly the task-integration pattern needed when an assistant must reach multiple municipal systems like pothole reporting and utility billing. A single Lambda function embedding every API call hardcodes the integration logic outside the model's reasoning loop, losing the agent's ability to dynamically choose which action fits a given question and forcing brittle custom routing logic instead. A fine-tuned FM that never calls external systems can only work from what it learned during training, so it cannot look up a citizen's actual current utility bill or file a live pothole report — no amount of fine-tuning substitutes for a real-time system call. A knowledge base of API documentation gives the model something to read about the APIs, not a way to invoke them; it supports retrieval-based question answering, not taking action against live backend systems. Scope note: each action group needs its own permission scope so the assistant only reaches the systems a given citizen interaction actually requires. Operational check: test each action group independently with sample inputs before wiring them into the full conversational flow.