relayr-ai 0.1.1

relayr is the bridge between artifactr and reflexr: events from chats and artifacts become events for rules, and runs act back in the chat as proposals and notices. It uses only the two libraries' public APIs, and neither library imports it or the other.

Status: built: the v0.1 plan. Both adapters, telemetry across the bridge, rules from chat and evaluation, and stackr's template wires it all into an application. It is on PyPI as relayr-ai, since the name relayr on PyPI is an unrelated project, and it is imported as relayr: uv add relayr-ai.

Why

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.

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).
• 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).
• Evaluation (built). Proposal outcomes become feedback on the runs that proposed them, with measures of acceptance, rewrites and rules from chat that stay live, in the evals extra.
• A ledger of its own (built), in memory or in SQL, behind the sql, sqlite and postgres extras.

Documentation

relayr's documentation is its section of lattice's site, at https://lattice.alexnodeland.com/relayr/, built from docs/relayr/.

• Bridging artifactr into reflexr: wiring the followers into an application.
• Acting in artifactr from rules: the outbound adapter, allowlists and loops.
• Tracing across the bridge: links, Langfuse tags and counters.
• Rules from chat: drafting, previewing and installing rules, and drift.
• Evaluating the bridge's rules: proposal outcomes and the measures.
• Architecture: what exists, and how it works.
• Architecture decision records: why each part is the way it is.
• RFCs: the v0.1 plan, its phases and what each waits on.
• The combined system, stackr's RFC-0002: the design relayr builds.
• Brand: the mark and its colours.

Contributing

See CONTRIBUTING.md for setup, the trunk-based workflow, and the RFC and ADR process.

License

MIT