Introducing Relay: autonomous PRs from labeled issues.

A week after we shipped Cascade to PyPI, the second project on our open-source roadmap deserves an introduction. Relay is the autonomous-CI counterpart to Cascade. Where Cascade walks you through review gates (story review before code, PR review before merge), Relay runs hands-off from a label on an issue to a tested PR waiting for your review.

Drop one workflow file in your repo. Label any issue with relay. The agent reads the issue, plans the changes, writes the code, writes the tests, runs them, and opens a PR. You merge or close. That is the whole loop.

The repo is on GitHub today at Thinknext-Software-Solutions/Relay. The README describes the intended developer experience. No functional code has been written yet. Target for v0.1 is 2026-07-19.

Why two products, not one

Cascade and Relay solve adjacent problems. Different teams hit each one harder; some teams need both. Here is the split:

	Cascade	Relay
Entry point	Meeting recording, tracker ticket, or one-line prompt	A labeled issue in your tracker
Where it runs	Your laptop or CI, on demand	Your CI, triggered by the label
Human gates	Story review BEFORE code; PR review BEFORE merge	PR review BEFORE merge
Best for	Fuzzy requirements that need deliberation	Well-scoped backlog tickets, autonomy
Status	Alpha, live on PyPI	Pre-alpha, target 2026-07-19

Pick Cascade when you want to think about the work before code gets written. Pick Relay when the work is well-defined and you want it ticked off without context-switching. Use both if your team's work spans both shapes.

The "runs in your CI" part is the whole point

The autonomous-AI-agent space is crowded. Devin, Sweep, Cosine, several other entrants. What makes Relay different is the same thing that makes Cascade different: it runs on your infrastructure with your LLM key, and your code never leaves your org except to the LLM provider you explicitly configured.

For teams in regulated industries (financial services, healthcare, government, defense), the SaaS-only agents are non-starters. The legal team will not sign off on sending source code to a third-party service no matter how clever the marketing deck is. Relay is for those teams. Drop a workflow file in your existing GitHub Actions / GitLab CI / Bitbucket Pipelines / Azure Pipelines, and the agent runs where your code already runs.

v0.1 ships GitHub Actions only because that is where ~80% of teams are. The other three CI systems land in v0.2 and v0.3:

CI runtime	Triggered by	Opens	Target
GitHub Actions	relay label on a GitHub issue	GitHub PR	v0.1 (2026-07-19)
GitLab CI	relay label on a GitLab issue	GitLab MR	v0.2 (Q4 2026)
Bitbucket Pipelines	relay label on a Bitbucket issue	Bitbucket PR	v0.2 (Q4 2026)
Azure Pipelines	relay tag on an Azure Boards work item	Azure DevOps PR	v0.3 (Q1 2027)

LLM providers mirror Cascade's matrix: Anthropic, OpenAI, Google Gemini, Claude Code SDK, Ollama. Languages mirror Cascade's eight built-in profiles. The underlying agent loop is shared code; the difference is the orchestration layer.

Why building it autonomous is harder

Cascade has a deliberate human-in-the-loop posture for a reason: the cheapest place to fix an AI misinterpretation is before code gets written. Story review catches "you misunderstood the requirement" in 30 seconds. PR review catches "you understood the requirement but wrote the wrong code" in five minutes.

Relay drops the first gate. The PR is the first place a human reviews anything. That makes Relay harder to ship responsibly than Cascade. We need the plan-code-test-self-review loop to be tight enough that the resulting PR is actually worth a human's attention, not noise. A bad Relay run is worse than no Relay run.

The way we are mitigating: a five-stage internal pipeline where each LLM call has one focused job (planner, coder, tester, reviewer, PR opener). The reviewer stage is the new one relative to Cascade; it self-critiques the diff before opening the PR. If the reviewer flags anything substantive, Relay declines to open a PR and leaves a comment on the issue explaining why.

What we are NOT building (on purpose)

A few deliberate non-goals, so expectations stay calibrated:

• No hosted version. Not now, not later. Relay is self-hosted. If you want hosted, fork it. The whole point is your code staying on your infrastructure.
• No merging. Ever. Relay opens PRs; humans merge. There is no "auto-merge on green tests" mode. We considered it and decided no.
• No multi-issue planning. v0.1 handles one labeled issue at a time. If you label five issues, Relay processes five independent runs. Coordination across issues is v0.3+ territory.
• No code review beyond self-critique. Relay does not review your team's existing PRs. It opens new ones. Reviewing other PRs is a different product.
• No model finetuning. We use foundation models as-is. No data is sent anywhere we can train on. Your prompts are your prompts.

How to follow the build

• Star and watch the GitHub repo. We will tag every milestone release.
• File issues and feature requests at github.com/Thinknext-Software-Solutions/Relay/issues. We are paying close attention to what early followers ask for; it shapes v0.1 priorities.
• Read the README for the intended developer experience and the full security model.
• Subscribe to this blog (no actual mailing list yet; bookmark /blog/) for the v0.1 launch post.

One thing to think about between now and July

If you are on a team where issues pile up faster than they get worked, ask yourself: which of your tickets are well-defined enough that you would trust an agent to take a first pass? If the answer is "more than zero," Relay is for you. If the answer is "none, our tickets are all underspecified," then the problem to solve is your tickets, not the tool. Cascade may be the better fit there.

Either way, thanks for reading. We will write the next post when v0.1 ships.

---

Relay is built by ThinkNext Software Solutions alongside our flagship Cascade. We are an AI-augmented engineering and staffing firm. We use AI at every step of the SDLC and ship the tools we use ourselves.