John CEO

Inspiration

Most teams already tried the workaround: screenshot a Slack thread, paste it into a chatbot, paste the answer back, open Gmail, paste again. The model never saw what you are allowed to see. Your CRM lived in another tab. And if the agent runs on shared infrastructure, you start wondering whose customer email just trained whose model.

We wanted the opposite - delegate in the channel where work already happens, with answers grounded in your workspace and actions that actually land in the tools you use.

There is a second problem generic chatbots ignore: who was in the room. Alice's DM to John and a #launch thread are different audiences. A real coworker remembers where they heard something. They do not repeat a private confession in a wider group.

What John does

Picture a #launch thread on Monday. You @John to summarize what changed since Friday. Your PM adds a constraint in the same thread without tagging him again. John keeps one shared conversation - the way a human teammate would.

That shared thread is not the same as shared memory. What you told John in a DM stays private to you unless you explicitly promote it for the team. What he learns in #sales stays scoped to that channel - and only reaches someone's DM when we can attest they were already a member there.

Or ask him to draft a follow-up from a customer call: he can pull recent channel context, then create the calendar hold and send the email through apps you connected at john.ceo. Replies stay in Slack; the busywork happens behind the scenes.

Each company runs on its own private workspace. Your threads, memory, and files do not mix with anyone else's.

How we built it

John for Slack is a Marketplace agent on the HTTP Events API - no Socket Mode. A message to @John becomes a job on our platform, runs on that organization's dedicated agent, and comes back as a thread reply from John.

Under the hood we wired the three technologies this hackathon rewards together:

• Slack AI for the Assistant surface, thinking status, and App Home connections.
• Real-Time Search API so John can ground answers in workspace context before he speaks.
• MCP twice: Slack's MCP server for search and summaries inside Slack, plus MCP connections to business apps (Gmail, Calendar, CRM, and hundreds more).
• Structural memory enforcement. Audience-scoped memory uses separate stores per scope (DM, channel, team-wide). We run automated leak tests in CI - e.g. a fact learned in a private DM must never surface in a channel reply - so isolation is enforced by policy and tests, not prompt politeness.

The agent reads and writes persistent storage in the private workspace (chat history, audience-scoped long-term memory, files). Customer-selected LLM providers handle inference. Voice notes are transcribed so async updates work from a phone walk-and-talk.

What we learned

The hardest UX problem was not intelligence - it was social timing. In a busy channel John must know when a thread is a delegation to him versus background chatter he should ignore.

Shared thread sessions changed the product feel entirely. Once teammates could add context without re-@mentioning, John stopped feeling like a bot and started feeling like staff.

Real-Time Search action tokens in Assistant DMs were a quiet win: grounding quality jumped when John could search with the installer's own visibility, not a super-bot view of the workspace.

Memory is a permissions problem, not a search problem. Collaborative threads need shared chat history. Long-term memory needs the opposite discipline. If Alice tells John a margin number in a DM, that fact must not show up when Bob asks in #sales. John tracks where something was learned and only recalls it for people who were allowed to hear it there. Private DM memory stays in DM. Channel memory stays in that channel. Nothing becomes team-wide unless the sponsor confirms it in a second step.

Challenges

Trust at two layers. Customers want isolation (one private workspace per org) while Slack permissions stay tied to the installing user. John posts as @John, but search and MCP run with your grants - designing that split took iteration.

Selective memory in shared Slack. Thread collab and memory scoping pull in opposite directions: teammates share one conversation in a channel, but durable facts must respect audience. Channel knowledge can widen to a DM only when our bridge attests overlapping membership. Team-wide facts require an explicit two-step confirmation - saying "remember this for everyone" is not enough on its own.

Shipping a Marketplace agent on a hackathon clock. HTTP Events, OAuth, privacy copy, and a demo that shows real delegation - not slides - while the submission window was still open.

What's next

Tighter promotion UX when someone wants to share a private fact with the whole team. Living briefings in Canvas and scheduled summaries posted where the team already looks. Continued hardening as customers add more channels and DMs.

Built With

• cloudflare
• composio
• drizzle
• hetzner
• hono
• mcp
• node.js
• react
• real-time-search-api
• slack
• slack-agent-builder
• slack-ai
• typescript