relayr¶

Why: one bridge, built once¶

An application can mount artifactr and reflexr side by side, on one database and one telemetry setup, over one shared context: the same tenant and workspace ids name the same context in both. But the two halves don't talk to each other. A rule can't see what people say in a thread, and a run can't put its result in front of the people it concerns. Each application that wants this would write its own glue, and meet the same hard parts: duplicate and lost deliveries, rules that trigger themselves, two kinds of session that don't line up, and events that anyone could forge.

stackr's RFC-0002 designs the bridge once, and relayr is where it is built. It uses only the two libraries' public APIs, and neither library imports it or the other.

What it does¶

• Inbound: chats and artifacts become events (built). One follower per workspace, with a lease, a cursor and dead letters, publishes selected artifactr events into reflexr under the artifactr namespace, such as artifactr:message_posted, artifactr:artifact_changed and artifactr:proposal_resolved, so that a message fires a rule exactly once, across a restart and a redelivery (ADR-0006, the guide).
• Outbound: runs act as participants (built). A pydantic-ai capability and helpers let a run act in artifactr as its rule's own external agent, reflexr:<rule>, so artifactr's rules apply to it: under a propose write policy its edits are proposals, and relayr never resolves one (ADR-0002).
• Notices by default (built). A rule's messages start no turn in the thread, unless the rule's allowlist grants it (ADR-0007).
• Chains and sessions kept apart, and linked (built). A thread is never a causal chain, and a chain never joins a thread's session or model history; traces are linked, and Langfuse sessions tagged, across the two (ADR-0003, ADR-0004).
• Rules from chat (built). A rule drafted in a thread is a rule artifact, reviewed as a proposal, and goes live in reflexr's stored rules only when a person who may install rules accepts it, with provenance recorded both ways. A rule changed in reflexr directly is proposed back to its artifact (ADR-0005, the guide).
• Evaluation (built). Proposal outcomes become feedback on the runs that proposed them, with measures of acceptance, rewrites and rules from chat that stay live (the guide).
• Task trackers (phase 1 built). A rule's run files, comments on and moves items in Plane's Community edition or Vikunja, each once however often the run is retried, by a key the ledger claims before anything is sent (lattice RFC-0004, the guide). Changes people make in the tracker come back as events in its phase 2.
• A ledger of its own (built), in memory or in SQL, behind the sql, sqlite and postgres extras.
• Forms for rules (built). With the forms extra, relayr.ui bridges an answer to artifactr's ask_form, and a submission to a form, both as ui:form_submitted, so a rule is written once for both ways of asking.

RFC-0001 built these in phases after the foundation, and records what each waited on in the libraries.

Where to go next¶