Our agent sent 847 emails because it couldn't tell success from failure

Our agent was supposed to send a simple welcome email to new users. Instead, it sent 847 emails to the same person because it couldn't tell the difference between "task failed" and "task completed but confirmation pending."

The problem wasn't the agent. It was us treating real-world actions like chat responses.

When an agent writes a file, sends an email, or calls an API, the world changes. But most agent setups treat these actions like they're just generating text. No confirmation. No verification. No understanding that the action actually happened.

The pattern that fixes this: Separate action execution from action confirmation. Your agent decides what to do. Your system does it and reports back what actually happened.

Here's the wrapper pattern we built:

def execute_with_confirmation(agent_action):
  # Agent decides what to do
  action_plan = agent_action.get_plan()
  
  # System executes and captures reality
  try:
    result = perform_action(action_plan)
    confirmation = verify_action_completed(result)
    return {
      "status": "completed",
      "evidence": confirmation,
      "side_effects": capture_side_effects(result)
    }
  except Exception as e:
    return {
      "status": "failed", 
      "reason": str(e),
      "retry_safe": is_retry_safe(e)
    }
  
  # Agent learns what actually happened
  agent_action.update_context(result)

The key insight: agents are terrible at knowing what they actually accomplished. They'll confidently report success while your database is on fire, or retry a task that already worked perfectly.

We learned this the hard way when our support agent started approving refunds that had already been processed. It would see "processing" in the API response and assume failure, then retry until it hit our daily limit.

Now every real-world action goes through confirmation:

• Email sends: Check delivery status, not just API acceptance
• File writes: Verify file exists and has expected content
• API calls: Parse the actual response, don't trust HTTP 200
• Database updates: Query back the changed records

The pattern scales to any action that changes state. The agent proposes. The system executes and verifies. The agent learns from reality, not assumptions.

This isn't about adding delays or complexity. It's about building systems that know the difference between "I tried to do something" and "something actually happened."

Your agent will make better decisions when it understands the actual consequences of its actions. But more importantly, you'll sleep better knowing it can't accidentally send 847 emails because it got confused about what "pending" means.