Bring your own agent to Tuple

TL;DR

Over the past month, we’ve quietly released a CLI, an MCP server, local transcription, and the ability to connect agents to Tuple calls. Together, they let the agent you already use follow a call live, pick up its full context afterward, or keep your systems up to date automatically.

The context

It increasingly feels like anyone can build anything, which makes deciding what to ship harder and more important. Those decisions happen in Tuple calls, where people weigh tradeoffs, make judgment calls, and reject approaches for reasons that rarely get written down. When a call ends, that context goes with the people who were there.

Tuple has always made those conversations feel like working side by side. But agents are now collaborators too: they can read our repos, tickets, and docs, yet they usually receive only summaries of the conversations that shaped them. They’re left to guess at the gaps.

That asymmetry is why we’ve released this set of composable parts. Together with Triggers, they have made our own experience using Tuple feel quite different. It’s been kinda delightful.

What we deliberately didn’t build

The “obvious” move was a Tuple assistant: our bot in your call, taking notes, sparkle icon and all. We didn’t build that because you already have an agent. Yours is configured, approved by your org, wired into your repos and issue tracker, and you’ve spent months teaching it how you work. A second, Tuple-branded assistant with its own memory and opinions is a worse version of the thing you already have.

So we inverted it. Instead of putting our agent in your calls, we made your calls legible to your agent, and made space for it to join you in real time if that’s what you’re into. Tuple facilitates the call, the agent connection, and the hooks; you bring the agent, whether that’s Claude Code, Codex, OpenCode, Cursor, or anything else your org allows.

What it looks like in practice

There are three categories of use that have emerged from early testing:

During the call. With the MCP installed, just tell your agent “follow along with my Tuple call” and it’ll handle the rest. It can follow the transcript live, wake when someone speaks, and capture the shared screen via the CLI to see what everyone is looking at. On a design review, “hey [agent], update the mock so we can see how it feels” goes from spoken sentence to revised artifact while the discussion continues. And when it needs a yes from you before acting, it doesn’t need to barge into the call audio: tuple notifications ask can post an accept/reject card in the call window and wait for your click.

After the call. You hang up with the task in your head but not your agent’s. “Look at my last Tuple call and pick up the refactor we discussed” pulls the transcript over MCP and starts from the full discussion: who wanted what, and why. tuple connect --call <id> does the same for any past call.

Without you at all. This is one we keep coming back to, even if it is a bit boring. Triggers run scripts on call events like call-transcription-complete, participant-joined, and screen-share-started; point one at an agent running headless:

#!/usr/bin/env sh
# ~/.tuple/triggers/post-call-action/call-transcription-complete
claude -p "Find my most recent Tuple call (tuple transcription list --limit 1),
read its transcript (tuple transcription show <id>), then:
1. extract action items and decisions,
2. append them to today's daily note in my Obsidian vault,
3. update my people notes for each participant with anything new,
4. file any bugs we agreed on as Linear issues,
5. label the call with a short title and summary for later reference
   (tuple transcription set-title / set-summary)."

That’s the whole integration, and it’s about five minutes of setup you or your agent does once. From then on, every call quietly feeds your systems: action items land in your task manager, your knowledge base accrues a note per person and project, tickets get filed while the context is fresh, and every call ends up titled and summarized. Three months in, “what did Priya and I decide about the retry logic?” is no longer an archaeology project. Swap in your own stack, Jira instead of Linear, a markdown folder instead of Obsidian; the trigger doesn’t care. It’s a shell script.

The constraints we set

Three rules shaped the design:

Everything runs on your machine. Pairing calls are sensitive: production debugging, unreleased code, the occasional personal aside. So transcription runs on-device (via Whisper), transcripts land in a local SQLite database, and the control surface is a local HTTP server on a Unix socket. tuple transcription search "connection pool" searches months of call history without a network round trip.

Primitives, not features. We can’t predict your workflow, so we shipped building blocks instead: a CLI that controls Tuple, an MCP server exposing the same surface, the ability to transcribe calls locally, and Triggers. Everything else in this post is a composition of these primitives.

Trust boundaries are explicit. Some of them are structural: the CLI sees nothing until you authorize it, you can revoke that in Settings at any time, and Tuple itself never sends any of it off your machine. What happens after your agent reads a transcript or captures a screenshot is a different boundary: that context goes to whatever model your harness is configured to use, exactly like the code and tickets your agent already reads. Everything else is a default you can inspect and replace. Ultimately, you’re connecting your own agent to calls, so your harness’s permission model has the final say on enforcement.

Getting set up

Open Settings > Transcription, turn on local transcription, download a Whisper model or choose your own, and click once to link the tuple CLI into your PATH and authorize it. Then run tuple connect in a terminal: the first run picks your agent, installs Tuple’s MCP server into it, and launches it with the call’s context. After that, running tuple connect in the terminal is all you need to spin up a new session for an ongoing call. If you aren’t in the terminal, you can instead tell the agent you configured to “connect to my ongoing Tuple call” and it’ll handle the rest via the MCP.

The Raycast test

We’d wanted a Raycast extension for years and never justified the integration work. Once the CLI existed, Stephen, our CEO, built it in about a day by composing the same tuple commands anyone can use: active-call controls, transcript search, contacts, and read-only tools for Raycast AI. It’s on the Raycast store, and the source is on GitHub.

Watch Stephen’s walkthrough of the extension.

That’s the point of these primitives. They don’t just connect agents to calls; they make the ideas that have been sitting in your backlog cheap enough to try.

In closing

This is early, and we’ve called it an alpha release for a reason. There are still plenty of rough edges to work through, and the fact that folks will need this post to understand the possibilities is an example of a clear UX gap. As you find rough edges in your own use, please let us know! The same applies for building new workflows; we want to know what you’re up to and how we might make life easier for you.

If you do only one thing, head to Settings, enable the alpha, and try tuple connect on your next call. We’d love to hear what you think.

If you’re up for one more, join us in the Tuple Community in Slack. You can chat directly with the Tuple team and learn from other folks in the Tuple-verse. We hope to see you there.