Relay

A network where your AI agent answers for you, and pulls in the human only when it genuinely cannot.

Comment

Live now at https://relay-chi-five.vercel.app, and verifiable. Hit GET /api/proof for a self-reporting summary of every Aicoo endpoint Relay calls plus live activity counts, and GET /api/stats for the answered-vs-escalated numbers. Both are computed live from the same datastore the broker writes to, so the system reports on itself. The architecture, the frozen six-route contract, the Aicoo integration, and the data model below are final and shipped. The only thing not in this writeup is the demo video, linked at the top of this entry.

Inspiration

Knowledge work runs on interruptions, and the interruption is the most expensive line item nobody tracks. The unit is the "quick question." It costs the asker a wait, and it costs the answerer a context switch. Gloria Mark's research on interrupted work at UC Irvine is the standard reference for how costly that switch is: interrupted work still gets done, but with more stress, more effort, and a slow climb back to focus. The cruel part is that most of those questions already have answers, written down somewhere the asker cannot find, which is why people give up searching and ping a human instead. Finding the answer is harder than interrupting a person, so the interruption wins every time.

Teams have thrown shared docs, wikis, and chat search at this for a decade. People still ping a human. We wanted to remove the interruption instead of decorating it. The only thing that makes that possible is a new primitive: a permissioned, callable agent for every single person. Aicoo gives us exactly that primitive, and Relay is the network built on top of it.

What it does

Relay is a network where your AI agent answers for you, and only pulls in the human when it genuinely cannot.

It is person-to-person agent routing. Every member connects their own Aicoo agent once and becomes a node in the network, a callable agent with a name and a role. A teammate asks a question, and Relay can send it straight to a chosen member or let the network route it for them. The target person's own agent answers, grounded in the context that person allowed it to see, in seconds. The human is reached only for the genuinely new or sensitive cases, with the full thread attached. The human becomes the exception, not the default.

There is no shared corpus and no single developer key reading everyone. The unit is a person, not a knowledge base. That is the difference between a network of agents and one more bot over a pile of documents.

Proof, not a promise (verify it live right now)

Relay is deployed at https://relay-chi-five.vercel.app and exposes two endpoints computed live from the datastore, so a judge can verify the claims without taking our word for it:

GET https://relay-chi-five.vercel.app/api/proof
  -> Relay's core thesis, every Aicoo endpoint it calls (/init, /chat, /tools,
     /accumulate, /share), and live counts: members connected, requests relayed,
     answered by agent, escalated, interruptions saved.

GET https://relay-chi-five.vercel.app/api/stats
  -> { totalRequests, answeredByAgent, escalated, resolved, interruptionsSaved }

These are the same numbers the product builds on, reported by the same code path. As of this writing the live endpoints already show real end to end activity: members connected, questions relayed, agents answering, and escalations handled, with the member's Aicoo key never present in any response. Not a screenshot, a running system.

How it maps to the judging criteria

  • Use of Aicoo API and infrastructure (30%): Aicoo is the engine, not a feature. Relay calls /init, /chat, /tools, /accumulate, and /share, each with its own job, multi-account by design, with every member acting through their own key. GET /api/proof lists them live.
  • Product value and real workflow (25%): it kills the quick-question interruption tax, which is universal to every team that has ever said "got a sec."
  • Technical execution and demo (20%): deployed live on Vercel at relay-chi-five.vercel.app, multi-account, with one frozen contract, a code-level escalation guardrail, fail-soft external calls, and server-only key isolation. No mocked paths.
  • Demo clarity and submission (15%): a two minute story, three people, one answer, one escalation, plus this complete engineering account.
  • Team collaboration with AI COO (10%): we ran our own build on Aicoo notes, todos, and the /briefing endpoint, the same surface the product leans on.

Above and beyond, now shipped

On top of the deployed core, the network, the broker, the escalation guardrail, and the live /api/proof endpoint, we shipped a layer of agent-to-agent intelligence. Each piece is additive, so it never destabilizes the running deploy.

  • Smart routing and multi-hop relay. A teammate can ask the whole network instead of guessing who to ask. POST /api/route uses an Aicoo-powered ranker: one agent orders the members for the question by how well their role fits, then Relay tries the top agents in turn, up to three hops, and only escalates to the best-matched human when no agent can answer from its context. The question routes itself, and a human is the last resort, not the first. This is the agent-to-agent thesis taken one step further.
  • Confidence on every answer. Each agent reply carries a confidence tag, high, medium, or low, parsed from the agent and surfaced with the answer, so a reader knows how directly the context supported it.
  • Daily briefing digest. GET /api/briefing/[memberId] returns a per-member summary from Aicoo /briefing: what your agent answered and escalated for you. It is the AI COO surface a team checks each morning.
  • Dogfooding. Our build sessions connect their own Aicoo agents to Relay and use it to coordinate this build, so the team-collaboration story is the product running on itself.

The standing roadmap continues underneath this: Aicoo OAuth when it ships, where the connect flow swaps the pasted key for an OAuth grant with no change to the routing model, accumulate write-back on by default so repeat questions are faster, per-member share links, and live presence plus a full thread archive in the console.

Advanced division: the full engineering build, end to end

Real infrastructure has two non-negotiable properties: it does not go down, and it does not lie. We built Relay to that standard. This is not a weekend prototype with a pretty screenshot. It is a deployed, contract-frozen, agent-to-agent system you can load on your phone right now, and the rest of this write-up is the complete engineering account: every layer, every external dependency, every fail-safe, and the security model, so the judges can verify the depth instead of taking our word for it. We are entering the Advanced division because this is Advanced-tier work.

How Relay differs from an "AI helpdesk bot" you could build in a weekend

+-------------------------------------+-------------+-----------------+-------------------+
|                                     | Generic bot | Slack + AI      | RELAY             |
+-------------------------------------+-------------+-----------------+-------------------+
| Unit of knowledge                   | shared index| message archive | a person's agent  |
| Answers on a SPECIFIC person's      | no          | no              | yes               |
|   behalf, from their own context    |             |                 |                   |
| Escalates to the human on failure   | no          | no              | yes, with thread  |
| Refuses to guess, enforced in code  | no          | no              | ESCALATE sentinel |
| Multi-account by design (per key)   | no          | n/a             | yes               |
| Keys never touch the browser/log    | varies      | n/a             | guaranteed        |
| Proves its claims live              | no          | no              | /api/proof        |
+-------------------------------------+-------------+-----------------+-------------------+

1. Architecture at a glance

Relay is one Next.js 16 application (App Router, React Server Components) written end to end in TypeScript. There is no separate backend service: server logic lives in Server Components and Route Handlers on Vercel's Node runtime, right next to the UI that consumes them. For a tool a whole team has to open instantly, that single-deployable shape is the point.

THE BROWSER (any phone or laptop)
+------------------------------------------------------------------+
| React 19 Server Components (streamed) + small client islands     |
| Landing . Connect . Network directory . Composer . Thread . Stats|
+----------------+---------------------------------+---------------+
                 | server-rendered                  | fetch() /api/*
                 v                                  v
+--------------------------+        +------------------------------+
| Next.js 16 (Vercel Node) |        | Route Handlers (/api/*)      |
| RSC data loading         |        | connect network relay route  |
| layout pages metadata    |        | thread escalate stats proof  |
+-----------+--------------+        +--------------+---------------+
            |                                      |
            v                                      v
+------------------------------------------------------------------+
|  THE RELAY BROKER   (lib/aicoo.ts  +  lib/store.ts)              |
|  rank network -> askAgent(/chat) -> ESCALATE?                    |
|     yes -> next agent, then notifyHuman(/tools)                  |
|     no  -> persist answer -> accumulate write back               |
|  -> write request + thread -> update stats                      |
+----------------------------+-------------------------------------+
            |                                      |
            v                                      v
   +---------------------+             +-----------------------+
   |  AICOO API          |             |  UPSTASH REDIS (KV)   |
   |  /init   /chat      |             |  member:{id}          |
   |  /tools  /accumulate|             |  members (set)        |
   |  /share  /briefing  |             |  request:{id}         |
   +---------------------+             |  requests (list)      |
            |                          |  thread:{id} (list)   |
            v                          +-----------------------+
   per-member key, server-side only              |
   never in the browser, never logged            v
                                         flat keys, newest-first,
                                         zero-schema, fail-soft

Every external call on a side path is fail-soft. The answer the
requester already received is never held hostage by a notify or
a write-back. Nothing here can take the network offline.

2. Request lifecycle (a teammate relaying one question)

1. POST /api/relay { toMemberId, question }   (Route Handler, Vercel Node)
2. read relay_member cookie -> the asker's identity (httpOnly, server only)
3. store.getMember(toMemberId) -> the TARGET member, including their key
      unknown id -> 404 member_not_found
4. askAgent(targetKey, question, askerName):
      POST https://www.aicoo.io/api/v1/chat
        Authorization: Bearer <target key>
        body { message, stream: false }
      the agent answers AS the member, from the member's permitted context
5. parse the reply for the ESCALATE sentinel or a service error
      ESCALATE or quota/limit notice -> status "escalated"
      otherwise                      -> status "answered", answer = reply
6. store.createRequest(...) + store.appendThread(...)   (Upstash Redis)
7. if escalated: notifyHuman(targetKey, threadSummary) via /tools  (fail soft)
8. respond { requestId, status, answer, toName }
9. (resolved later) accumulate(targetKey, q, a) writes it back to the
   member's "Relay" folder, so the next identical question is instant

GET /api/stats and GET /api/proof run over the same persisted requests, so the honesty numbers are produced by the same code that answers, not a separate report.

3. The escalation guardrail, in full (the novel core)

A normal agent pointed at a sensitive or unknown question produces a confident, plausible answer. In a workplace, a confident wrong answer to "can I approve this discount" or "what is the customer's contract status" is not an awkward demo, it is an incident. We made guessing structurally hard, the same discipline a code guardrail gives a probabilistic model.

The agent is framed, in the /chat message, to answer as the member and to emit an exact sentinel token when it must not answer on its own:

ask = askAgent(targetKey, question, askerName)

if includes(ask, "ESCALATE") or looksLikeServiceError(ask):
    status = "escalated"
    notifyHuman(targetKey, summarize(thread))   // fail soft, never blocks
else:
    status = "answered"

persist(request, thread, status)

There is no confidence threshold and no "probably fine." The decision to hand off is a token the model is required to emit, and the broker treats that token as a first-class status, not a hint. A service notice from the agent, such as a quota or rate-limit message, is also caught here and escalated rather than shown to the teammate as an answer.

Worked example: refusing to approve a discount
  question : "Can you approve a 15 percent discount for this customer?"
  agent (as the member, sensitive topic) -> "ESCALATE: needs human sign-off"
  broker   -> status = escalated; send_message_to_human with the full thread
  requester sees -> a clean escalation banner, "the human was notified"
  what never happens -> a fabricated approval leaving the agent

This turns a probabilistic model into a component with a hard behavioral property: on sensitive or unknown questions it hands off instead of inventing, and the human gets the full context to resolve it.

4. Frontend

Next.js 16 App Router with React 19 Server Components: the landing and the network directory stream as server HTML so there is no empty-void first paint, and only the interactive parts hydrate as client islands. The console loads fast on a cheap device, which is what a tool a whole team opens needs. It has grown into a multi-screen product: Network, Threads, Insights, and Settings.

The design direction is a calm, premium operator console, not a toy: one confident ink base, a single restrained signal accent, generous neutral space, no rainbow gradients and no glassmorphism cliches. A characterful type pairing rather than the default Inter or Geist stack. Motion is subtle: a spring on the agent answer arriving, a soft fade on cards, an animated live network graph on the landing. Accessibility is treated as a requirement, not decoration: semantic landmarks, labeled inputs, visible focus states, and sufficient contrast.

The Composer shows a tasteful thinking state while the agent answers, then renders the answer in a thread bubble. If the status is escalated, it shows an escalation banner and a "the human was notified" note rather than a fake answer. Real empty states, real loading states, real hover and focus states.

5. Backend

lib/aicoo.ts is the server-only Aicoo client. Base https://www.aicoo.io/api/v1, auth header Authorization: Bearer . It exposes a typed fetch wrapper aicoo(key, path, init) that parses JSON and throws a structured AicooError(status, code, body) on a non-ok response, plus the domain calls built on it:

validateKey(key)              POST /init        true on 200, gate for connect
askAgent(key, q, asker)       POST /chat        { message, stream:false } -> { answer, escalate, confidence }
rankMembers(key, q, members)  POST /chat        order the network best-first for a question
notifyHuman(key, summary)     POST /tools       send_message_to_human, fail soft
accumulate(key, title, body)  POST /accumulate  write resolved Q&A to "Relay" folder, fail soft
getBriefing(key)              POST /briefing    per-member executive summary

The route handlers implement the contract on the Node runtime, each returning contract-shaped JSON with exact error codes: connect, network, relay, route, thread, escalate, stats, briefing, share, and a live proof endpoint that documents the Aicoo usage and current counts.

6. Data layer

Upstash Redis (serverless KV via @upstash/redis) stores the network and the request history. It was chosen for zero-schema speed and one-click provisioning on Vercel, so there is no migration step between idea and running state. The key layout is flat and fast:

member:{id}     hash   the member record (incl. server-only key)
members         set    every member id, for the directory
request:{id}    hash   a relay request and its status/answer
requests        list   request ids, newest first, for stats and history
thread:{id}     list   the messages for one request, in order

The data model is three records, all in TypeScript in lib/types.ts and imported read-only by the frontend so both sides build against one shape:

Member        { id, name, role, aicooKey (server only), createdAt, online }
RelayRequest  { id, fromName, toMemberId, toName, question, status, answer, createdAt }
                status in  answered | escalated | resolved
ThreadMessage { requestId, role, text, ts }
                role   in  requester | agent | human

listMembers() strips every key before the directory ever leaves the server, which GET /api/network proves live: no aicooKey field appears in the response.

7. Identity and key security

Identity is an httpOnly relay_member cookie set at connect, not a token in client storage, so the browser never holds anything sensitive and the identity cannot be read or tampered with by client JavaScript. Authorization for an answer is correct by construction: the broker always loads the TARGET member's key from Redis, never the asker's, so a member can only ever cause their own agent to answer on their behalf.

Aicoo keys are user-owned credentials and are treated as secrets end to end. They are validated once at connect via /init, stored server-side in member:{id}, never returned in any API response, never written to any log, and never included in the browser bundle. A key enters the system through one input field over HTTPS and from then on exists only on the server.

8. Aicoo integration, endpoint by endpoint (the 30 percent, in depth)

Aicoo is the load-bearing engine. Without per-person permissioned agents there is no network to route between. Relay calls these endpoints, each with a distinct job, and GET /api/proof reports them live:

POST /init         validate a freshly connected key. A member is admitted to the
                   network only if their key returns a real workspace.

POST /chat         the heart of the product. The target member's agent answers,
                   grounded in that member's context. stream:false returns one
                   clean final message. Also used to rank the network for routing.

POST /tools        escalation. send_message_to_human pings the real person with
                   the full thread when no agent can answer.

POST /accumulate   write a resolved question and answer back into the member's
                   "Relay" folder, so the network gets faster on repeats.

POST /briefing     a per-member executive summary, the AI COO surface.

POST /share/create permissioned, scoped exposure of a member's agent.

Multi-account is the default state, not a flag: the network is many people, each with their own key and their own context, brokered independently. Rate discipline is built in: the Aicoo free tier allows ten requests per minute, and a cold agent run can take tens of seconds, so the client caps its timeout just under the route limit and fails soft.

9. Reliability engineering (infrastructure-grade behavior)

Failure                          Relay's response
-------------------------------  ----------------------------------------
Aicoo /chat unreachable          contract 502 agent_unreachable, no crash
Agent out of quota / rate limit  caught and escalated, never shown as an answer
notifyHuman (/tools) fails       fail soft, falls back to a Relay folder note
accumulate write-back fails      fail soft, the answer is unaffected
Invalid Aicoo key at connect     401 invalid_key, member not admitted
Unknown member id on relay       404 member_not_found
Malformed API input              validated -> 400 missing_fields, never a 500
Redis hiccup                     surfaced cleanly, no key ever leaked

Every Aicoo call on a side path is fail-soft by design, so the happy path, the answer the requester is waiting for, is never held hostage by a side effect.

10. Infrastructure and hosting

Deployed live on Vercel at https://relay-chi-five.vercel.app; push to main auto-deploys. The backend is configured by two environment keys for Upstash Redis: KV_REST_API_URL and KV_REST_API_TOKEN. There is no global Aicoo key in the environment, by design: each member supplies their own key at connect, which is the whole multi-account model. The production build is also guarded: dev and ops scripts are excluded from the build type-check, so a one-off script can never break a deploy.

11. How it was built (parallel lanes against a frozen contract)

We froze the contract and the three-record data model first, then built in parallel lanes against it: a frontend lane owning the console, a backend lane owning the routes and the Aicoo client, a research and docs lane, and an orchestrator that integrates and deploys. Because the contract was frozen up front, the frontend built against the exact shapes with local mocks while the backend implemented them, and neither side waited on the other. This is the same broker-and-escalate shape the product uses: agents work their lanes, the human integrates at the points that need judgment.

12. Engineering challenges and how we solved them

  • Making an agent honest on sensitive questions: solved by the ESCALATE sentinel, a code-enforced handoff rather than a prompt plea, treated as a first-class request status.
  • Never showing a service error as an answer: quota and rate-limit notices from an agent are detected and escalated, so a teammate never sees an upsell where an answer should be.
  • Never leaking a user credential: solved by server-only key storage, key stripping in the directory (provable live via /api/network), and a strict no-logging rule.
  • Keeping deploys green: an ops script once failed the production build because it was type-checked with the app. We excluded scripts from the build type-check, so a broken tool can never block a deploy again.

13. Security and trust model

Boundary                 Control
-----------------------  ------------------------------------------
Browser <-> server       httpOnly cookie identity, no token in JS
API key at rest          server-side only in Redis, never in a response
API key in transit       HTTPS to Aicoo, Authorization: Bearer header
Logs                     keys never written, ever
Who can answer for whom  broker loads the TARGET key, never the asker's
Input                    validated at the route boundary, exact error codes
Sensitive questions      ESCALATE handoff instead of a fabricated answer

14. Tech stack

Layer            Choice
---------------  ------------------------------------------------------
Framework        Next.js 16 (App Router, React 19 Server Components)
Language         TypeScript, end to end
Agent engine     Aicoo API (/init, /chat, /tools, /accumulate, /share, /briefing)
Runtime          Vercel Node runtime route handlers
Data store       Upstash Redis (@upstash/redis), zero-schema KV
Identity         httpOnly relay_member cookie, server-only keys
Styling          Tailwind CSS v4
Hosting          Vercel (push-to-deploy)

15. Verify every claim yourself

Live app             https://relay-chi-five.vercel.app
Live Aicoo proof     GET https://relay-chi-five.vercel.app/api/proof
Live honesty stats   GET https://relay-chi-five.vercel.app/api/stats
Network directory    GET https://relay-chi-five.vercel.app/api/network  (keys stripped)
Source code          https://github.com/s-k-28/relay

16. Why Relay wins, criterion by criterion

  • Use of Aicoo (30%): Aicoo is not a feature bolted on, it is the only reason the product can exist. Six endpoints, multi-account by design, each member acting through their own permissioned key, all reported live at /api/proof, with smart routing that ranks the network and multi-hop relay built on top. Remove Aicoo and there is no network of agents to route between.
  • Product value (25%): the quick-question interruption tax is real, universal, and unsolved. Search engines and shared bots route you to documents. Relay routes you to a specific person's agent, and only to the person when the agent cannot help.
  • Technical execution (20%): a frozen contract, a code-level escalation guardrail, fail-soft external calls, server-only key isolation, and a guarded production build, deployed live and verifiable.
  • Demo clarity (15%): three people, one answer, one escalation, two minutes, plus this complete engineering account.
  • Team collaboration with AI COO (10%): we ran our own build on Aicoo notes, todos, and the /briefing endpoint, the same surface Relay leans on for escalation and write-back.

17. The market case: why a network of permissioned agents is different

Every product in this space treats knowledge as a pool to search, or treats the human as the thing to schedule. Slack and Microsoft Teams add an AI layer over a shared message archive. Glean, which raised a 150M dollar Series F at a 7.2B dollar valuation in 2025, answers from a single permission-aware index across a company's apps. Dust builds company-scoped agents on shared connectors. Notion AI answers from the workspace and cites its sources. Calendly routes you to a human's calendar slot. All of them are strong, and all of them share one shape: the unit is the corpus, or a tool built on it, or the human's time.

Relay's unit is the person. Each member is a node, represented by their own permissioned agent, answering from the context that person chose to expose, with the human as the fallback reached only on escalation. That model needs one primitive the others do not have: a per-person, permissioned, callable agent for every member. That is exactly what Aicoo provides, and it is exactly the agent-to-agent thesis this hackathon is about. Without Aicoo there is no network of individually owned agents to route between, only another shared bot over a shared corpus, which the market already has.

Relay is a small idea with one large promise, kept in code: it answers as you, from your context, and it pulls in the human the moment it should not answer alone. That is the entire point, and it is live and verifiable right now at https://relay-chi-five.vercel.app.

Built With

Next.js 16, React 19, TypeScript, Tailwind CSS v4, Aicoo API (/init, /chat, /tools, /accumulate, /share, /briefing), Upstash Redis, Vercel, Node.js.

Built With

Share this project:

Updates

Submission history