Relay

• 

  Relay-Architecture

Inspiration

Engineering teams lose a huge share of their week to coordination, not code: chasing PR reviews, updating tickets, writing standup notes, and re-answering "what did we decide about X?" in Slack. We noticed that every Slack AI agent we had ever used shared the same limitation: it only does something when you @mention it. It is a smarter command line, not a teammate. We wanted an agent that watches the work happening around it and acts on its own, the way a good colleague would.

What it does

Relay is an event-driven Slack agent for engineering teams. It reacts to real events, no @mention required:

• Proactive PR to Jira sync. When a pull request is merged, Relay posts a plain-English summary of the diff to the channel and moves the linked Jira ticket to Done, with no one asking it to.
• Answers from your history. Ask a question and Relay uses Slack's Real-Time Search API (search.messages) to find the relevant decision in your chat and answer it, cleanly formatted with sources.
• Semantic memory (RAG). Save runbooks and docs with /relay save, or just drop a file in a channel. Relay embeds them and answers questions that share no keywords with the source, using pgvector similarity search.
• Pre-standup briefs. Each developer gets a DM before standup summarizing their open PRs, assigned tickets, and unresolved mentions.
• Stale-PR nudges. Relay pings the right reviewer when a PR is going stale and offers one-click actions ("I'll review this next", "I can't", "Snooze").
• Handoff canvas and weekly health digest. End-of-day and weekly summaries of open PRs, blocked tickets, and team throughput.

How we built it

Relay is a TypeScript service deployed on Railway. Events arrive three ways: GitHub webhooks (PR and CI events), Slack events (mentions, slash commands, and file uploads), and scheduled cron jobs (standup, nudges, handoff, digest). A Hono HTTP server verifies every request (HMAC signatures for both Slack and GitHub), then hands work to a BullMQ queue on Redis with a dead-letter queue for durability, so a slow model call or a flaky integration never drops an event.

Four feature workers do the reasoning: ticket sync, Q&A and memory, review ops, and briefs and insights. Under them sit the integrations: OpenAI (gpt-5.5 for reasoning plus text-embedding-3-small for retrieval), Supabase (Postgres and pgvector for data and semantic memory), the GitHub API (diffs, CI status, OAuth), the Jira REST API (transitions and comments), and the qualifying technology, Slack's Real-Time Search API. Everything is delivered back as Slack Block Kit cards, canvases, and DMs.

Challenges we ran into

• Eligibility done right. A Slack bot token cannot call search.messages. We had to wire a user token with the search:read scope and scope every query to the demo channel with the in:<#CHANNEL_ID> modifier, then fall back to keyword search when no user token is present.
• Making the proactive card actually show. The merge summary was being computed but the Slack blocks were dropped before posting. Tracking that down meant following one event from webhook to queue to worker to the Web API call.
• Real workflows, not mocks. Jira transitions depend on the project's actual workflow, so we verified the live path (To Do to In Review to Done) end to end against a real board rather than trusting a happy-path assumption.

Accomplishments that we're proud of

• A genuinely proactive agent: the headline demo has nobody typing to the bot.
• The whole pipeline is verified live, not simulated. A real PR merge flips a real Jira ticket and posts a real card, end to end, on the deployed backend.
• Strong engineering hygiene: strict TypeScript, a dead-letter queue, HMAC verification on every inbound request, and a broad automated test suite.

What we learned

Event-driven beats request-driven for team tooling. The value is not a better answer to a question you remembered to ask; it is the update, the nudge, and the summary you would otherwise have had to chase. We also learned how much of a "smart" agent is really careful plumbing: idempotency, signature checks, retries, and graceful degradation when an integration is down.

What's next for Relay

Deeper calendar-aware scheduling, incident summaries from monitoring webhooks, per-workspace onboarding polish, and upsert and dedup for the document store so long-running memory stays clean at scale.

Built With

• block-kit
• bullmq
• embeddings
• github-api
• github-webhooks
• google-calendar-api
• gpt-5.5
• hono
• jira-rest-api
• node-cron
• node.js
• oauth
• octokit
• openai
• pgvector
• postgresql
• railway
• redis
• rest-api
• slack-api
• slack-bolt
• slack-real-time-search-api
• supabase
• typescript
• webhooks