AI agents take actions. The actions have consequences. The actions might delete a record, send an email, charge a credit card, deploy to production, or shut down a service. The naive approach lets the agent take any action whenever it decides. The action may be wrong. The damage is irreversible.
Facio's action execution discipline gives AI agents structured mechanisms to carry out side-effecting operations safely. The agent declares what it intends to do. The system verifies the action is allowed. The system executes the action through approved channels. The system records what happened. The system enables reversal when possible.
Here's how the discipline works, what action execution it includes, and why action execution discipline is what makes AI agents trustworthy in production where actions have real-world consequences.
The Action Execution Reality
Production AI agents face an action execution problem:
Problem 1: Unintended destruction. The agent deletes a record it shouldn't. The customer sees the lost data. The trust is broken.
Problem 2: Cascading operations. The agent calls tool A. Tool A triggers tool B. Tool B triggers tool C. The cascade damages systems the agent didn't know it was touching.
Problem 3: Idempotency violations. The agent retries a tool call. The tool isn't idempotent. The action happens twice. The customer is double-charged.
Problem 4: No audit trail. The agent takes an action. The action isn't recorded. The team can't reproduce or explain what happened.
Problem 5: No rollback mechanism. The agent takes an irreversible action. The action is wrong. There's no way to undo. The damage is permanent.
Problem 6: Scope creep. The agent takes an action. The action has broader permissions than needed. The blast radius is bigger than the work required.
The naive approach — let the agent take any action — fails every test. The team ends up with a system where actions are the highest-stakes risk.
The Action Execution Discipline
Facio's action execution discipline has five pillars. Each addresses a different aspect of safe action execution.
Pillar 1: Action Declaration (Declare Before Doing)
Side-effecting actions are declared before execution:
# Action declaration
action_declaration = {
"action_request": {
"action_id": "act-abc-123",
"action_type": "delete_customer",
"tool_to_call": "postgres.delete_customer",
"arguments": {
"customer_id": "cust-456",
"reason": "GDPR_deletion_request",
},
"intended_effect": "customer_record_removed_from_database",
"expected_side_effects": [
"customer_data_permanently_deleted",
"audit_log_preserved",
"gdpr_response_record_created",
],
"reversible": False,
"blast_radius": "single_record",
"requester": "agent-customer-support-007",
"approval_status": "approved",
"approver": "user-jane-doe",
"timestamp": "2026-08-04T10:23:45Z",
},
"declaration_requirements": {
"every_side_effecting_action": "must_be_declared",
"declaration_fields": ["action_type", "intended_effect", "reversible", "blast_radius"],
"declaration_validation": "verify_declaration_is_well_formed",
"declaration_logging": "every_declaration_logged_before_execution",
},
"declaration_enforcement": {
"before_execution": "verify_declaration_exists",
"during_execution": "verify_execution_matches_declaration",
"after_execution": "verify_outcome_matches_declaration",
"missing_declaration": "block_action_AND_alert",
},
}
def declare_action(action_request):
validate_declaration(action_request)
record_declaration(action_request)
return {"status": "declared", "action_id": action_request["action_id"]}
The action declaration is upfront. The team can review before execution.
Pillar 2: Pre-Execution Validation (Check Before Acting)
Actions are validated before execution:
# Pre-execution validation
pre_execution_validation = {
"validation_checks": [
{
"check": "authorization_check",
"description": "Verify agent is authorized for this action",
"implementation": "check_agent_permissions_for_action_type",
"example": "delete_customer requires customer_data_delete permission",
},
{
"check": "scope_check",
"description": "Verify action is within agent's scope",
"implementation": "check_action_arguments_against_scope",
"example": "agent can delete customer in EU region only",
},
{
"check": "tenant_isolation_check",
"description": "Verify tenant context is correct",
"implementation": "verify_tenant_context_matches_data",
"example": "delete only allowed for tenant-acme-corp customers",
},
{
"check": "rate_limit_check",
"description": "Verify rate limit not exceeded",
"implementation": "count_actions_in_window",
"example": "max_10_deletes_per_hour_per_agent",
},
{
"check": "duplicate_check",
"description": "Verify action isn't duplicate",
"implementation": "check_action_request_idempotency_key",
"example": "same_delete_request_within_5_minutes_collapsed",
},
{
"check": "data_validation_check",
"description": "Verify arguments are valid",
"implementation": "validate_against_schema",
"example": "customer_id must exist in database",
},
{
"check": "approval_check",
"description": "Verify required approvals exist",
"implementation": "check_approval_record_for_action",
"example": "high_stakes_actions_require_human_approval",
},
],
"validation_failure_handling": {
"any_check_fails": "block_execution_AND_alert",
"validation_log": "all_checks_recorded_with_results",
"validation_audit": "audit_trail_for_compliance",
},
}
def validate_action(action_request):
validation_results = []
for check in pre_execution_validation["validation_checks"]:
result = run_check(check, action_request)
validation_results.append({"check": check["check"], "result": result})
if not result["passed"]:
log_validation_failure(action_request, check, result)
raise PreExecutionValidationError(action_request, check, result)
log_validation_success(action_request, validation_results)
return {"status": "validated", "checks": validation_results}
The pre-execution validation catches issues before they happen. The team has confidence in the action.
Pillar 3: Approved Execution Channels (Execute Through Safe Paths)
Actions execute through approved, constrained channels:
# Approved execution channels
approved_execution_channels = {
"channel_types": {
"tool_call_with_audit": {
"description": "Execute via tool with full audit logging",
"implementation": "all_tool_calls_routed_through_safe_executor",
"guarantee": "every_call_logged_AND_validated",
},
"queued_execution": {
"description": "Queue action for async execution",
"implementation": "high_stakes_actions_queued_for_review",
"use_case": "bulk_actions_requiring_review",
"guarantee": "actions_executed_in_controlled_manner",
},
"human_mediated_execution": {
"description": "Human verifies and executes",
"implementation": "human_uses_separate_terminal_with_full_context",
"use_case": "irreversible_high_stakes_actions",
"guarantee": "human_verifies_before_action",
},
"dry_run_execution": {
"description": "Run action without committing effects",
"implementation": "sandbox_execution_with_no_persistence",
"use_case": "verify_outcome_before_real_execution",
"guarantee": "no_side_effects_during_test",
},
},
"channel_selection_rules": {
"by_reversibility": {
"reversible": "tool_call_with_audit",
"irreversible_low_stakes": "queued_execution",
"irreversible_high_stakes": "human_mediated_execution",
},
"by_volume": {
"single_action": "tool_call_with_audit",
"batch_actions": "queued_execution",
"high_volume_critical": "queued_execution_with_human_review",
},
"by_uncertainty": {
"low_uncertainty": "tool_call_with_audit",
"medium_uncertainty": "queued_execution",
"high_uncertainty": "human_mediated_execution",
},
},
"channel_enforcement": {
"prevent_direct_execution": "agent_cannot_bypass_channels",
"channel_logging": "every_execution_through_channel_logged",
"channel_metrics": "metrics_per_channel_track_usage",
},
}
def execute_action_safely(action_request):
channel = select_execution_channel(action_request)
if channel["type"] == "tool_call_with_audit":
return execute_tool_with_audit(action_request)
elif channel["type"] == "queued_execution":
return queue_for_async_execution(action_request)
elif channel["type"] == "human_mediated_execution":
return escalate_to_human(action_request)
elif channel["type"] == "dry_run_execution":
return execute_dry_run(action_request)
The approved channels provide safety. The agent cannot bypass them.
Pillar 4: Idempotency and Duplicate Prevention (Don't Repeat)
Actions are idempotent and deduplicated:
# Idempotency and duplicate prevention
idempotency_management = {
"idempotency_principles": {
"idempotency_key": "every_action_has_unique_idempotency_key",
"duplicate_window": "actions_duplicate_within_window_collapsed",
"idempotent_tools": "actions_through_idempotent_tools",
"compensation_actions": "non_idempotent_actions_have_compensation",
},
"idempotency_implementation": {
"idempotency_key_generation": "generate_unique_key_per_action_request",
"idempotency_storage": "store_key_with_action_outcome",
"idempotency_lookup": "before_execution_check_key_exists",
"idempotency_window": "window_for_duplicate_detection (default_24_hours)",
},
"duplicate_handling": {
"same_action_within_window": "return_original_outcome_instead_of_re_executing",
"different_args_same_intent": "log_warning_AND_treat_as_duplicate",
"force_re_execution": "allow_only_with_explicit_force_flag",
},
"non_idempotent_handling": {
"compensation_pattern": "create_compensation_action_for_reversal",
"example_compensation": "if_send_email_then_also_store_outbox_id_for_resend",
"compensation_storage": "store_compensation_data_separately",
},
}
def execute_with_idempotency(action_request):
idempotency_key = generate_idempotency_key(action_request)
existing_outcome = idempotency_store.get(idempotency_key)
if existing_outcome and not action_request.get("force_re_execution"):
log_duplicate_action(action_request, existing_outcome)
return existing_outcome
outcome = execute_action(action_request)
idempotency_store.put(idempotency_key, outcome)
return outcome
The idempotency prevents the same action from happening twice. The customer is not double-charged.
Pillar 5: Post-Execution Verification and Audit Trail (Record What Happened)
After execution, the outcome is verified and recorded:
# Post-execution verification and audit trail
post_execution = {
"verification_checks": [
{
"check": "outcome_matches_intent",
"description": "Verify outcome matches declared intent",
"example": "intended customer_record_removed AND outcome customer_record_removed",
},
{
"check": "no_unexpected_side_effects",
"description": "Verify no additional side effects occurred",
"example": "intended_record_removed AND no_other_records_removed",
},
{
"check": "data_consistency",
"description": "Verify data remains consistent",
"example": "no_orphaned_references_remain",
},
{
"check": "compensating_actions_queued",
"description": "Verify compensating actions queued if needed",
"example": "compensation_outbox_id_stored_for_compensation_action",
},
],
"audit_trail": {
"action_attempted": "logged_with_full_context",
"validation_results": "logged_with_per_check_results",
"execution_outcome": "logged_with_actual_outcome",
"post_execution_verification": "logged_with_verification_results",
"compensation_actions": "logged_if_created",
"human_notifications": "logged_if_sent",
},
"audit_trail_storage": {
"tamper_evident": "audit_records_cannot_be_modified",
"immutable": "audit_records_immutable_once_written",
"searchable": "audit_records_searchable_by_action_id",
"exportable": "audit_records_exportable_for_compliance",
},
}
def verify_and_audit(action_request, execution_outcome):
verification_results = []
for check in post_execution["verification_checks"]:
result = run_post_check(check, action_request, execution_outcome)
verification_results.append({"check": check["check"], "result": result})
audit_record = {
"action_request": action_request,
"execution_outcome": execution_outcome,
"verification_results": verification_results,
"timestamp": time.now(),
}
audit_log.write(audit_record)
if any(not r["result"]["passed"] for r in verification_results):
alert_verification_failure(audit_record)
return {"status": "verified", "audit_id": audit_record["id"]}
The post-execution verification catches unexpected outcomes. The audit trail is the historical record.
The Action Execution Patterns
Several patterns emerge from disciplined action execution.
Pattern 1: Action Approval Workflow
Side-effecting actions go through approval workflow:
# Action approval workflow
approval_workflow = {
"approval_requirements": {
"by_action_type": {
"read_actions": "no_approval_needed",
"write_actions_low_stakes": "automatic_approval",
"write_actions_high_stakes": "human_approval_required",
"irreversible_actions": "explicit_human_approval",
"financial_actions": "dual_approval_required",
},
"by_actor": {
"user_initiated_action": "user_approval_at_request_time",
"agent_initiated_action": "approval_decision_by_agent_when_certain_AND_human_when_uncertain",
},
"by_context": {
"new_pattern": "approval_for_first_N_executions",
"established_pattern": "automatic_approval",
"exceptional_pattern": "human_approval_for_every_execution",
},
},
"approval_capture": {
"explicit_approval": "user_explicitly_approves",
"implicit_approval": "user_assumed_to_approve_based_on_context",
"delegated_approval": "user_delegates_to_agent_with_constraints",
},
"approval_storage": {
"approval_record": "logged_with_approver_AND_timestamp_AND_context",
"approval_revocable": "approval_can_be_revoked_before_execution",
"approval_auditable": "approvals_searchable_for_compliance",
},
}
def request_action_approval(action_request):
if not requires_approval(action_request):
return {"status": "auto_approved", "action_id": action_request["action_id"]}
approval_request = {
"action_request": action_request,
"approver": determine_approver(action_request),
"deadline": time.now() + calculate_approval_timeout(action_request),
"context": generate_approval_context(action_request),
}
approval_store.create(approval_request)
notify_approver(approval_request)
return {"status": "awaiting_approval", "approval_id": approval_request["id"]}
The approval workflow ensures high-stakes actions are reviewed. The team has oversight.
Pattern 2: Compensation Actions
Non-idempotent actions have compensation actions:
# Compensation actions
compensation_actions = {
"compensation_pattern": {
"description": "Pair action with compensation action",
"principle": "every_action_has_reversible_companion",
"implementation": "compensation_action_automatically_created",
},
"compensation_examples": {
"send_email": {
"action": "send_email",
"compensation": "mark_email_as_recallable_AND_store_smtp_message_id",
"execution_flow": "send_email_AND_store_compensation_metadata",
},
"create_charge": {
"action": "create_charge",
"compensation": "create_refund_with_original_charge_id",
"execution_flow": "create_charge_AND_stage_compensation_refund",
},
"delete_record": {
"action": "delete_record",
"compensation": "soft_delete_with_30_day_recovery_window",
"execution_flow": "delete_record_AND_archive_for_recovery",
},
"deploy_to_production": {
"action": "deploy_to_production",
"compensation": "previous_version_rollback_capability",
"execution_flow": "deploy_AND_keep_previous_version_warm",
},
},
"compensation_execution": {
"automatic_execution": "if_outcome_is_bad_then_auto_compensate",
"human_initiated_execution": "human_decides_to_compensate",
"scheduled_execution": "compensation_happens_at_scheduled_time",
},
}
def execute_with_compensation(action_request):
compensation = create_compensation(action_request)
outcome = execute_action(action_request)
compensation_store.put(compensation["id"], {"action_outcome": outcome, "compensation_data": compensation})
return {"outcome": outcome, "compensation_id": compensation["id"]}
def execute_compensation(compensation_id):
compensation = compensation_store.get(compensation_id)
return compensation["compensation_data"]["execute"](compensation["action_outcome"])
The compensation actions provide rollback capability. The damage is reversible.
Pattern 3: Blast Radius Limitation
Actions are limited to minimum blast radius:
# Blast radius limitation
blast_radius_limitation = {
"blast_radius_levels": {
"single_record": {
"description": "Action affects single record",
"approval": "automatic",
"examples": ["delete_one_customer", "update_one_record"],
},
"multi_record_limited": {
"description": "Action affects limited multi records",
"approval": "human_review",
"examples": ["delete_100_customers_in_EU", "update_records_matching_filter"],
},
"bulk_records": {
"description": "Action affects many records",
"approval": "human_approval_AND_dry_run",
"examples": ["delete_10000_customers", "bulk_update_all_records"],
},
"system_wide": {
"description": "Action affects entire system",
"approval": "explicit_human_approval_AND_safety_checks",
"examples": ["delete_all_records", "reset_database", "shutdown_service"],
},
},
"limitation_strategies": {
"default_to_minimum": "start_with_smallest_blast_radius_EXPAND_if_needed",
"explicit_expansion": "any_expansion_requires_explicit_approval",
"blast_radius_check": "verify_action_blast_radius_matches_intent",
"blast_radius_alert": "alert_if_blast_radius_unexpected",
},
"blast_radius_examples": {
"customer_deletion_request": "intended_single_record_but_agent_attempts_bulk",
"data_export_request": "intended_summary_but_agent_attempts_full_export",
"configuration_change": "intended_one_field_but_agent_attempts_full_reset",
},
}
def limit_blast_radius(action_request):
declared_radius = action_request["blast_radius"]
actual_radius = calculate_actual_blast_radius(action_request)
if exceeds_declared_radius(actual_radius, declared_radius):
raise BlastRadiusExceededError(action_request, declared_radius, actual_radius)
if actual_radius["level"] in ["bulk_records", "system_wide"]:
require_explicit_human_approval(action_request)
return {"status": "blast_radius_verified", "declared": declared_radius, "actual": actual_radius}
The blast radius limitation prevents scope creep. The damage is contained.
Pattern 4: Action Templates
Side-effecting actions are wrapped in templates:
# Action templates
action_templates = {
"template_structure": {
"template_id": "tmpl-customer-delete",
"template_name": "Delete Customer",
"template_validation": ["customer_exists", "deletion_allowed", "tenant_correct"],
"template_execution": "execute_with_audit_AND_compensation",
"template_compensation": "soft_delete_with_recovery_window",
"template_approval": "automatic_for_deletion_request",
"template_audit": "full_audit_trail_with_gdpr_metadata",
},
"template_benefits": {
"consistent_validation": "every_action_validated_same_way",
"consistent_audit": "every_action_audited_same_way",
"consistent_compensation": "every_action_compensable_same_way",
"consistent_approval": "every_action_approved_same_way",
},
"template_library": {
"delete_records": "tmpl-record-delete",
"update_records": "tmpl-record-update",
"send_messages": "tmpl-message-send",
"process_payments": "tmpl-payment-process",
"deploy_changes": "tmpl-deploy",
},
}
def execute_via_template(template_id, arguments, context):
template = template_library.get(template_id)
run_template_validation(template, arguments, context)
execute_via_approved_channel(template, arguments, context)
with_audit_trail(template, arguments, context)
setup_compensation(template, arguments, context)
return outcome
Templates provide consistent execution. The agent uses templates for every side-effecting action.
Pattern 5: Action Observability
Action execution is observable:
# Action observability
action_observability = {
"metrics": {
"actions_attempted_per_hour": "tracks_action_volume",
"actions_succeeded_per_hour": "tracks_success_rate",
"actions_failed_per_hour": "tracks_failure_rate",
"actions_by_type_distribution": "tracks_what_agents_are_doing",
"actions_by_blast_radius": "tracks_action_severity",
"compensation_actions_triggered": "tracks_how_often_rollback_needed",
"duplicate_actions_prevented": "tracks_idempotency_saves",
},
"alerts": [
{"level": "critical", "message": "High blast radius action attempted without approval"},
{"level": "warning", "message": "Action failure rate spike"},
{"level": "warning", "message": "Multiple compensation actions triggered"},
{"level": "info", "message": "New action type first observed"},
],
"dashboard": "https://internal-dashboard/facio/actions",
"audit_search": {
"searchable_by": ["action_id", "agent_id", "tenant_id", "timestamp", "outcome"],
"exportable_format": ["json", "csv"],
"retention_period_days": 365,
},
}
def emit_action_metrics(action_request, execution_outcome):
metrics = collect_all_action_metrics(action_request, execution_outcome)
publish_to_dashboard(metrics)
check_alert_thresholds(metrics)
update_audit_log(action_request, execution_outcome)
The observability surfaces action patterns. The team understands what the agent does.
The Action Execution Discipline Doesn't Do
Honest limitations:
- It can't prevent all bad actions. Sophisticated agent decisions bypass the discipline. The discipline reduces risk, not eliminates it.
- It adds latency. Validation, approval, and audit take time. The discipline trades speed for safety.
- It adds complexity. Multiple validation steps, approval workflows, compensation actions. The discipline requires infrastructure.
- It can be circumvented. Sophisticated attacks may find ways through. The discipline requires vigilant monitoring.
- It requires careful action typing. Distinguishing read from write actions is non-trivial. The discipline needs precise categorization.
The Action Execution Discipline as Operational Practice
Action execution discipline is operational practice:
Action review. The team reviews action patterns. They identify unusual patterns.
Approval audit. The team audits approval records. They verify proper approvals.
Compensation testing. The team tests compensation actions. They verify rollbacks work.
Blast radius review. The team reviews blast radius decisions. They ensure appropriate scoping.
The practice is what makes the discipline sustainable. Without it, the discipline drifts. With it, the discipline is robust.
The Compound Effect of Action Execution Discipline
Action execution discipline compounds:
- Lower risk actions. Bad actions are caught early. The risk is contained.
- Better customer trust. Customers know actions are controlled. The trust is high.
- Faster incident response. Compensation actions reverse damage. The response is fast.
- Higher team confidence. The team trusts the agent's actions. The deployment is wider.
- Better compliance. Audit trails are comprehensive. The compliance is met.
The undisciplined approach has the opposite trajectory. High-risk actions, broken trust, slow incident response, low team confidence, compliance gaps.
Bottom Line
AI agents take actions. The actions have consequences. Without action execution discipline, the consequences are uncontrolled. With action execution discipline, the consequences are managed.
Facio's action execution discipline provides action declaration, pre-execution validation, approved execution channels, idempotency and duplicate prevention, and post-execution verification and audit trail. The discipline makes AI agents safe.
The agent without action execution is a liability that takes risky actions. The agent with it takes controlled actions. The team trusts the controlled one. The customers trust the controlled one.
Because AI agents in production take actions. The question is whether the actions are safe or risky. The action execution discipline is what makes the answer safe.
See the action execution documentation for declaration schemas, validation patterns, and compensation action workflows.