Event-Driven Triggers + Reactive Agents

The goal splits into two reusable layers plus a thin demo app:

• Part A - Event system: an event can fire a message to an agent (an existing conversational agent or a Part B agent).
• Part B - Reactive agents: agents with no conversation. On trigger they receive a prepared list of data, then emit a response (or a sequence of tool-using responses) until the task is finished - place a bet, fetch more data, close a bet, register a new trigger.
• Demo app - Sports betting: a feed poller emits game_start / goal / red_card events; a sports_bettor reactive agent reacts to each.

Key finding: roughly 80% of the required machinery already exists in the codebase. The plan reuses it rather than rebuilding.

Time triggers (cron/interval/once) and event triggers are the same idea: a condition that fires a message to an agent. So Part A is not a new subsystem - it generalizes the existing scheduler. One table, one handler, one dispatch path; the only thing that differs is the trigger source - a clock vs a push.

Not a new LLM class - a prompt capability + a lifecycle convention over existing machinery.

reactive_agent prompt capability

Defines the contract:

1. You are triggered by an event or supervisor message - not a conversation.
2. The trigger payload + seed_parts give you a prepared data list.
3. Gather any additional data via tools.
4. Act to completion (place bet, fetch more, close bet).
5. Optionally register follow-up triggers via the scheduler capability (schedule_type=event).
6. End the turn.

Lifecycle (recommended default)

Ephemeral instance per trigger via inject-and-create with extra_seed_parts = [event payload + data-prep resolve parts]. This maps exactly to 'a prepared list of data -> a response -> run to completion'. (Alternative: a long-lived instance that calls clear_history between events.)

Everything below is done by an agent sending CHMP messages - no human code, no deploy. That is what makes the loop self-service: an agent can author a reactive agent, wire a trigger to it, and let that agent register further triggers at runtime.

Step 1 - Author a reactive agent spec → agent_builder

Define the agent once: its capabilities, its contract prompt, and the data it should auto-prepare on every trigger (seed_parts, resolved live into one turn).

{
  "header": {"message_title": "agent_builder_create_agent_request",
             "destination": {"id": "agent_builder", "type": "AGENT_BUILDER"}},
  "body": {
    "agent_id": "sports_bettor",
    "capabilities": [
      {"name": "central_hub",    "version": 1},
      {"name": "reactive_agent", "version": 1},
      {"name": "sports_data",    "version": 1},
      {"name": "event_trigger",  "version": 1},
      {"name": "memory",         "version": 1}
    ],
    "customized_prompt": "You are a live sports bettor. On each trigger, ...",
    "seed_parts": [
      {"literal": "## Strategy rules + open ledger"},
      {"request": {"header": {"message_title": "memory_read_request",
                   "destination": {"id": "memory", "type": "MEMORY"}},
                   "body": {"operation": "read", "environment": "sports_betting",
                            "key": "config/strategy/rules"}}}
    ]
  }
}

Step 2 - Register an event trigger → scheduler

The same scheduler handler used for cron jobs - just with schedule_type: "event". {date}/{run_id} in agent_instance_id means 'spawn a fresh instance per event'; a static id means 'deliver to the existing instance'.

{
  "header": {"message_title": "scheduler_create_job_request",
             "destination": {"id": "scheduler", "type": "SCHEDULER"}},
  "body": {
    "operation": "create",
    "name": "soccer_goal_to_bettor",
    "schedule_type": "event",
    "schedule_expression": "sports_feed:goal",   // event key = source:type
    "match_filter": {"league": "soccer"},          // optional comparison
    "agent_id": "sports_bettor",
    "agent_instance_id": "sports_bettor_{date}_{run_id}",  // fresh instance per event
    "supervisor_message": "A goal was scored. Evaluate the edge and act.",
    "owner_email": "owner@example.com",
    "enabled": true
  }
}

Identical shape to a cron job - only schedule_type plus the new match_filter / extra_seed_parts fields differ. One handler, one registry, one dispatch.

Step 3 - The loop closes itself

While the reactive agent is running, it issues the exact same register call to set up its OWN follow-up trigger (e.g. a final_whistle trigger to settle the bet). New triggers are built at runtime by the agent - no human in the loop.

A trigger condition (e.g. 'price first exceeds 100') can be a comparison. Recommended: the comparison lives in the producer. The producer turns a continuous signal into a discrete fact and emits only when the condition flips - the event bus then just routes facts.

Producer-side (Pattern A) - the recommended shape

// producer config, per watch
{ "symbol": "AAPL", "op": "gt", "threshold": 100 }

// emitted ONLY when price crosses 100 from below
POST /api/events/ingest
{ "source": "stocks", "type": "price_cross_above",
  "payload": { "symbol": "AAPL", "threshold": 100, "price": 100.3 } }

Clean refinement: declare the threshold in the subscription, and have the producer read enabled subscriptions to learn which thresholds to watch and do the edge-detection. The condition stays declarative; the statefulness stays in the producer.

match_filter (Pattern B) - stateless field comparison

"match_filter": { "symbol": "AAPL", "price": { "gte": 100 } }

Operators: eq ne gt gte lt lte in. Fires on every matching event (not just the first) - use one_shot: true for 'fire once, then disable'.