feat: Agent Lifecycle & Activation Framework with Pluggable Policies

[aryanbhosale]

Summary

This issue proposes an agent lifecycle and activation framework for OASIS — a pluggable system that governs which agents are active, what capabilities they have, and how they transition between lifecycle states across simulation steps.

The core motivation comes from applying Extended Game of Life (Getz & Salter, 2022) cellular automata rules to social graph topology, but the framework is designed to be general-purpose and beneficial to all OASIS simulations.

Problem

Currently in OASIS, every agent is always active with full capabilities every simulation step. This creates three issues:

1. Unrealistic behavior. Real social platforms have user lifecycles — new accounts have restricted capabilities (Twitter rate limits new accounts, Reddit requires karma for certain subs), users go through phases (lurker → occasional poster → power user → inactive), and most users are dormant at any given moment.

2. Cost at scale. Every agent hits the LLM every step(). At 10K+ agents, this is expensive. There is no way to say "only 20% of agents are active this step" based on principled rules rather than random sampling.

3. Missing research axis. There is no way to study how activation dynamics shape social phenomena. Questions like "how does gradual capability unlocking affect misinformation spread?" or "what happens when agent activity follows local neighborhood rules?" cannot be explored with the current architecture.

Proposal

An agent lifecycle framework with three components:

1. Agent States

Each SocialAgent gets a lifecycle state that persists across steps:

class AgentState(Enum):
    DORMANT = 0     # Inactive, no actions
    NEW = 1         # Can observe, like, follow
    ACTIVE = 2      # Can also comment
    ESTABLISHED = 3 # Full capabilities (post, moderate, etc.)

State determines which ActionType values are available to the agent on any given step.

2. Activation Policies (Pluggable)

An ActivationPolicy interface that runs on AgentGraph and determines state transitions:

class ActivationPolicy(ABC):
    @abstractmethod
    def compute_transitions(
        self,
        agent_graph: AgentGraph,
        current_states: dict[int, int],
    ) -> dict[int, int]:
        """Given current agent states and the social graph, return new states."""

Concrete policies could include:

• AllActivePolicy — every agent is always ESTABLISHED (current default behavior, backwards compatible)
• EngagementPolicy — agents that receive likes/follows progress; inactive agents decay
• ThresholdPolicy — activate when follower count or post count crosses thresholds
• CellularAutomataPolicy — Extended Game of Life rules (Getz & Salter, 2022) running on the social graph topology, where local neighborhood rules based on follower connections determine birth/progress/death of agent activity, producing emergent global patterns such as activation cascades, dormancy waves, and cluster formation

3. Integration with OasisEnv.step()

Each simulation step becomes:

step():
  1. policy.compute_transitions(agent_graph, states)  # deterministic, cheap
  2. update each agent's available_actions based on new state
  3. run LLM actions only for active agents            # expensive, but fewer agents

Why Cellular Automata Specifically

The Extended Game of Life (n-state generalization of Conway's GoL) is particularly interesting for social simulation because:

• Local rules, global emergence. Simple neighbor-based rules produce cascades, oscillations, and self-organizing patterns — analogous to viral content spread and echo chamber formation.
• Tunable complexity. The parameter space (state_values, transition_bounds) lets researchers control how easily agents activate, how long they stay active, and what neighborhood conditions trigger transitions.
• Cheap. The activation layer is pure NumPy — negligible cost compared to LLM calls.
• On the social graph, not a grid. The "neighborhood" is an agent's followers/following, not a 2D grid. This is what makes it useful for social simulation rather than a toy.

Reference: Getz & Salter (2022), "Extending Conway's Game of Life" — extends GoL to n states with birth/progress/die transition rules controlled by neighborhood value sums.

Benefits to OASIS

• Realism — agent lifecycles with capability progression mirror real platform behavior
• Cost — 5-10x fewer LLM calls per step when only active agents reason
• Research — new experimental axis (how do activation dynamics shape social outcomes?)
• Backwards compatible — default policy is AllActivePolicy which preserves current behavior

Proposed Implementation Plan

I am happy to break this into smaller PRs if preferred:

1. AgentState enum and state management on SocialAgent — add lifecycle state attribute with ActionType filtering based on state
2. ActivationPolicy abstract interface — define the pluggable policy contract
3. AllActivePolicy — default implementation preserving current behavior
4. OasisEnv.step() integration — wire policy transitions into the simulation loop
5. CellularAutomataPolicy — Extended GoL rules on AgentGraph topology
6. Example script and tests — demo simulation and unit/integration tests

Each PR would include unit tests and updated documentation following the existing conventions.

Questions for Maintainers

1. Is agent lifecycle something you would want as a core OASIS feature, or better as an external extension?
2. Should activation state live on SocialAgent or be managed externally by OasisEnv?
3. Any constraints on how available_actions filtering should work with the existing perform_action_by_llm() flow?
4. Would you prefer this as a single PR or broken into smaller pieces as outlined above?

Happy to prototype any of this. Would love feedback on the direction before writing code.