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 aren’t always 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 now agents are collaborators too. They can read our repos, tickets, and docs, yet they usually receive only summaries of the conversations that shaped them.

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, you can 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. With Triggers, Tuple can run shell scripts in response to lifecycle events, like call-transcription-complete, participant-joined, and screen-share-started, which opens up a new playing field for automations. One example is having an agent automatically update your knowledge base and task manager from calls. It removes day-to-day toil and has even made it easier to keep up with each other’s personal lives, like birthdays and family members’ names. I’d like to say I can just remember that stuff, but evidence shows I can’t, and this helps me be a better coworker and friend.

You could point one at an agent running headless with something like this, and it just works:

#!/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)."

Now, action items land in your task manager, your knowledge base accrues a note per person and project, and tickets get filed while the context is fresh. Stephen breaks down his setup here.

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.