Repositories, issues, pull requests, and releases.
Studio engineeringDefault accountready
Connection layer for agents
MirrorConnect accounts once for every agent.
Mirror gives agents approved access to the services you already use. Connect an account once, choose which agents can use it, and review actions before they run.
Start with 30 connections and counting.
30 connections and counting · One account layer · Approval before action
MirrorConnectionsPersonal ⌄Connections
Connect provider accounts once, keep their source records mirrored, and make them available to approved agents.
Documents and shared drives, mirrored for retrieval.
Research workspaceDefault accountready
Channels, threads, messages, and shared files.
Artificial IlluminationDefault accountready
Pages, databases, blocks, and workspace search.
Ready to connect
Issues, projects, cycles, and product roadmaps.
Ready to connect
Saved music, playlists, listening history, and metadata.
Ready to connect
ONE TASK THROUGH MIRROR
A release agent needs GitHub and Slack.
The user connects both accounts in Mirror. The agent sees the approved bindings and can query release changes in GitHub and related discussion in Slack.
If the agent wants to post an update, Mirror records the exact request and asks for approval before it runs.
- 01Connect the accounts
- 02Read the sources
- 03Keep context available
- 04Approve the action
- 05Record the result
01
One connection layer serves every agent.
Users connect and revoke accounts in one place. Agents get the context they need without holding raw provider credentials or rebuilding authentication, sync, and approvals.
02
Accounts stay with the user.
Agents can find ready providers, inspect bindings, query mirrored records, request live data, and sync changes through the same surface.
- ↳OAuth, API-key, CLI, and MCP-backed providers
- ↳Isolated provider and account lanes
- ↳Connection catalog and readiness state
- ↳Revocation and disconnect flows
- ↳Webhook and callback handling
- ↳Per-agent connection declarations
03
Give agents fresh context and reliable history.
Mirror keeps a versioned history of external data. Summaries and normalized views remain linked to the original provider record. Live reads are used when available, with mirrored records for history or fallback.
- ↳Versioned source records
- ↳Live reads with mirrored fallback
- ↳Incremental synchronization and cursors
- ↳Source payload and blob retrieval
- ↳Rebuildable normalized projections
04
Stay in control of what agents change.
Mirror classifies provider tools and sends write-like actions through an approval ledger. The ledger records the exact request and its hash before the action runs.
Agent quickstart
05One interface for every connection.
After binding, an agent can find connections, query records, fetch source payloads, sync accounts, and request actions through the CLI.
mirror providers
mirror query github "release v0.3" --limit 5
mirror read slack --tool mcp.tools.list06
Mirror owns connected context.
Mirror owns provider connections and source records. Provenance records agent activity. Margins and repositories own human-facing files.
QUESTIONS, ANSWERED
What to know before you start.
01Is Mirror another MCP client?＋
Mirror can expose MCP tools, but it also handles provider authentication, account isolation, source mirroring, sync, approvals, and diagnostics.
02Does every agent receive every provider token?＋
No. Mirror owns provider credentials and account lanes. Agents use Mirror instead of receiving raw credentials by default.
03Does Mirror replace Provenance?＋
No. Mirror stores provider context. Provenance stores append-only evidence of agent work.
04Can agents perform write actions?＋
Supported write actions can run after approval. Mirror records the exact request before execution.