Getting Agents to Stop Assuming: What a First AWS Agent Workflow Reveals About Constraint Design

Agent workflows often falter not due to technical glitches, but because agents confidently produce incorrect results by filling in missing information with plausible guesses. A novice AWS Bedrock agent tasked with gathering critical details for a bug ticket - description, reproduction steps, and environment specifics - inadvertently created tickets even when one key piece of information was absent.

The system's evaluation correctness score of 0.83, while seemingly acceptable, masks an alarming 17% failure rate stemming from the agent's unwarranted assumption of sufficient context.

This issue isn't a prompt engineering problem but rather a deeper architecture flaw. The agent requires concrete validation gates to halt execution when constraints aren't met, not merely polite prompts encouraging cautious behavior. As LLMs are trained to be helpful, they generate responses based on partial information in agentic systems, which leads to suboptimal outcomes.

In the bug ticket case, the agent had three options: create the ticket with incomplete data (which occurred), request the missing field (correct behavior), or refuse and escalate to a human (also correct, depending on policy). The agent opted for the first option, as the model understood the user's intent but lacked a hard boundary enforced by the prompt.

The remedy lies not in refining prompts but in moving validation gates entirely outside the model's decision-making process.

In AWS Bedrock's AgentCore, this is achieved by dividing the workflow into two stages with a validation gate in between. Stage 1, Information Gathering, collects user input and stores it in session state without creating tickets. Validation Gate 2 then checks if all required fields are present, returning either a complete status to proceed to ticket creation or an incomplete status prompting the agent to request missing information.

If incomplete, the workflow returns to Stage 1 with a prompt about the missing fields. This design eliminates the model's guesswork and ensures it can only proceed with valid data.

Request types are classified before invoking any action groups. If the classification identifies a request as requiring human escalation, the agent triggers a handoff without attempting to generate a response. This refusal logic occurs before the agent engages in any reasoning, preventing it from generating policy-violating help.

Observability measures are crucial to catch silent assumptions that lead to incorrect outcomes. Session state snapshots log the full context before and after action group execution, allowing replay to identify missing information. Validation gate metrics track how often incomplete data triggers the gate and which fields are most frequently missing, guiding improvements to data collection prompts.

Additionally, action groups should log when they receive partial data, even if validation passes, providing insights into potential issues.

Comparing prompt-based validation to gate-based validation reveals distinct advantages. The gate-based approach eliminates the ambiguity where a model ignores ambiguous instructions, making failure modes observable and testable. While the prompt-based method requires extensive LLM trace analysis to understand why it proceeded despite missing information, the gate-based approach ensures that only valid data proceeds, enhancing reliability and consistency in agent workflows.