Understanding Simple Reflex Agent Pseudocode: A Step-by-Step Guide (2026)

Understanding Simple Reflex Agent Architecture and Design

A simple reflex agent represents the most fundamental computational model in artificial intelligence decision-making systems. At its core, a simple reflex agent operates on a stimulus-response mechanism: it receives sensory input from its environment, processes that input through a fixed set of condition-action rules, and produces an immediate output without maintaining any internal memory of previous interactions or considering future consequences.

This architectural simplicity makes simple reflex agents computationally efficient and suitable for deployment in resource-constrained environments. From a cloud infrastructure perspective, simple reflex agents require minimal memory footprint, negligible state persistence, and can operate independently without requiring distributed consensus mechanisms. However, this efficiency comes at a significant cost: the agent cannot function effectively in environments that require temporal reasoning, partial observability handling, or adaptive behavior.

Engineers evaluating agent systems must understand simple reflex agents as a foundational concept before considering more sophisticated alternatives. The pseudocode structure underlying these agents reveals fundamental principles applicable to rule-based systems, event-driven architectures, and reactive programming patterns commonly deployed across modern cloud platforms including AWS Lambda, Google Cloud Functions, and Azure Functions.

The design philosophy of simple reflex agents emphasizes directness: there exists a direct causal pathway from perception to action. This one-to-one mapping eliminates the computational overhead of state management, learning algorithms, and predictive modeling. For systems requiring sub-millisecond response times in predictable environments, this direct mapping provides significant performance advantages over more complex agent architectures.

Foundational Concepts: Percepts, States, Actions, and Rules

Understanding the vocabulary and conceptual framework surrounding simple reflex agents is essential before examining their pseudocode implementations. These agents operate within a clearly defined cycle that engineers must understand thoroughly.

A percept represents the raw sensory information the agent receives from its environment at a given moment. This could be a temperature reading from a sensor, a boolean value indicating motion detection, a video frame from a camera, or a complex data structure from an API endpoint. Percepts are fundamentally instantaneous; they represent the environment’s state at a specific point in time without any historical context or future implications.

The state is the agent’s internal representation of its current situation. While simple reflex agents do not maintain persistent state across multiple time steps, they do compute a transient state representation during each decision cycle. This state is derived from the current percept through interpretation and abstraction. For example, raw temperature data (the percept) might be interpreted as the state “too_cold”, “optimal”, or “too_hot”.

Rules form the decision-making core of simple reflex agents. These are conditional statements, typically expressed as “if state X then action Y” mappings. Rules are static and predefined; the agent cannot modify, add, or remove rules during operation. They represent the complete behavioral repertoire of the agent.

Actions are the outputs the agent produces, typically commanding actuators or external systems to perform specific behaviors. Actions are discrete in simple reflex agents and directly correspond to states via the rule set.

Component	Definition	Temporal Scope	Mutable
Percept	Raw environmental sensor data	Current moment only	No (external input)
State	Interpreted representation of environment	Derived from current percept	No (derived, not stored)
Rules	Condition to action mappings	Unchanged across agent lifetime	No (hardcoded)
Action	Command sent to actuators	Executed in current moment	No (rule-determined)

Pseudocode Structure and Execution Flow

The pseudocode for a simple reflex agent follows a remarkably consistent pattern across implementations. This consistency reflects the fundamental simplicity of the agent’s architecture. The generic structure comprises three essential functions that orchestrate the perception-action cycle.

The outermost function, typically named SimpleReflexAgent(percept), serves as the main entry point. This function encapsulates the complete decision-making process for a single time step. It receives a percept as its only parameter and returns an action as its only output. Critically, the function maintains no state between invocations; each call is completely independent from previous calls.

Inside the main function, two supporting functions handle specialized tasks. The InterpretPercept(percept) function translates raw sensory data into a meaningful state representation. The Rules(state) function maps the interpreted state to an action using the agent’s decision rules. This separation of concerns provides clarity and modularity in the implementation.

The execution flow follows a linear pipeline: percept input triggers interpretation, interpretation produces state, state triggers rule matching, rule matching produces action, and the function returns the action for external execution. There are no loops, branches based on state history, or probabilistic selections. The agent simply processes the input through a deterministic pipeline and produces an output.

This deterministic, stateless design enables simple reflex agents to be implemented as pure functions in functional programming paradigms. This property proves valuable when deploying agents to cloud platforms like AWS Lambda or Google Cloud Functions, which execute stateless functions as containerized workloads. The agent’s behavior becomes fully reproducible and testable given the same percept input.

Implementing the Perception Interpretation Function

The InterpretPercept function performs critical translation work between the agent’s sensory inputs and its decision-making logic. Raw sensor data rarely maps directly to meaningful behavioral categories, necessitating an interpretation layer. This function bridges the gap between hardware or API outputs and the abstract states the rules engine understands.

Consider a temperature sensor that produces floating-point values representing ambient temperature in degrees Celsius. The raw percept might be “23.7”. However, the agent’s rules operate on categorical states like “cold”, “comfortable”, or “hot”. The interpretation function must map the raw numeric value to the appropriate category based on predefined thresholds. This thresholding operation constitutes the core work of the interpretation function.

For more complex scenarios, the interpretation function might perform multiple operations: filtering noisy sensor data, aggregating multiple sensors, normalizing values to standard ranges, or detecting specific patterns in the sensor stream. A robotic system might receive percepts from multiple proximity sensors simultaneously; the interpretation function could determine which obstacle is closest or whether the robot is surrounded by obstacles.

The interpretation function must handle edge cases and invalid inputs gracefully. If a sensor produces a value outside its expected range, the function must either map it to a valid state category or raise an exception. Robust implementations include validation logic and fallback state assignments for out-of-range values.

From a systems perspective, the interpretation function represents a critical performance bottleneck. If perception is a frequent operation in high-frequency control loops, optimizing the interpretation function becomes essential. This might involve precomputing lookup tables instead of performing real-time calculations, or using bitwise operations instead of floating-point arithmetic. Cloud-based deployments might move interpretation functions to edge devices to reduce network latency between sensors and decision-making logic.

The interpretation function also defines the agent’s “observability” of the environment. An agent cannot perceive or act upon environmental aspects that the interpretation function does not expose. If the function only extracts the presence of obstacles but not their distance, the agent cannot implement distance-aware behaviors. This limitation necessitates careful design of the interpretation function to ensure it exposes all environmental information the rules might require.

Designing and Implementing the Rules Function

The Rules(state) function represents the agent’s decision-making logic in its purest form. This function receives an interpreted state and returns an action. The implementation must be correct, efficient, and maintainable. Several implementation approaches offer different tradeoffs between performance, clarity, and flexibility.

The simplest approach uses nested if-else statements:

function Rules(state):
    if state == "cold":
        return "activate_heater"
    else if state == "hot":
        return "activate_cooler"
    else if state == "comfortable":
        return "maintain_temperature"
    else:
        return "error_unknown_state"
end function

This approach is immediately readable and requires no preprocessing. However, as the number of states increases, nested if-else chains become unwieldy and inefficient. For agents with dozens or hundreds of states, this approach becomes impractical.

A more scalable approach uses a lookup table or dictionary structure:

rule_table = {
    "cold": "activate_heater",
    "hot": "activate_cooler",
    "comfortable": "maintain_temperature"
}

function Rules(state):
    if state in rule_table:
        return rule_table[state]
    else:
        return "error_unknown_state"
end function

This approach scales much better as the number of states increases. Lookup operations typically run in constant time, making the function’s performance independent of the number of rules. This becomes critical for agents operating in high-frequency control loops where the rules function is invoked thousands of times per second.

For even more sophisticated scenarios, agents might use pattern matching or more complex conditional logic:

function Rules(state):
    if state.obstacle_distance < 0.5:
        if state.is_moving_forward:
            return "reverse_immediately"
        else:
            return "turn_ninety_degrees"
    else if state.battery_level < 0.2:
        return "navigate_to_charging_station"
    else if state.dirt_detected:
        return "activate_vacuum_and_move_forward"
    else:
        return "explore_random_direction"
end function

This approach allows the rules function to access multiple attributes of the state object and combine them in complex Boolean expressions. While this adds power, it also increases complexity and the likelihood of subtle bugs.

Regardless of implementation approach, the rules function must handle all possible states the interpretation function might produce. Unhandled states should trigger an explicit error or default behavior, never silent failures. Testing the rules function requires exercising all branches with various state inputs, ensuring the agent behaves correctly for every possible state combination.

From a maintainability perspective, the rules function is often the most frequently modified component of a simple reflex agent. Business requirements change, environmental conditions shift, and behavioral specifications evolve. Separating rules from the rest of the agent code facilitates these updates. Some implementations externalize rules entirely, storing them in configuration files or databases. This allows rules to be modified without recompiling the agent software, crucial for systems requiring frequent behavioral adjustments.

Complete Pseudocode Example: Autonomous Thermostat System

Examining a complete working example clarifies how all the pieces fit together. A simple thermostat system provides an excellent concrete case study, as thermostats are ubiquitous in real-world deployments and their behavior is immediately understandable.

function SimpleReflexThermostat(temperature_reading):
    // Step 1: Interpret the raw temperature reading
    current_state = InterpretTemperature(temperature_reading)
    
    // Step 2: Apply rules to determine action
    required_action = ThermostatRules(current_state)
    
    // Step 3: Return the action for execution
    return required_action
end function

function InterpretTemperature(raw_temperature):
    // Define temperature thresholds in Celsius
    cold_threshold = 18.0
    warm_threshold = 22.0
    
    if raw_temperature < cold_threshold:
        return "too_cold"
    else if raw_temperature > warm_threshold:
        return "too_hot"
    else:
        return "comfortable"
    end if
end function

function ThermostatRules(state):
    rule_table = {
        "too_cold": "activate_heating_full_power",
        "too_hot": "activate_cooling_full_power",
        "comfortable": "maintain_current_mode"
    }
    
    if state in rule_table:
        return rule_table[state]
    else:
        return "error_invalid_state"
    end if
end function

This simple thermostat agent operates as follows: when invoked, it receives a temperature reading in degrees Celsius. The interpretation function maps this numeric value into one of three categorical states based on predefined thresholds. The rules function then maps this state to a specific action. Finally, the main function returns the action for execution by the physical thermostat hardware.

Notice that the agent maintains absolutely no memory between invocations. If the temperature was 21 degrees Celsius (comfortable) in the previous time step and drops to 18 degrees (too_cold) in the current time step, the agent immediately activates heating. It does not consider whether the temperature is rising or falling, nor does it remember that it was comfortable moments ago. Each decision is made in isolation based solely on the current reading.

This example also illustrates why simple reflex agents fail in certain scenarios. If the thermostat is using a heating system with a substantial warm-up time, immediately activating full heating power when the temperature drops below threshold will cause overshooting, where the temperature rises above the comfortable range before the heating system is deactivated. More sophisticated agent architectures track recent actions and states to avoid this oscillation problem. Simple reflex agents lack this capability entirely.

Computational Complexity and Performance Characteristics

Simple reflex agents are designed for computational efficiency. Understanding their performance characteristics helps engineers determine whether they are appropriate for specific deployment scenarios or whether more sophisticated agent architectures are necessary.

The time complexity of a simple reflex agent is O(1) with respect to the number of time steps executed. The agent does not perform any operations that scale with the number of previous percepts or actions. Each decision cycle requires constant time regardless of how long the agent has been running or how many decisions it has previously made. This property enables simple reflex agents to operate in real-time systems with strict latency requirements.

The space complexity is similarly O(1). The agent does not accumulate data over time and requires only enough memory to store the rule table, the interpretation function, and temporary variables for the current computation. Even agents with thousands of rules require bounded memory proportional to the rule table size, not to the number of percepts processed.

In comparison, more sophisticated agent architectures like model-based agents maintain internal state representing past observations and future predictions. These require space proportional to the history window or world model complexity. Goal-oriented agents maintain representations of goals, preconditions, and effects. Utility-maximizing agents compute probability distributions over future states. All of these consume substantially more computational resources than simple reflex agents.

The deterministic nature of simple reflex agents enables horizontal scaling across cloud platforms. Since each agent instance is stateless and requires no coordination with other instances, load can be distributed arbitrarily across multiple containers or virtual machines. Cloud platforms like Kubernetes automatically handle load balancing for stateless services, making simple reflex agents ideal for serverless execution models.

However, this computational efficiency comes with a critical limitation: simple reflex agents cannot solve problems requiring temporal reasoning, state accumulation, or historical context. In scenarios where the optimal decision depends on previous states or the history of actions, simple reflex agents are fundamentally incapable of generating correct behavior. The limitation is not computational but architectural; no amount of additional processing power can overcome the agent's inability to maintain internal state.

Limitations and Failure Modes in Dynamic Environments

Simple reflex agents excel in static, fully observable environments where the current percept completely determines the optimal action. However, they fail systematically in more complex scenarios. Understanding these limitations helps engineers recognize when simple reflex agents are inappropriate and more sophisticated agent architectures are necessary.

The most fundamental limitation is the lack of internal state maintenance. Many real-world scenarios require knowing what happened previously to make correct decisions. Consider a robot navigating a building where the optimal path depends on whether certain areas are already cleaned, blocked, or safe. A simple reflex agent cannot track which areas have been visited; it can only react to the current configuration of sensors. This forces the robot to potentially repeat work or make suboptimal decisions.

A critical failure mode occurs in scenarios with perceptual aliasing. Two different situations might produce identical percepts, yet require different actions based on context. Imagine an agent navigating a maze. The percept might be "wall ahead" in two different locations. A simple reflex agent cannot distinguish between these situations and might apply the same action (turning left) regardless of which location it occupies. A more sophisticated agent maintaining an internal map could disambiguate the situations and choose appropriate actions.

Simple reflex agents also struggle with noisy environments where sensor readings fluctuate around boundary values. If a temperature sensor reads 22.0 degrees Celsius and the comfortable range is defined as 18.0 to 22.0, the agent might oscillate between "comfortable" and "too_hot" states if the actual temperature hovers near the threshold. The agent might constantly activate and deactivate the cooling system, causing wear on equipment and wasting energy. More sophisticated agents could maintain hysteresis, tracking the previous action to avoid excessive switching.

Another failure mode occurs when the percept provides insufficient information for optimal decision-making. The interpretation function can only extract information present in the current percept. If critical environmental information is not captured by the sensors, the agent cannot act on it. For example, a robot with only proximity sensors and no directional information might know that an obstacle exists but not which direction to move to avoid it.

Finally, simple reflex agents cannot implement behaviors requiring lookahead or goal satisfaction. They cannot plan sequences of actions to achieve desired outcomes. They cannot assess whether current actions are moving toward goals or away from them. They simply execute condition-action pairs without any understanding of why those actions are appropriate.

Cloud Deployment Architectures for Simple Reflex Agents

Despite their limitations, simple reflex agents appear frequently in cloud-based systems. Their stateless nature and constant-time complexity make them ideal for specific deployment patterns. Understanding how to architect cloud systems around simple reflex agents helps engineers leverage their strengths while mitigating their weaknesses through architectural patterns.

Serverless function platforms like AWS Lambda, Google Cloud Functions, and Azure Functions are natural homes for simple reflex agents. Each function invocation receives a percept (typically extracted from an API request, message queue, or sensor data stream), executes the agent logic, and returns an action (typically sent to an output topic, API endpoint, or actuator). The platform automatically handles scaling, load balancing, and resource management. No persistent containers are required, and charges are based on execution time and invocations, not on idle capacity.

A typical architecture might use message queues to decouple sensor systems from agent decision-making. Sensors publish percepts to a queue topic. A serverless function subscribes to this topic, invokes the simple reflex agent, and publishes the resulting action to an output topic consumed by actuators. This decoupling enables independent scaling of sensors, agents, and actuators, and provides resilience if any component becomes temporarily unavailable.

For higher-frequency control loops, containerized agents deployed on Kubernetes provide more predictable latency and throughput characteristics. Kubernetes services automatically load-balance requests across multiple agent containers, enabling horizontal scaling. Container registries like Docker Hub or AWS ECR store agent code, enabling rapid deployment updates and rollbacks.

Edge computing deployments bring agent decision-making closer to sensors and actuators. Rather than sending raw percepts to cloud servers for processing, agents run on edge devices like IoT gateways or industrial computers. This dramatically reduces latency, critical for systems requiring immediate responses. However, edge deployments complicate operations; agents must be deployed, monitored, and updated across potentially hundreds of devices. Management platforms like AWS Greengrass or Azure IoT Edge provide tools for distributed agent management.

For scenarios requiring both low latency and central coordination, hybrid architectures combine edge and cloud agents. Edge-deployed simple reflex agents handle immediate, local decision-making. Cloud-deployed agents provide higher-level coordination and learn from aggregate patterns across many edge agents. This architecture balances responsiveness with centralized intelligence.

Observability becomes critical in cloud deployments. Each agent invocation should log its percept, interpreted state, applied rule, and resulting action. These logs enable debugging when agents produce unexpected behavior and provide datasets for analyzing agent effectiveness. Cloud platforms provide centralized logging services like AWS CloudWatch, Google Cloud Logging, or Azure Monitor that aggregate logs from distributed agent instances.

Comparison with More Advanced Agent Architectures

Engineers evaluating agent systems must understand how simple reflex agents compare to more sophisticated alternatives. This comparison helps determine which architecture is appropriate for specific problems.

Model-based reflex agents enhance simple reflex agents by maintaining an internal state representation of the environment. Rather than making decisions based solely on the current percept, they combine the current percept with historical information stored in the model. This enables them to handle partially observable environments and situations where temporal context matters. However, model-based agents require memory and computation to maintain and update the model.

Goal-oriented agents extend model-based agents by incorporating explicit goal representations. They select actions not based on preprogrammed rules but on whether actions move the agent closer to achieving specified goals. This enables greater flexibility and adaptability. However, goal-oriented agents require more sophisticated planning algorithms and more computation.

Utility-maximizing agents further extend goal-oriented agents by assigning numerical utilities to outcomes and selecting actions that maximize expected utility. They can handle scenarios with conflicting goals by explicitly weighing their relative importance. However, utility-maximizing agents require probability distributions over future states and extensive computation to search through possible action sequences.

Learning agents incorporate adaptation mechanisms that modify the agent's behavior based on experience. Rather than using fixed rules, learning agents adjust rules or improve predictions based on observed outcomes. This enables them to improve performance in complex, partially understood environments. However, learning agents require training data, more sophisticated algorithms, and substantially more computation.

Agent Type	Internal State	Decision Basis	Time Complexity	Suitable For
Simple Reflex	None	Current percept only	O(1)	Fully observable, static environments
Model-Based Reflex	Yes, world model	Current percept + history	O(n) where n = history size	Partially observable, temporal context matters
Goal-Oriented	Yes, goals + model	Goal satisfaction via planning	O(b^d) where b = branching factor, d = depth	Complex objectives, multi-step reasoning required
Utility-Maximizing	Yes, preferences + model	Expected utility maximization	Exponential in search space size	Conflicting goals, probabilistic outcomes
Learning Agent	Yes, learned model	Experience-based adaptation	Training-dependent, often high	Complex, poorly understood domains

For many real-world systems, the appropriate agent architecture falls somewhere between simple reflex and fully learning-based approaches. Engineers must evaluate problem characteristics to determine the minimum architectural sophistication required. Selecting an architecture that is more complex than necessary wastes computational resources and complicates operations. Selecting one that is too simple leads to incorrect or suboptimal behavior.

Testing, Validation, and Safety Considerations

Simple reflex agents must be thoroughly tested before deployment to ensure correct behavior across all possible percepts and states. The deterministic nature of these agents makes exhaustive testing feasible in ways that are impossible for learning-based systems.

Unit testing focuses on the individual functions. The interpretation function should be tested with various percept values to ensure correct state mapping, including boundary cases, invalid values, and edge cases. For example, a thermostat interpretation function should be tested with temperature values far above and below the comfortable range, floating-point precision edge cases, and invalid inputs like null or non-numeric values.

The rules function should be tested with all possible states the interpretation function might produce, plus several invalid states to verify error handling. Each rule should be exercised to confirm it produces the correct action. For systems with decision tables, every cell in the table should be tested.

Integration testing verifies that the complete agent operates correctly. The agent should be tested with realistic percept sequences that simulate actual operating scenarios. Test sequences should include normal operation, boundary conditions, and abnormal situations that might occur rarely in production but could cause failures if unhandled.

Formal verification provides the highest level of assurance. For agents controlling critical systems, mathematical proofs can verify that the agent will never produce unsafe actions regardless of percept values. This is particularly important for agents controlling physical systems like vehicles, industrial machinery, or medical devices.

Safety considerations are paramount when agents control physical systems that could cause harm. Every possible action the agent might produce must be analyzed for safety implications. Safeguards should prevent the agent from executing dangerous action sequences. For example, a robot's agent should never command the robot to move toward a cliff even if a sensor malfunction produces misleading percepts. Hardware interlocks, fallback modes, and fail-safe designs complement the agent's decision logic.

In cloud deployments, chaos engineering tests verify that agents handle infrastructure failures gracefully. What happens if the queue containing percepts goes offline? What happens if the service is unable to respond to the caller? Resilient architectures include retry logic, timeouts, circuit breakers, and fallback behaviors.

Real-World Implementations and Case Studies

Simple reflex agents appear in numerous real-world systems across diverse industries. Examining actual implementations clarifies how agents function in practice and highlights common patterns and pitfalls.

Industrial thermostat systems exemplify simple reflex agents. Modern thermostats measure temperature continuously and adjust heating or cooling based on the current reading relative to target setpoints. While sophisticated thermostats incorporate learning algorithms to adapt to occupancy patterns, the fundamental temperature control loop operates as a simple reflex agent. Cloud-connected thermostats report data to cloud platforms where analytics systems detect patterns, but the local thermostat itself maintains no complex state.

Robotic vacuum cleaners like Roomba and similar products operate primarily as simple reflex agents. They have proximity sensors, dirt detection sensors, and bump sensors. Rules map sensor states to movement commands: if a bump sensor triggers, reverse and turn; if dirt is detected, activate vacuum; if no obstacles, continue forward. The vacuum maintains no map, learns no patterns, and remembers nothing between charging cycles. Despite this simplicity, millions of units clean homes effectively because home environments are relatively predictable and static.

Building access control systems use simple reflex agents for door control. When proximity sensors detect authorized badge-holders, the agent commands doors to unlock. When card readers validate credentials against a database lookup, the agent commands magnetic locks to release. These systems must respond in milliseconds, and their logic is inherently reactive; they exist only to respond to authentication events.

Traffic light control systems often use simple reflex agents to manage signal timing. Sensors detect vehicles in each lane. Rules map traffic patterns to signal phases: if vehicles are waiting in the northbound lane for more than thirty seconds, switch to green for north. While more sophisticated traffic systems use machine learning to adapt to traffic patterns, the fundamental cycle switching still operates as reflex agents responding to current queue lengths.

Industrial sensor-based monitoring systems frequently employ simple reflex agents. Manufacturing equipment has numerous sensors monitoring temperature, pressure, vibration, and other parameters. Agents continuously compare current readings against acceptable ranges. If any parameter exceeds its threshold, the agent triggers an alert or initiates a protective action like shutting down the equipment. These systems must respond within seconds to prevent equipment damage.

Cloud-based API gateways use simple reflex agent logic to route requests. Rules map request characteristics (headers, path, parameters) to backend services or security policies. While API gateways implement more sophisticated features like caching and transformation, the fundamental request routing operates as condition-action rules applied to incoming requests.

Designing Rules for Real-World Scenarios

Translating real-world requirements into effective rules requires careful analysis and testing. The apparent simplicity of "if condition then action" masks significant complexity in practice.

Effective rule design begins with understanding the problem domain deeply. What states can the environment actually occupy? What actions can the agent execute? What are the consequences of each action? Are there constraints on action sequences? For example, a robot cannot rotate left and move forward simultaneously; these are distinct actions that must be chosen sequentially.

Rules must be complete; there should be no possible state for which no rule exists. This is often challenging because identifying all possible states requires exhaustive analysis. One approach is to define a set of specific states the agent should handle explicitly, then provide a default rule that handles all other states. The default rule might perform a safe action or log an error for debugging.

Rules should be unambiguous; no state should match multiple rules that produce different actions. If the rule set is ambiguous, the agent's behavior becomes unpredictable. A state definition must be precise enough to uniquely identify the situation it represents.

Rules should align with physical and temporal constraints. An action that requires equipment to cool from high temperature to room temperature takes time. Issuing contradictory commands in consecutive time steps might damage equipment. Rules should account for the time required for actions to take effect and avoid issuing new commands before previous actions complete.

Rules must balance responsiveness with stability. If thresholds are set too tight, the agent might oscillate rapidly, causing equipment wear and wasting energy. If thresholds are too loose, the agent might fail to respond to genuine problems. Hysteresis, where different thresholds apply for transitioning into and out of a state, helps prevent oscillation.

For systems deployed in cloud environments with potentially high latency between perception and actuation, rules must account for outdated percepts. An action chosen based on a percept that is tens of seconds old might be inappropriate for the current environment. Conservative rules that assume the worst or progressive rules that gradually escalate response might be more appropriate than aggressive rules that assume the percept reflects current reality.

Frequently Asked Questions