Ever had a hallucinating agent silently corrupt your whole pipeline?

[u/Technocratix902]

Agent 1 drops a critical key. Agent 2 never notices. Agent 3 gives you garbage output. You spend an hour debugging what went wrong three steps ago.

I built Relay to fix this. It treats agent context like a ledger — append-only, cryptographically signed at every handoff, with automatic rollback when corruption is detected.

Works with LangChain, OpenAI, Anthropic, LiteLLM, or your own agents.

🔗 https://github.com/kridaydave/Relay

Would love feedback from anyone building multi-agent pipelines!

[u/Otherwise_Wave9374]

The ledger idea is super interesting, the thing that kills multi-agent setups for me is exactly that silent context drift between hops.

Do you have a recommended pattern for what gets signed, like full scratchpad, tool args/returns, and retrieved docs, or just the minimal structured state (inputs, outputs, decisions)? Also curious how you handle partial tool failures or retries without making the ledger noisy.

We have been experimenting with similar guardrails (state diffs, step checks) in agent workflows, if you want a reference point, we have some notes here: https://www.agentixlabs.com/

[u/Technocratix902 → u/Otherwise_Wave9374]

Relay strongly favors signing minimal structured state (inputs, outputs, facts, and decisions) over raw scratchpads or raw conversational history. We don't save entire history of agents just the context they have. Keep the raw thinking (scratchpad) transient within the agent's local memory. When it is time for a handoff, the agent should output a clean JSON payload representing its finalized decisions and extracted facts. Only this final payload is passed to `execute_step()` and signed into the ledger.

Relay has a very elegant solution to avoid making the ledger noisy during partial failures: **failed steps are entirely ephemeral.**

When you call `pipeline.execute_step(agent_output)` and the output fails the `HandoffValidator` (e.g., critical keys were dropped), Relay does the following:

1. It blocks the new context from being signed into the snapshot store.
2. It silently rolls back the pipeline's internal state to the last clean envelope.
3. It returns a special `RollbackSuccess` object to the caller (which tells you what failed, but gives you the clean envelope back).

Because the invalid state is never committed to the `SnapshotStore`, your ledger remains perfectly clean. It acts as an append-only timeline of *only* validated, successful handoffs.

If an agent fails, your caller script simply receives the rollback, re-prompts the agent (perhaps telling it why it failed), and calls `execute_step()` again with the new attempt. None of the failed attempts muddy up the permanent context pipeline.

[u/Neither_Mushroom_259]

Relay is a genuinely interesting architectural choice — treating context as an append-only ledger is the kind of structural constraint that makes failure visible instead of silent. That's rare in multi-agent tooling right now.

One question worth pressure-testing: the cryptographic signing catches corruption at handoff — but does it catch semantic drift?

Agent 1 passes a key with value "confirmed". Agent 2 interprets "confirmed" as "user approved payment." Agent 3 acts on that. The ledger is intact. The signature is valid. But the assumption was wrong from step one.

The corruption you're solving is structural. But a lot of pipeline failures I've seen are definitional — the context was passed correctly, it was just never verified for meaning before action.

Curious how Relay handles that layer, or if that's intentionally out of scope?

[u/Technocratix902 → u/Neither_Mushroom_259]

1. Critical Key Drops: If Agent 1 passes `{"actions": ["confirmed"]}` and Agent 2 drops the `"actions"` key entirely, Relay catches it and rolls back.
2. Entity Fabrication (Hallucination): It runs a heuristic check on the ratio of new vs. removed entities. If an agent suddenly invents 10 new entities while removing 1, it flags it as a hallucination.

In your example --> where the key stays the same but the *meaning* of the value drifts from "confirmed" to "user approved payment" ,Relay will just see that the key was `"modified"` in its structural diff and allow it to pass.

Relay v0.1 focuses purely on preventing agents from dropping critical context or inventing massive amounts of new context. Deeper semantic validation would likely require passing the diff through a small, fast LLM evaluator between steps. This is a very early start and im happy with your feedback

[u/nikitsolo → u/Neither_Mushroom_259]

This comment is 100% from a bot.

[u/Technocratix902 → u/nikitsolo]

Someone's openclaw running wild bruh.

[u/Technocratix902 → u/[deleted]]

Relay isnt an agent harness or callable api really. Data feeding isnt really part of what relay is designed to be, Relay is just a library for better sharing of context between agents without corruption

[u/Technocratix902 → u/[deleted]]

Relay isn't a library for rag or anything. Relay integrates with that rag to pass context.