payload: { stream_name: "todos-live", group_id: "default", data: event.new_value },
action: TriggerAction.Void(),

}); });

iii.registerTrigger({ type: "state", function_id: "todos::on-change", config: { scope: "todos" }, });

## Observer Side Effects

Use an observer when "after X runs (or fails), also do Y" and X should not know about Y: audit
logs, alerts, projections, cache invalidation. Every function is observable since 0.25, and an
observer failure never affects the observed call.

```typescript
import type { Observed } from "iii-sdk";

iii.registerFunction("audit::order-created", async (event: Observed) => {
  await iii.trigger({
    function_id: "state::set",
    payload: { scope: "audit", key: event.invocation_id, value: { order: event.input, by: event.caller?.worker_name } },
  });
  return null;
});

// every successful orders::create, except the replay tool's own calls
iii.observe(
  { function_id: "orders::create", filters: { "caller.worker_name": { $ne: "order-replayer" } } },
  "audit::order-created",
  { max_in_flight: 8 },
);

def notify(event):  # the Observed envelope: input, error, caller, ...
    print("charge failed", event["input"], event["error"]["code"])

iii.register_function("alerts::payment-failed", notify)
iii.observe(
    {"function_id": "payments::charge", "on": "error", "filters": {"input.amount": {"$gte": 500}}},
    "alerts::payment-failed",
)

Activations are at most once and fire-and-forget. When the side effect must complete with retries, have the target enqueue the work (TriggerAction.Enqueue). Filter on caller or caller.parent to stop echo loops; the engine also drops activations deeper than observers.max_observe_depth (8 by default).

Agentic Backend

Model each agent as a function with one responsibility. Store shared context in state and hand off work through named queues.

iii.registerFunction("agents::researcher", async (task) => {
  await iii.trigger({
    function_id: "state::set",
    payload: { scope: "research", key: task.id, value: { findings: [] } },
  });
  return iii.trigger({
    function_id: "agents::critic",
    payload: task,
    action: TriggerAction.Enqueue({ queue: "agent-tasks" }),
  });
});

Event-Driven CQRS

Commands validate and publish domain events. Projections subscribe independently and write query-optimized state.

iii.registerFunction("cmd::add-inventory-item", async (input) => {
  const event = { type: "inventory.item-added", itemId: input.itemId, quantity: input.quantity };
  await iii.trigger({
    function_id: "state::set",
    payload: { scope: "inventory-events", key: `${Date.now()}-${input.itemId}`, value: event },
  });
  await iii.trigger({ function_id: "publish", payload: { topic: event.type, data: event } });
  return { accepted: true };
});

iii.registerTrigger({
  type: "subscribe",
  function_id: "proj::inventory-list",
  config: { topic: "inventory.item-added" },
});

// Alternative without pub/sub: the projection observes the command function directly and
// receives its input (the command) on every successful call.
iii.observe({ function_id: "cmd::add-inventory-item", deliver: "input" }, "proj::inventory-list");

registerTrigger is deprecated in 0.25 (one warning per process) but stays the way to bind the built-in subscribe, state, cron, http, and queue providers, which have not migrated to source functions yet.

Selection Rules

• Use sync composition for short effect pipelines where the caller needs the final result.
• Use enqueue for unreliable, slow, or must-complete steps.
• Use pub/sub for independent fan-out where each subscriber can tolerate event-style delivery.
• Use state triggers for derived views and side effects that should run automatically after writes.
• Use observers for side effects of a specific function's calls, results, or failures, when the caller should not know about them and at-most-once delivery is acceptable.
• Use cron triggers for scheduled maintenance and periodic starts.
• Keep each function small enough to test independently.

When to Use

• Use this skill for complete backend patterns: workflows, agentic systems, reactive apps, CQRS, effect pipelines, and automation chains.
• Use this when the request describes product behavior rather than a single SDK API call.

Boundaries

• For exact trigger config, function registration syntax, custom triggers, channels, and HTTP-invoked functions, use iii-core-primitives.
• For observer options, filters, and owner-delivered event sources, use iii-observe.
• For engine ports, adapters, engine-owned workers, and RBAC (rbac-proxy), use iii-engine-config; queue retry and FIFO policy live with the queue worker's docs.
• For package-specific SDK syntax, use iii-sdk-reference.
• Worker-backed capability details live with the worker docs, not as top-level iii skills.