Relay — Meeting-to-Action Agent

Paste a meeting transcript. GPT-5.6 extracts the decisions and action items. You approve. Relay files them into Slack, Linear, and Notion — automatically.

Comment

Inspiration

(This is the one section I genuinely can't write for you — why did you personally care about this problem? A specific meeting where an action item got dropped? A team you're on that's bad at follow-through? Devpost readers respond to a real, specific moment far more than a generic "meetings are inefficient" line.)

What it does

Paste a raw meeting transcript. GPT-5.6 extracts decisions, action items (owner, due date, priority), and open questions — each one grounded to the exact transcript line it came from. Nothing is filed until you review and approve it. Confirm, and it posts a recap to Slack, creates one Linear issue per action item, and writes a full meeting-notes page in Notion — live, not a mockup.

How we built it

  • Backend: FastAPI + a small Python package (relay/). Frontend: a single HTML file, no build step.
  • GPT-5.6 handles the one step that needs real reasoning: unstructured transcript → structured JSON (via structured outputs / JSON schema).
  • Filing (Slack/Linear/Notion) is deterministic, direct API calls, not an LLM in the loop — more on why below.
  • Model provider is swappable: OpenAI directly, or OpenRouter (so the app works on free models too).

What we learned

  • The instinct to route everything through an LLM agent is wrong when the data is already fully structured. An agent is for judgment calls; filing an approved record has none left to make.
  • Free-tier models are meaningfully worse at multi-step tool-calling than at single-shot structured extraction — the gap is bigger than we expected.
  • Notion's page-creation API is strict about nested block shapes (typed unions, parent must be an object) — a good stress test for any model's structured-output reliability.
  • "The agent said it succeeded" and "it actually succeeded" are not the same claim, and you have to verify the second one independently.

Challenges we ran into

  • Live-tested three different models (including a 550B one) for the filing step. All three failed differently: one returned "success" after calling zero tools; one completed only 2 of 5 Linear issues before garbling; the biggest one made 8 different malformed attempts at Notion's block schema before hitting the tool-call limit.
  • Caught a real correctness bug because of this: the app was reporting "filed" any time the agent didn't throw an exception — even when it had created nothing. Fixed by verifying actual API responses instead of trusting the agent's summary.
  • The fix that actually worked: since the approved record is already structured JSON, we rewrote Slack/Linear/Notion filing as direct, deterministic API calls instead of agent-orchestrated ones. That fixed reliability and a garbled/mixed-language text bug in Slack messages, in one move.
  • [Add your own: anything about OAuth/token setup, Windows-specific quirks, or the actual Codex session that gave you trouble worth mentioning.]

Built With

  • codex
  • css
  • fastapi
  • gpt-5.6
  • graphql
  • html
  • httpx
  • javascript
  • json-schema
  • linear-api
  • mcp
  • node.js
  • notion-api
  • openai
  • openai-agents-sdk
  • openrouter
  • pydantic
  • python
  • rest-api
  • slack-api
  • uvicorn
Share this project:

Updates