Skip to content
eddyeddyeddy

eddy is designed, not built. Its design book holds the design whole.

eddy

eddy lists recorded meetings across services with no model running, and keeps each transcript whole for a session to read later.

How it worksRead the designGitHub
eddy: a program lists meetings, a session reads them later Three meeting services, Wispr Flow, Webex and Microsoft Teams, hold recorded meetings. eddy has one part per service. Each part lists its service's meetings and fetches them while the count of model calls stays at zero, and a two-minute check-in is skipped as too short to matter. eddy keeps each other meeting under its key, meeting slash service slash the meeting's id, with the transcript as the service served it and a plain copy with one line per turn. Later, and outside eddy, a Claude session reads one transcript and writes signals through millpond. eddy lists recorded meetings; a session reads them later SERVICES Wispr Flow design review · 48 min check-in · 2 min Webex vendor call · 31 min Microsoft Teams planning · 55 min EDDY · A PART PER SERVICE model calls while listing 0 wispr lists · fetches webex lists · fetches teams lists · fetches skipped: check-in, 2 min SHARED BY EVERY PART the key · the details the raw layout · the skip design review · 48 min check-in · 2 min vendor call · 31 min planning · 55 min CAPTURES · KEYED meeting/wispr/7f3c2a design review · 48 min · 4 people transcript.json as served transcript.txt one line per turn meeting/webex/3d77a1 vendor call · 31 min · 3 people transcript.vtt as served transcript.txt one line per turn meeting/teams/9b1e04 planning · 55 min · 6 people transcript.vtt as served transcript.txt one line per turn eddy ends here A READER · LATER a Claude session reads transcript.txt Ana: export ships Friday Raj: legal needs a week Ana: then the 24th Mei: I'll tell them decision ask signals, written through millpond, never by eddy 1 A part per service lists the meetings recorded there. 2 No model runs. A meeting too short to matter is skipped. 3 Each is kept by its key, the transcript whole. 4 A session reads it later. eddy never does.
eddy: a program lists meetings, a session reads them later Three meeting services, Wispr Flow, Webex and Microsoft Teams, hold recorded meetings. eddy has one part per service. Each part lists its service's meetings and fetches them while the count of model calls stays at zero, and a two-minute check-in is skipped as too short to matter. eddy keeps each other meeting under its key, meeting slash service slash the meeting's id, with the transcript as the service served it and a plain copy with one line per turn. Later, and outside eddy, a Claude session reads one transcript and writes signals through millpond. eddy lists recorded meetings; a session reads them later SERVICES Wispr Flow review · 48m check-in · 2m Webex vendor · 31m Teams planning · 55m EDDY · A PART PER SERVICE model calls 0 wispr webex teams skipped: check-in, 2 min SHARED BY EVERY PART key meeting/<service>/<meeting id> details title · start · length · attendees raw as served, plus one line per turn skip a meeting too short to matter review · 48m check-in · 2m vendor · 31m planning · 55m CAPTURES meeting/wispr/7f3c2a 48 min transcript.json as served transcript.txt one line per turn meeting/webex/3d77a1 31 min transcript.vtt as served transcript.txt one line per turn meeting/teams/9b1e04 55 min transcript.vtt as served transcript.txt one line per turn A READER · LATER a Claude session reads transcript.txt Ana: export ships Friday Raj: legal needs a week Ana: then the 24th decision ask signals, through millpond 1 A part per service lists the meetings. 2 No model runs. A short one is skipped. 3 Each is kept by its key, transcript whole. 4 A session reads it later. eddy never does.

Why

Section titled “Why”

A meeting holds decisions and asks that change a repository’s work. Finding the meetings is arithmetic: which services, since when, how long, under what id. Reading them is judgment. eddy does the arithmetic and leaves the judgment to a session, so no model runs to list a day’s meetings, and a meeting keeps one key however often it is listed.

  1. List

    A part per service lists the meetings recorded there since its cursor and fetches each transcript. No model runs.

  2. Key

    eddy keys each meeting by its service and the meeting’s own id, meeting/wispr/7f3c2a. The same meeting gets the same key from every host and every run.

  3. Keep

    It writes the transcript as the service served it, plus a plain copy with one line per turn, and skips a meeting too short to hold anything.

  4. Read later

    A session reads the transcript later and writes its signals through millpond. eddy never reads a meeting.

Three ways to run it

Section titled “Three ways to run it”

In Claude Code

eddy’s Claude Code plugin pulls a meeting’s transcript into a session, so the session works from what was said.

Beside your panes

eddy’s herdr plugin shows the day’s meetings beside the agents’ panes.

Into the inbox

eddy’s Flywheel plugin holds one part per service. millpond runs each part on a schedule and keeps what it lists, and a reader session turns each transcript into signals.

Services

Section titled “Services”

Each part keys a meeting as meeting/<part>/<meeting id>.

Part Source When
wispr Wispr Flow’s MCP endpoint, as an MCP client with its own sign-in first
webex Webex’s transcripts API when a partition records on Webex
teams Microsoft Graph’s meeting transcripts when a tenant’s administrator consents

Any other service joins as a plugin of its own that passes the meeting checks, and a generic MCP part and millpond’s folder drop take the rest.

How it worksOne part per service, what a meeting becomes on disk, and how others add a service.
How it fitseddy beside headwater, millpond, sluice and Flywheel.

Built in the open by agentplot, under the MIT licence.