Skip to content
Recued
Menu

How Recued works

Recued is the local control plane between any AI, the people who reach you, and the accounts and data on machines you own. Agents and people ask; Recued checks the contract, shields personal data, asks for approval when needed, acts locally, and writes the result to Runs.

Recued as a local control plane: a central Recued daemon holds your warehouse (mail, calendar, files, contacts, CRM snapshots), installed recipes and tools, a Contracts and Gateway enforcement boundary, approvals, and a Runs audit log. It sits between your own systems (reached via Connections with local keys), visitors arriving through Reception, external AI agents calling in over MCP contracts, and LLM providers — with personal data aliased before it leaves for an LLM and restored locally.

Reading the diagram

  1. Start in the middle — the control plane. The center is Recued, the local daemon you run. It holds your warehouse (mail, calendar, files, contacts, CRM snapshots), the installed recipes and tools, the Contracts and Gateway enforcement boundary, approvals, and the Runs audit log. Everything is local.
  2. Your systems, outbound. Through Connections, Recued reaches your own APIs, mail, calendar, tasks and CRM, files, MCP servers, notifications, and webhooks with scoped read and write. Keys stay local — vendors talk to your server, never a cloud.
  3. Visitors, inbound. People reach you through Reception and Messenger — booking, intake, file drop, approval links. Public pages expose declared fields only; the private warehouse is never shown.
  4. External agents, inbound. Any MCP client — Claude Desktop, Cursor, Codex, a custom agent, or a peer Recued — calls in through a contract: a URL, a token, and tool grants. Agents receive contracted tools, never your account keys.
  5. The LLM boundary, round-trip. Recued chat and AI steps route through policy. Personal data is aliased before it leaves — Person1, m1@d1.invalid — the model reasons over the aliases, and Recued restores the real values locally.
  6. Follow the gate. Every inbound call passes the Contracts and Gateway boundary once, in order: policy, resolve key, audit, execute. Risky outward actions are irreversible by default, so they pause for approval; allowed, denied, blocked, and approved calls all land in Runs.

The four flows

The arrows in the diagram carry the story.

  • Local read and write. Server to your systems and back — bidirectional, and the keys never leave the machine.

  • The inbound ask. Agents call in over MCP; visitors arrive through Reception. Both terminate at the gate.

  • The gate. Contracts and approval. Every call passes here before anything runs.

  • The AI round-trip. Out to an LLM with personal data shielded, back with the answer to restore locally.

The surfaces

Recued
The local daemon you run — the control plane itself: warehouse, recipes and tools, the Contracts and Gateway boundary, approvals, and the Runs audit log. Runs on a machine you own.
Contracts
The grants surface. A contract is a URL, a token, and tool grants — the inbound twin of Connections.
Connections
Outbound endpoints to your own systems — API and OAuth, mail, calendar, CRM, files, MCP servers, notifications, webhooks.
Recipes
What Recued can do — installed capabilities exposed to agents over MCP.
Runs
The audit story — every allowed, denied, blocked, and approved call.
Reception
One public-ingress surface — booking, intake, file drop, approval link — not the whole product.

Next