Limitations & fallbacks

Known constraints of agent capabilities and alternative strategies when automation is not feasible.

Limitations and fallbacks represent a critical design consideration in agentic systems: understanding what your agent cannot do and providing graceful alternatives when automation reaches its boundaries. While autonomous agents promise powerful automation, production systems must acknowledge technical constraints, edge cases, and scenarios where human intervention becomes necessary.

Why it matters

Realistic expectations

Users who understand an agent's limitations develop appropriate mental models of system capabilities. When you clearly communicate boundaries—whether through documentation, in-context messaging, or graceful failures—users calibrate their expectations and approach tasks with realistic assumptions about what automation can achieve.

Systems that overpromise and underdeliver erode trust quickly. A user who expects an agent to handle complex multi-application workflows will feel frustrated when it fails silently. Conversely, an agent that proactively identifies limitations ("I cannot process CAPTCHAs—please complete this manually") maintains credibility even when automation falls short.

Graceful degradation

Well-designed fallback strategies ensure task continuity when full automation proves impossible. Rather than complete failure, systems should degrade gracefully to partial automation, guided workflows, or human handoff. This approach preserves user progress and maintains productivity even when encountering capability boundaries.

Consider a document processing agent that encounters an unsupported file format. A brittle system simply errors out. A system with graceful degradation might fall back to extracting basic metadata, offering manual upload options, or routing to a human specialist—each preserving some value rather than complete failure.

User trust

Transparency about limitations builds long-term trust. Users develop confidence in systems that accurately report what they can and cannot do. This honesty creates psychological safety: users know the system will alert them when encountering boundaries rather than silently producing incorrect results.

Trust also emerges from consistent fallback experiences. When users repeatedly see the system handle edge cases gracefully—providing clear explanations and actionable alternatives—they develop confidence in the overall system reliability, even when individual tasks require manual intervention.

Concrete examples

CAPTCHA limitations

The constraint: Vision-based AI agents cannot reliably solve CAPTCHA challenges designed to distinguish humans from bots. While models can process images, CAPTCHA systems specifically evolve to resist automated solutions.

Fallback strategy: When encountering CAPTCHA challenges, agents should immediately pause automation and request human assistance. The handoff should preserve session state, provide context about the interrupted workflow, and allow seamless continuation after CAPTCHA completion.

async function navigateWithCaptchaDetection(agent: Agent, url: string) {
  const result = await agent.navigate(url);

  if (result.captchaDetected) {
    return {
      status: 'requires_human',
      reason: 'CAPTCHA challenge detected',
      fallback: {
        action: 'request_human_intervention',
        context: {
          url: url,
          sessionState: result.sessionId,
          instructions: 'Complete CAPTCHA and click Continue'
        }
      }
    };
  }

  return { status: 'success', data: result };
}

Complex visual reasoning

The constraint: While vision models excel at object detection and basic scene understanding, complex spatial reasoning—like interpreting intricate diagrams, architectural blueprints, or dense infographics—often exceeds current capabilities.

Fallback strategy: For tasks requiring nuanced visual analysis, implement a confidence threshold system. When visual interpretation confidence falls below acceptable levels, route to human review rather than proceeding with potentially incorrect interpretations.

def analyze_complex_diagram(image_path: str, confidence_threshold: float = 0.85):
    analysis = vision_model.analyze(image_path)

    if analysis.confidence < confidence_threshold:
        return {
            'status': 'low_confidence',
            'automated_result': analysis.result,
            'confidence': analysis.confidence,
            'fallback': {
                'strategy': 'human_review',
                'reason': f'Visual analysis confidence {analysis.confidence} below threshold {confidence_threshold}',
                'suggested_action': 'Route to specialist for manual interpretation'
            }
        }

    return {'status': 'success', 'result': analysis.result}

Multi-tab workflows

The constraint: Coordinating actions across multiple browser tabs or application windows introduces complexity that challenges many agent architectures. State management, context switching, and timing coordination become increasingly fragile with each additional context.

Fallback strategy: Recognize when workflows exceed manageable complexity and offer guided alternatives. Rather than attempting fragile multi-tab automation, break tasks into sequential single-tab operations or provide step-by-step human-guided workflows.

interface WorkflowComplexity {
  tabCount: number;
  contextSwitches: number;
  timingDependencies: number;
}

function assessWorkflowFeasibility(workflow: WorkflowComplexity) {
  const complexityScore =
    workflow.tabCount * 2 +
    workflow.contextSwitches * 3 +
    workflow.timingDependencies * 4;

  if (complexityScore > 15) {
    return {
      feasible: false,
      recommendation: 'guided_workflow',
      fallback: {
        strategy: 'break_into_sequential_tasks',
        message: 'This workflow is complex. I\'ll guide you through each step.',
        steps: generateGuidedSteps(workflow)
      }
    };
  }

  return { feasible: true };
}

Dynamic authentication flows

The constraint: Modern authentication increasingly uses dynamic methods—biometric scans, hardware tokens, SMS codes, authenticator apps—that lie outside agent capabilities. These security measures explicitly prevent automated access.

Fallback strategy: Design authentication workflows with clear human checkpoints. Agents can navigate to login pages and fill basic credentials, but should pause for human completion of multi-factor authentication steps.

Ambiguous user intent

The constraint: Natural language understanding, while sophisticated, still struggles with ambiguity, context-dependent meaning, and implicit user knowledge. Agents may misinterpret vague instructions or lack sufficient context to make appropriate decisions.

Fallback strategy: Implement clarification dialogues when intent confidence is low. Rather than guessing user meaning, explicitly ask disambiguating questions before proceeding with potentially incorrect actions.

async function parseUserIntent(instruction: string) {
  const parsed = await nlp.parse(instruction);

  if (parsed.confidence < 0.7 || parsed.ambiguities.length > 0) {
    return {
      status: 'requires_clarification',
      understood: parsed.likelyInterpretation,
      ambiguities: parsed.ambiguities,
      clarificationQuestions: [
        'Did you mean to process all items or just recent ones?',
        'Should I include archived records in the search?'
      ],
      fallback: 'await_user_clarification'
    };
  }

  return { status: 'clear', intent: parsed };
}

Common pitfalls

Hiding limitations

Organizations often obscure system limitations to avoid appearing less capable than competitors. This creates a dangerous dynamic where users encounter unexpected failures without understanding why automation suddenly stopped working.

The problem: Marketing materials promise "fully autonomous agents" while documentation buries disclaimers about CAPTCHA limitations, authentication boundaries, and visual reasoning constraints. Users build mental models based on marketing promises, leading to frustration when reality diverges.

Better approach: Lead with transparency. Explicitly document known limitations in prominent locations. Create a capabilities matrix showing what agents can and cannot do. Frame limitations as current state rather than permanent constraints, sharing roadmap plans for capability expansion.

No fallback paths

Systems designed only for the happy path collapse when encountering edge cases. Without planned fallback strategies, users face dead ends with no clear path forward.

The problem: An agent encounters a CAPTCHA and simply displays "Error: Cannot proceed." The user session ends, progress is lost, and there's no mechanism to complete the task manually or resume automation after resolving the blocker.

Better approach: Every identified limitation should have a corresponding fallback strategy. Map capability boundaries to specific alternatives: human handoff, guided workflows, partial automation, or graceful degradation to manual completion with agent assistance.

// Pitfall: No fallback
try {
  await agent.completeWorkflow();
} catch (error) {
  throw new Error('Workflow failed');
}

// Better: Structured fallback
try {
  await agent.completeWorkflow();
} catch (error) {
  if (error.type === 'CAPABILITY_LIMIT') {
    return fallbackStrategy.handle(error, {
      preserveState: true,
      offerAlternatives: true,
      enableHumanHandoff: true
    });
  }
  throw error;
}

Over-promising capabilities

Marketing and product teams often describe aspirational capabilities rather than current reality. This misalignment between promise and delivery damages user trust more severely than modest claims with reliable delivery.

The problem: Product descriptions claim "automate any workflow" or "handle complex multi-step processes" without caveats. Users attempt workflows that exceed current capabilities, encounter failures, and conclude the system is unreliable—even though it works well within actual boundaries.

Better approach: Describe capabilities with specificity and examples. Rather than "automate any workflow," specify "automate single-application workflows including form filling, data extraction, and report generation." Provide concrete examples of successful automations and clearly note scenarios requiring human involvement.

Inadequate error context

When agents hit limitations, error messages often lack sufficient context for users to understand what went wrong and how to proceed.

The problem: Generic messages like "Cannot complete task" or "Automation failed" leave users confused about whether to retry, try a different approach, or abandon the task entirely.

Better approach: Provide rich error context including: what the agent was attempting, why it cannot proceed, what specific limitation was encountered, and concrete next steps the user can take.

// Inadequate context
return { error: 'Task failed' };

// Rich context
return {
  status: 'capability_limit_reached',
  attemptedAction: 'Complete multi-factor authentication',
  limitation: 'Cannot interact with authenticator app (external to browser)',
  context: {
    currentStep: 'Step 3 of 5: Verify identity',
    completedSteps: ['Navigate to login', 'Enter credentials'],
    blockedBy: 'MFA challenge requires mobile device interaction'
  },
  nextSteps: [
    'Complete authentication on your mobile device',
    'Click "Continue" when ready to resume automation'
  ],
  fallbackStrategy: 'human_checkpoint_with_resume'
};

Ignoring partial success

Systems often treat tasks as binary: complete success or total failure. This ignores scenarios where agents successfully complete most steps but encounter limitations on specific subtasks.

The problem: An agent successfully extracts data from 47 of 50 documents but cannot process 3 due to unsupported formats. The system reports "Extraction failed" rather than acknowledging 94% success and highlighting the 3 exceptions requiring attention.

Better approach: Track and report partial success. Communicate what was accomplished, what remains incomplete, and provide paths to completion for remaining items.

Implementation

Capability detection

Build systems that understand their own limitations. Rather than attempting tasks blindly and failing, agents should assess capability boundaries before committing to automation.

Pre-flight checks: Before executing workflows, evaluate whether required capabilities are available and likely to succeed. This assessment should consider:

• Required API access and permissions
• Supported content types and formats
• Environmental constraints (network connectivity, authentication state)
• Known problematic patterns (CAPTCHA-protected sites, complex multi-tab flows)

interface CapabilityAssessment {
  taskType: string;
  requirements: string[];
  availableCapabilities: string[];
  assessment: 'fully_supported' | 'partially_supported' | 'unsupported';
  limitations: string[];
  recommendedApproach: 'full_automation' | 'guided_workflow' | 'manual_with_assistance';
}

async function assessTaskFeasibility(task: Task): Promise<CapabilityAssessment> {
  const requirements = analyzeTaskRequirements(task);
  const capabilities = await getCurrentCapabilities();

  const supportedRequirements = requirements.filter(req =>
    capabilities.includes(req)
  );

  const unsupportedRequirements = requirements.filter(req =>
    !capabilities.includes(req)
  );

  if (unsupportedRequirements.length === 0) {
    return {
      taskType: task.type,
      requirements,
      availableCapabilities: capabilities,
      assessment: 'fully_supported',
      limitations: [],
      recommendedApproach: 'full_automation'
    };
  }

  if (unsupportedRequirements.length < requirements.length * 0.3) {
    return {
      taskType: task.type,
      requirements,
      availableCapabilities: capabilities,
      assessment: 'partially_supported',
      limitations: unsupportedRequirements,
      recommendedApproach: 'guided_workflow'
    };
  }

  return {
    taskType: task.type,
    requirements,
    availableCapabilities: capabilities,
    assessment: 'unsupported',
    limitations: unsupportedRequirements,
    recommendedApproach: 'manual_with_assistance'
  };
}

Runtime monitoring: Continuously assess whether automation remains within capability boundaries during execution. Detect degrading conditions that suggest fallback activation:

• Confidence scores falling below thresholds
• Repeated failed attempts at specific actions
• Unexpected state changes suggesting environmental shifts
• Timeout patterns indicating task complexity exceeds agent capacity

Fallback strategies

Design hierarchical fallback approaches that preserve maximum value when full automation proves infeasible.

Tiered fallback hierarchy:

1. Full automation: Complete task without human intervention
2. Partial automation: Automate subset of steps, request human input for limited checkpoints
3. Guided workflow: Provide step-by-step instructions with automated assists
4. Manual with context: Human completes task with agent-provided context and resources
5. Alternative approach: Suggest different method to achieve same goal

class FallbackOrchestrator:
    def __init__(self):
        self.strategies = [
            FullAutomationStrategy(),
            PartialAutomationStrategy(),
            GuidedWorkflowStrategy(),
            ManualWithContextStrategy(),
            AlternativeApproachStrategy()
        ]

    async def execute_with_fallback(self, task: Task) -> TaskResult:
        """Execute task with progressive fallback through strategy hierarchy."""

        for strategy in self.strategies:
            if not await strategy.is_feasible(task):
                continue

            try:
                result = await strategy.execute(task)

                if result.success:
                    return result

                # Strategy attempted but encountered limitations
                if result.should_fallback:
                    continue  # Try next strategy
                else:
                    return result  # Fatal error, don't continue

            except CapabilityLimitException as e:
                # Expected limitation, continue to next strategy
                logging.info(f"Strategy {strategy.name} hit limitation: {e}")
                continue
            except Exception as e:
                # Unexpected error
                logging.error(f"Strategy {strategy.name} failed unexpectedly: {e}")
                return TaskResult(
                    success=False,
                    error=str(e),
                    fallback_exhausted=True
                )

        return TaskResult(
            success=False,
            error="All fallback strategies exhausted",
            fallback_exhausted=True
        )

Checkpoint-based fallback: For multi-step workflows, implement checkpoints where automation can pause for human input without losing progress.

interface WorkflowCheckpoint {
  stepId: string;
  completedSteps: string[];
  currentState: any;
  reason: 'capability_limit' | 'requires_decision' | 'verification_needed';
  humanActions: HumanAction[];
  resumeCondition: string;
}

async function executeWorkflowWithCheckpoints(workflow: Workflow) {
  const state = { completedSteps: [], data: {} };

  for (const step of workflow.steps) {
    if (step.requiresHumanCapability) {
      // Pause and create checkpoint
      const checkpoint: WorkflowCheckpoint = {
        stepId: step.id,
        completedSteps: state.completedSteps,
        currentState: state.data,
        reason: 'capability_limit',
        humanActions: step.humanActions,
        resumeCondition: step.resumeCondition
      };

      await saveCheckpoint(checkpoint);
      await notifyUserOfCheckpoint(checkpoint);

      // Wait for human completion
      await waitForResumeCondition(checkpoint.resumeCondition);
    } else {
      // Automated step
      const result = await executeAutomatedStep(step, state);
      state.completedSteps.push(step.id);
      state.data = { ...state.data, ...result.data };
    }
  }

  return state;
}

User communication

Clear communication about limitations and fallbacks maintains trust and sets appropriate expectations.

Proactive disclosure: Communicate limitations before users encounter them. During onboarding, task setup, or workflow design, highlight scenarios where automation may require human input.

const taskSetupGuidance = {
  'form_filling': {
    capabilities: [
      'Fill text inputs, dropdowns, and checkboxes',
      'Upload files from specified locations',
      'Submit forms and validate responses'
    ],
    limitations: [
      'Cannot solve CAPTCHAs (requires human completion)',
      'May struggle with dynamic forms that change based on previous inputs',
      'Cannot access files outside authorized directories'
    ],
    expectedFallbacks: [
      'CAPTCHA challenges: You\'ll be prompted to complete manually',
      'File uploads: You may need to select files interactively'
    ]
  }
};

function displayTaskGuidance(taskType: string) {
  const guidance = taskSetupGuidance[taskType];

  return {
    message: `Setting up ${taskType} automation`,
    capabilities: guidance.capabilities,
    limitations: guidance.limitations,
    whatToExpect: guidance.expectedFallbacks
  };
}

In-context explanations: When encountering limitations during execution, explain what happened and why in user-friendly language.

function generateLimitationExplanation(limitation: string, context: any) {
  const explanations = {
    'captcha_detected': {
      title: 'Human verification required',
      explanation: 'This page includes a CAPTCHA challenge designed to verify you\'re human. AI agents cannot solve these challenges.',
      userAction: 'Please complete the CAPTCHA, then click "Continue" to resume automation.',
      technical: 'CAPTCHA systems explicitly prevent automated solving to protect against bots.'
    },
    'mfa_required': {
      title: 'Multi-factor authentication needed',
      explanation: 'This service requires verification through your mobile device or authenticator app.',
      userAction: 'Complete the authentication on your device, then click "Continue".',
      technical: 'Agents cannot access external authentication apps or receive SMS codes.'
    },
    'complex_visual_reasoning': {
      title: 'Complex image requires review',
      explanation: 'This image contains intricate details that I cannot interpret with high confidence.',
      userAction: 'Please review the image and provide the information needed.',
      technical: `Confidence score: ${context.confidence}. Threshold: ${context.threshold}.`
    }
  };

  return explanations[limitation] || {
    title: 'Automation limit reached',
    explanation: 'This task requires capabilities beyond current automation.',
    userAction: 'Please complete this step manually.',
    technical: limitation
  };
}

Continuous feedback: During long-running workflows, provide status updates that include fallback activations and manual interventions required.

interface WorkflowProgress {
  totalSteps: number;
  completedSteps: number;
  automatedSteps: number;
  manualSteps: number;
  currentStatus: string;
  upcomingCheckpoints: string[];
}

function generateProgressUpdate(progress: WorkflowProgress): string {
  const automationRate = (progress.automatedSteps / progress.completedSteps * 100).toFixed(0);

  return `
Progress: ${progress.completedSteps}/${progress.totalSteps} steps complete
Automation: ${automationRate}% of completed steps
Current: ${progress.currentStatus}
${progress.upcomingCheckpoints.length > 0 ?
  `Upcoming manual steps: ${progress.upcomingCheckpoints.join(', ')}` :
  'No manual intervention expected'}
  `.trim();
}

Key metrics

Fallback activation rate

Definition: Percentage of tasks that trigger fallback strategies rather than completing through full automation.

Calculation: (Tasks requiring fallback / Total tasks attempted) × 100

Interpretation:

• < 5%: Excellent automation coverage with rare fallback needs
• 5-15%: Healthy balance, limitations well-understood and managed
• 15-30%: Significant fallback usage, may indicate capability-task mismatch
• > 30%: High fallback rate suggests tasks exceed agent capabilities

Actionable insights: Track fallback reasons to identify patterns. If specific limitation types dominate (e.g., 80% of fallbacks due to CAPTCHA), prioritize solutions for those constraints. Rising fallback rates may indicate users attempting increasingly complex tasks beyond current scope.

interface FallbackMetrics {
  totalTasks: number;
  fallbackActivations: number;
  fallbacksByReason: Map<string, number>;
  fallbacksByTaskType: Map<string, number>;
}

function calculateFallbackRate(metrics: FallbackMetrics) {
  const rate = (metrics.fallbackActivations / metrics.totalTasks) * 100;

  const topReasons = Array.from(metrics.fallbacksByReason.entries())
    .sort((a, b) => b[1] - a[1])
    .slice(0, 5)
    .map(([reason, count]) => ({
      reason,
      count,
      percentage: (count / metrics.fallbackActivations * 100).toFixed(1)
    }));

  return {
    rate: rate.toFixed(2),
    interpretation: rate < 5 ? 'excellent' : rate < 15 ? 'healthy' : rate < 30 ? 'high' : 'very_high',
    topReasons,
    recommendation: rate > 30 ?
      'Review task complexity vs. agent capabilities' :
      'Monitor for emerging patterns'
  };
}

User satisfaction after fallback

Definition: User-reported satisfaction scores following tasks that required fallback to human intervention.

Collection methods:

• Post-task surveys asking about fallback experience
• Comparative ratings: satisfaction with fully automated vs. fallback-assisted tasks
• Qualitative feedback about fallback clarity and helpfulness

Target benchmark: Satisfaction scores within 10% of fully automated task scores indicate well-designed fallback experiences.

Interpretation:

• High satisfaction despite fallback: Users appreciate transparency and smooth handoff
• Low satisfaction with fallback: Frustration with interruptions or unclear next steps
• Satisfaction variance by fallback type: Some fallback strategies work better than others

class FallbackSatisfactionTracker:
    def __init__(self):
        self.responses = []

    def record_satisfaction(self, task_id: str, fallback_type: str,
                          satisfaction_score: float, feedback: str):
        self.responses.append({
            'task_id': task_id,
            'fallback_type': fallback_type,
            'satisfaction_score': satisfaction_score,
            'feedback': feedback,
            'timestamp': datetime.now()
        })

    def analyze_by_fallback_type(self):
        """Compare satisfaction across different fallback strategies."""
        from collections import defaultdict

        by_type = defaultdict(list)
        for response in self.responses:
            by_type[response['fallback_type']].append(
                response['satisfaction_score']
            )

        return {
            fallback_type: {
                'avg_satisfaction': sum(scores) / len(scores),
                'sample_size': len(scores),
                'min_score': min(scores),
                'max_score': max(scores)
            }
            for fallback_type, scores in by_type.items()
        }

Capability coverage

Definition: Percentage of common user tasks that fall within agent capability boundaries (requiring no fallback or only minor fallback).

Calculation: (Fully/mostly automated tasks / Total unique task types) × 100

Interpretation:

• < 50%: Limited capability coverage, majority of tasks need significant human involvement
• 50-75%: Moderate coverage, agent handles many common tasks but gaps remain
• 75-90%: Strong coverage, agent handles most common workflows
• > 90%: Excellent coverage, rare limitations for typical use cases

Tracking evolution: Monitor capability coverage over time as agent capabilities expand. Increasing coverage indicates successful capability development aligned with user needs.

interface CapabilityCoverage {
  totalTaskTypes: number;
  fullyAutomated: number;  // 0% fallback
  mostlyAutomated: number;  // < 20% fallback
  partiallyAutomated: number;  // 20-80% fallback
  manuallyDominated: number;  // > 80% fallback
}

function assessCapabilityCoverage(coverage: CapabilityCoverage) {
  const strong = coverage.fullyAutomated + coverage.mostlyAutomated;
  const coverageRate = (strong / coverage.totalTaskTypes) * 100;

  return {
    coverageRate: coverageRate.toFixed(1),
    breakdown: {
      fullyAutomated: (coverage.fullyAutomated / coverage.totalTaskTypes * 100).toFixed(1),
      mostlyAutomated: (coverage.mostlyAutomated / coverage.totalTaskTypes * 100).toFixed(1),
      partiallyAutomated: (coverage.partiallyAutomated / coverage.totalTaskTypes * 100).toFixed(1),
      manuallyDominated: (coverage.manuallyDominated / coverage.totalTaskTypes * 100).toFixed(1)
    },
    interpretation:
      coverageRate < 50 ? 'limited' :
      coverageRate < 75 ? 'moderate' :
      coverageRate < 90 ? 'strong' : 'excellent',
    priorityGaps: identifyHighValueGaps(coverage)
  };
}

function identifyHighValueGaps(coverage: CapabilityCoverage): string[] {
  // Return task types frequently attempted but requiring high fallback rates
  // This would analyze actual task logs to identify improvement priorities
  return [
    'Multi-application workflows',
    'Complex form validation',
    'Dynamic content extraction'
  ];
}

Recovery time after fallback

Definition: Average time from fallback activation to successful task resumption or completion.

Why it matters: Shorter recovery times indicate smooth handoff experiences where users understand what's needed and can quickly provide input. Long recovery times suggest confusion, unclear instructions, or complex manual steps.

Target benchmarks:

• Simple fallbacks (CAPTCHA, MFA): < 2 minutes
• Complex fallbacks (manual data entry, decision points): < 10 minutes
• Workflow resumption rate: > 85% of fallbacks successfully resume

interface FallbackRecoveryMetrics {
  fallbackId: string;
  fallbackType: string;
  activationTime: Date;
  resolutionTime: Date | null;
  recoveryDuration: number | null;  // milliseconds
  resumed: boolean;
  userDifficulty: 'easy' | 'moderate' | 'difficult' | null;
}

function analyzeRecoveryTime(metrics: FallbackRecoveryMetrics[]) {
  const resolved = metrics.filter(m => m.resolutionTime !== null);
  const resumed = metrics.filter(m => m.resumed);

  const avgRecoveryTime = resolved.reduce((sum, m) =>
    sum + m.recoveryDuration!, 0
  ) / resolved.length;

  const resumptionRate = (resumed.length / metrics.length) * 100;

  return {
    averageRecoveryTime: (avgRecoveryTime / 1000 / 60).toFixed(2) + ' minutes',
    resumptionRate: resumptionRate.toFixed(1) + '%',
    byDifficulty: calculateByDifficulty(resolved),
    recommendation: avgRecoveryTime > 600000 ?
      'Simplify fallback instructions or break into smaller steps' :
      'Recovery time within acceptable range'
  };
}

Related concepts

Understanding limitations and fallbacks connects to broader patterns in agentic system design:

• Guided vs autonomous - Spectrum from full automation to human-led workflows, with fallbacks often transitioning between modes
• Handoff patterns - Specific mechanisms for transferring control between agent and human when limitations are reached
• Fail-safes - Protective mechanisms that prevent harmful actions when agents operate near capability boundaries
• Error recovery - Strategies for detecting and recovering from failures, including those caused by capability limitations

Effective limitation management acknowledges that today's constraints inform tomorrow's capabilities. By transparently documenting what agents cannot do, implementing graceful fallbacks, and measuring limitation patterns, teams build trust while identifying clear priorities for capability expansion. The goal is not to eliminate limitations—an impossible task—but to handle them with such clarity and grace that users remain confident even when automation reaches its boundaries.