# Vyre 0.5.2

Branch: `release/0.5.2`. Status: planned. Follows 0.5.1.

Theme: connect outside systems, and make agents cheaper and better. Integrations are separately built, signed modules for outside services. Skills and Plugins get screens. An agent efficiency program measures what Vyre costs an agent and cuts it. One Chrome extension replaces three pieces. Sizes are given where an estimate exists; most items here still need one.

## Integrations

An Integration is a separately built, signed module that wraps an outside system and brings its own capabilities. It is not part of the core everyone gets. Order: the contract and the section first, then the first two systems, then the other two.

1. **Integration contract.** One standard, very flexible: every part is optional and an Integration declares only what it brings. Additions to the module manifest: Flow steps and triggers (schema, inputs, outputs, whether the effect is a read or goes outward, the kind of Gate), record types or fields, its connection (credential kind, sign-in with refresh, request budget), agent tools for the MCP hub, and optional screens from the shared block kit. The Flows catalog and editor read installed Integrations' steps. Why: many systems, each bringing different things, must not need a new mechanism each time. Test: a sample Integration declaring one step, one record type and one tool installs, its step appears in the editor and runs, and nothing it did not declare exists.
2. **Integrations section.** One section listing installable Integrations. One action downloads, verifies the signature, configures the connection in the Vault and enables. Uninstall removes its steps and tools and ends its grants. Today's connector presets fold into it, so there is one concept. Test: install then uninstall leaves no step, tool, grant or Vault lease behind; a tampered package is refused.
3. **Make an Integration from an API.** Builds on connectors made from an API's description: an agent writes the Integration from the API's docs, the person reviews and installs it. First-party Integrations are built the same way. Test: from a small public API description an agent produces an Integration that passes the contract checks and that a person can review before install.
4. **Clio.** Steps to create or find a contact and matter, related contacts, custom fields, calendar entries and document upload; sign-in with refresh; a request budget for its rate limit; idempotent writes. Needs a sandbox account. Test: a Flow creates a contact and matter twice with the same key and the sandbox holds one of each; the rate budget is never exceeded in a burst.
5. **Lawmatics.** Steps for prospects and matters (find, create, update, custom fields via the documented key, search by email, name or phone). Test: a Flow upserts a prospect with a custom field and a second run changes nothing.
6. **GoHighLevel.** Contacts, conversations, opportunities and workflow triggers as steps and triggers. Test: a Flow creates a contact and starts a workflow, and an inbound event starts a Flow.
7. **DecisionVault.** Reads and writes of a client's decisions and documents as steps and record types. Test: a Flow reads a stored decision into a document and writes a status back.

## Skills and Plugins

8. **Skills screen.** Browse, search, read, write, version and roll back skills by scope (person, project, Space); approve proposed and learned skills; see which agents and projects use each. The backend and its tools exist; only the screens are missing. Test: write a skill, approve it, see which agent uses it, roll it back, and the agent's next session uses the older version.
9. **Plugins screen.** Install, configure, enable per agent and project, and remove. Native to each provider (Claude Code plugins and skills, Codex, Grok equivalents); one Vyre skill or plugin is carried to every provider where its parts translate (instructions, MCP servers, commands, hooks), and the screen says plainly what does not carry. Plugins with code need an owner's or admin's yes. Test: install one plugin, enable it for one agent only, and see it in that agent's sessions on two providers with a note for any part that did not carry.

## Agent efficiency program

Research first: what others do now (tool search and deferred tool loading, context compaction, skills as progressive disclosure, provider-native plugin formats, MCP registries, cross-model memory), written up with sources before anything is built.

10. **Vyre tax eval, a release gate.** The same real tasks run by the same model with and without Vyre; track success, turns, tokens, time and cost. A release cannot ship if agents get measurably worse. Uses the existing token-proof harness. Evals are budgeted at about 5 dollars a round. Test: the gate fails a deliberately worsened build and passes the current one.
11. **Fewer tools up front, the right one picked.** A small always-on core plus on-demand tool loading, intent routing, and grouping by task. Measure pick accuracy per model as the tool count grows. Test: with the full tool set, accuracy on the eval tasks is no lower than today and the tokens before the first turn drop by a stated amount.
12. **Cut the agent docs without cutting capability.** The agent docs are about 12,600 tokens today. Keep a short index always on and fetch detail by `docs.find` or `skills.get`; load per task; lay out for prompt caching; remove what the tool descriptions already say. Test: tokens per session fall by a stated amount in the Vyre tax eval and no eval task regresses.
13. **Less friction around actions.** Measure every hold, ask and refusal an agent meets on real tasks; remove the ones that protect nothing; one yes for a whole plan where that is safe. Test: the count of avoidable holds on the eval tasks drops, and no outward action loses its hold.
14. **Model switching mid-chat.** Instant and cheap: carry a compact state, not the whole transcript, across providers; reuse caches; one transcript format Vyre owns. Fix the case where switching accounts loses the session id first. Test: switch models three times in one chat and the new model answers a question that needs the earlier context, with the carried state under a stated size.

## One Chrome extension

15. **One extension for Chrome.** Merge three pieces (the password and passkey extension, the Chrome control extension, and the standalone Chrome control server) into one that works on Chrome first, then Edge, Brave and Arc, with Firefox for fill only. It signs in like a device of the person: its own device key, shown in Devices and removable there, reaching the Space the way the web app does, with no typed address. Test: install, sign in, see it in Devices, remove it there, and it stops working.
16. **Vault unlock in the extension.** The master password unlocks the person's own vault in the extension; it locks on idle and on browser close. Test: after idle timeout a fill asks for the password again; no vault value appears in a chat transcript.
17. **Chrome control for chats.** A chat asks to use this Chrome; the person allows it once and it is hands-free on that browser until taken back; Esc or the toolbar stops everything; sends, posts and payments stay held for a yes. Uses the extension's signed-in session, with no native host and no local port. Test: allow, drive a page, press Esc and everything stops, and a send is held.
18. **Chat in the browser side panel.** The extension opens a Vyre chat in Chrome's side panel; every chat there is an ordinary Vyre thread saved in the Space and openable from the app and phone. The agent sees the current tab only when the person turns on sharing it (an accessibility snapshot first, a screenshot only when needed); password and card fields are never read. Test: start a chat in the panel, open it in the app, and with sharing off the agent cannot read the tab.
19. **Security review of the extension.** A new device class, its key storage, the debugger permission, which pages control may touch, and its logs moving into the Space's activity. Test: the review's findings are closed before release.

## Later

Not scheduled for 0.5.1 or 0.5.2.

- Send a made document for signature directly, with boxes placed from markers in the Word template, and let members send documents they can read.
- "Take your data": one export of everything a person can reach, and SQL import for records.
- Sign in with GitHub, Google or Microsoft as identity only; GitHub access for work; sign-in capture for MCP servers inside a session.
- Sites: password or team-only access for a live site, rollback to a chosen version, kept logs, visits, delete, and a domain wizard.
- Flows run page: bulk retry, a "record created or updated" trigger, debounce for bursty triggers.
- Agent and assistant folders shown in Files; agent memory pane and lessons.
- Needs you: server-side snooze, choice asks, undo, credential asks that open the Vault prefilled.
- Linked-folder links visible only to the member who made them; stable item ids in the drive index; the native Finder and Explorer mount proven on real machines.
- Vault: rotate the personal key after a suspected compromise; move a member's secret key to a new device by approved sign-in.
- Checkpoint store purge: per-version delete for credential files uploaded by older lent sessions.
- Playbooks: archive a template, per-template gating, fuzzy stage-set matching.
- Records: server-side filters and search; field-group names hidden from members who cannot read them.
- Example Kits as content: estate administration and contingency intake.
- Real-device proof on iPhone and Android, native push, Screen Share, and a Windows home.