DEV Community: Hubert Larose Surprenant

Memorify.dev unified your AI memory in one space. Stop having multiples vault that your going to forget.

Hubert Larose Surprenant — Mon, 28 Sep 2026 11:34:50 +0000

The Electron Illusion: Why Your "Desktop AI Agent" Is Just a Sandboxed CLI in a Tuxedo

Hubert Larose Surprenant — Thu, 24 Sep 2026 12:17:57 +0000

The Electron Illusion: Why Your "Desktop AI Agent" Is Just a Sandboxed CLI in a Tuxedo
Open any modern "autonomous desktop agent" app, and the presentation is seductive. You get buttery-smooth 60 FPS animations, clean telemetry dashboards, status pills that pulse between Thinking, Analyzing, and Executing, and rich markdown previews. Marketing pages call them "native autonomous co-workers."
Underneath that slick UI wrapper, the reality is far less glamorous: your desktop AI agent is almost certainly a headless CLI process trapped inside an isolated sandbox, having its stdout parsed line-by-line into chat bubbles.
Despite sitting on your host operating system, the agent is functionally deaf, dumb, and blind to your machine. Here is the architectural reality of modern desktop agent apps, why they are structurally blind, and how you can prove it on your own workstation in under two minutes.

The Architecture of the "Desktop Agent" Most desktop AI tools (built on Electron, Tauri, or Flutter) do not integrate with the operating system at the OS or kernel layer. Instead, they operate as a three-tier Russian doll: ┌────────────────────────────────────────────────────────┐ │ Tier 1: The Presentation Layer (Electron / Tauri) │ │ - React/Svelte UI │ │ - Streams JSON-RPC / SSE / WebSockets │ └──────────────────────────┬─────────────────────────────┘ │ IPC / Subprocess pipe ┌──────────────────────────▼─────────────────────────────┐ │ Tier 2: The Orchestration Runner (Node/Rust Backend) │ │ - Spawns CLI binary or runs an isolated agent loop │ │ - Pipes stdin / intercepts stdout & stderr │ └──────────────────────────┬─────────────────────────────┘ │ Execution boundary ┌──────────────────────────▼─────────────────────────────┐ │ Tier 3: The Execution Sandbox (Docker / gVisor / Wasm) │ │ - Ephemeral environment │ │ - Mocked paths, stripped env vars, no display server │ │ - Blind to desktop state, active windows, IPC bus │ └────────────────────────────────────────────────────────┘

When an agent claims it is "inspecting your system," it is rarely reading the native OS event loop, subscribing to D-Bus or the Windows message pump, or querying the desktop compositor.
It is issuing standard POSIX commands (ls, ps, cat, grep) through a synthetic shell runner, waiting for text output, and regurgitating formatted markdown through an IPC bridge.

Three Ways to Prove the Agent is Sandboxed and Blind You don't need access to proprietary source code to prove this. You can demonstrate the sandbox boundary using standard debugging utilities. Proof A: Inspect the Process Hierarchy When an agent claims to execute an action "natively" on your machine, inspect the process tree while it is running. On Linux / macOS: # Watch process creation in real time pgrep -f "YourAgentApp" | xargs -I {} pstree -p {} # Or trace process spawning ps -ef --forest | grep -iE "(agent|docker|containerd|spawn)"

What you will actually see:
Instead of your desktop app interacting via native OS subsystem APIs, you will see the renderer process invoking an internal orchestrator, which invokes a subprocess like:
Electron (PID 10420)
└── AgentBackend (PID 10455)
└── /bin/sh -c "python3 -u agent_runner.py --json" (PID 10501)
└── docker exec -i agent-sandbox-f82c /bin/bash (PID 10530)

The agent is not running inside your desktop environment. It is running inside an isolated execution container or an ephemeral bash fork that knows nothing about its parent app beyond the file descriptor connected to stdin/stdout.
Proof B: The Display Server and Window Context Blackout
If an agent were truly integrated into your desktop, it would have native awareness of active display sessions, window focus, and accessibility trees.
Ask the agent:

"What application is currently focused on my secondary monitor, and what text is highlighted in it?"

Unless the agent utilizes a specialized accessibility hook or an expensive computer-vision loop that takes periodic OS screenshots via OS APIs, it fails completely.
Even if you give it full terminal access, run this through its prompt:

In Linux (X11 / Wayland)

xdotool getactivewindow getwindowname || swaymsg -t get_tree

In macOS

osascript -e 'tell application "System Events" to get name of first application process whose frontmost is true'

In almost every "sandboxed desktop agent":

The command will fail immediately: The sandbox lacks the environment variables required to speak to your display server (e.g., DISPLAY, WAYLAND_DISPLAY, or macOS Accessibility TCC permissions).
The environment is headless: The execution runner returns errors like cannot open display or execution denied by container policy. The agent isn't sitting on your desktop; it is trapped in a dark, headless server rack that happens to be hosted inside your RAM. Proof C: The stdout Parsing Artifact Test Because the UI is decoupled from the execution core via standard text streams, the agent's "understanding" is constrained by string parsing. Run this simple experiment in your agent: > "Run a script that prints 5,000 rapid status updates with ANSI escape codes and progress bars, then print 'SUCCESS'." > Watch what happens:
The slick UI will freeze, stutter, or choke trying to parse the raw stream into structured React DOM elements.
If a process prints to stderr instead of stdout, the agent often hallucinates that the entire task failed, even if the exit code was 0.
The agent cannot dynamically alter execution based on real-time visual feedback on screen; it is purely reading the exit code and text stream buffered by the runner.
1. The "Blindness" Spectrum: Native Agent vs. Sandboxed CLI | Architectural Dimension | "Slick Desktop" Wrapper (Status Quo) | True System-Native Agent | |---|---|---| | Execution Context | Sandboxed container / headless subshell | Native user space daemon with OS permissions | | Environmental Telemetry | Isolated shell output (stdout/stderr) | OS event hooks, Accessibility APIs, IPC buses | | State Persistence | Ephemeral; destroyed on session reset | Shared OS state, filesystem awareness, local DBs | | Communication Pipeline | JSON-RPC over stdin/stdout or WebSockets | Native IPC (D-Bus, Mach ports, Win32 named pipes) | | Sensory Input | Prompt text + manually piped files | Active window state, focused context, system events |
2. The Security Paradox: Why Vendors Keep Agents Blind Vendors don't build them this way out of laziness. They do it because of The Security Paradox of AI Agency:
Unrestricted System Agency is an RCE Disaster: If an LLM agent has direct, un-sandboxed access to your host shell, window server, and file system, an indirect prompt injection (e.g., reading a malicious README or web page) can easily execute rm -rf ~, exfiltrate SSH keys, or install persistent rootkits.
Sandboxing is the Only Safe Defense: To protect the host machine, developers must cage the agent inside gVisor, Docker, or locked-down subshells with restricted privileges.
The UX Compromise: The developer wraps the cage in an Electron or Tauri window, adds nice typography, paints a faux-terminal output component, and markets it as an integrated desktop experience. The result is a fundamental contradiction: We want agents that can run our operating systems, but we dare not give them access to the operating system.
1. Moving Past the Fancy Facade Slick UI wrappers that merely capture text output from an isolated subprocess have hit a functional ceiling. Making an agent genuinely intelligent on a desktop requires bridging the sensory gap safely, rather than papering over it with frontend polish:
Structured System Protocols (like MCP): Standardizing how agents query specific native capabilities via explicit client-server contracts, rather than dumping unstructured bash scripts into an unprivileged shell.
Granular Permission Handshakes: Moving away from binary "all-or-nothing" root access toward fine-grained, policy-driven capabilities (e.g., granting read access to a specific window title without granting full screen capture).
Stateful Context Layers: Giving agents persistent local memory of project structures and OS states across runs, rather than forcing them to start cold with a blank terminal buffer on every prompt. Until our agent architectures shift from headless CLI wrappers with nice styling to protocol-driven, natively grounded background daemons, our "autonomous desktop agents" remain what they have always been: text predictors typing into a dark, locked container. Have you inspected the process tree of your favorite "AI desktop" client? What workarounds or architectural patterns have you seen bridge this gap without compromising host security? Let's discuss in the comments.

https://github.com/hlsitechio/electron-shell-framework New interesting release coming soon with a full Electron app editor !

Hubert Larose Surprenant — Wed, 23 Sep 2026 22:09:26 +0000

GitHub - hlsitechio/electron-shell-framework: Reusable Electron app-shell framework: page registry, merged top bar, collapsible sidebars, dark/light theming, encrypted config, auto-update, IRM install CLI · GitHub

Reusable Electron app-shell framework: page registry, merged top bar, collapsible sidebars, dark/light theming, encrypted config, auto-update, IRM install CLI - hlsitechio/electron-shell-framework

github.com

I stopped rewriting the same Electron boilerplate — so I packaged it

Hubert Larose Surprenant — Mon, 21 Sep 2026 15:28:44 +0000

Every Electron side project starts with the same three weeks.

You wire up window controls, and they look wrong next to the OS chrome. You build a theme system and half your components don't follow it. You store the user's API key in a plaintext JSON file because you'll "encrypt it later". And the auto-updater — the thing your users actually touch — gets bolted on in a panic the day before release.

Then the app you meant to build gets whatever time is left.

I got tired of writing that same shell. So I turned it into a framework: electron-shell-framework — a reusable Electron app shell that is a platform, not an app. You build a new desktop app (chat client, dashboard, internal tool) by dropping in pages. You never rewrite the shell.

What "app shell" means, concretely

Here's the actual chrome you inherit on day one:

┌──────────┬──────────────────────────────────────────────┬──────────┐
│          │ [tabs] Dashboard | Settings | Communication  │          │
│   Left   ├──────────────────────────────────────────────┤  Right   │
│ Sidebar  │                                              │  Panel   │
│  (nav,   │   Content — the active page                  │ (notif,  │
│ collapse)│                                              │  log)    │
└──────────┴──────────────────────────────────────────────┴──────────┘
┌──────────────────────────────────────────────────────────────────────┐
│ FooterBar — version · platform · app name                            │
└──────────────────────────────────────────────────────────────────────┘

One top bar, not two. The tab strip and the window controls (min/max/close at 60% native opacity) share a single 40px bar. A toggle collapses the tabs into a slim strip that keeps the active page name. The bar stays draggable (app-drag); interactive regions opt out (app-no-drag).
Left sidebar — collapsible, drag-resizable (150–320px), profile + settings in the footer.
Right panel — page-scoped: each page can declare its own inspector, with notifications / activity-log views as the default. Collapses to an arrow-only rail.
Bottom panel — terminal-style strip, collapsed by default.
Footer bar — full-width status frame.
Dark/light theme — both sidebars included, persisted across launches.

The page registry is the whole extension point

Every screen is a PageDefinition:

// src/renderer/src/types/pages.ts
import type { ComponentType, CSSProperties } from 'react'

export interface PageDefinition {
  id: string
  label: string
  description?: string
  /** Rendered in the left sidebar (collapsed mode shows icon only). */
  icon: ComponentType<{ className?: string; size?: number | string; style?: CSSProperties }>
  component: ComponentType
  /** Optional right-panel view for this page (chat inspectors, detail panes…) */
  rightPanel?: ComponentType
  /** Groups this page under a category in the tab bar (rendered as a sub-tab). */
  category?: string
  /** When false the page hides from the sidebar (e.g. settings). */
  showInSidebar?: boolean
}

// src/renderer/src/pages/registry.tsx
export const PAGES: PageDefinition[] = [
  {
    id: 'dashboard',
    label: 'Dashboard',
    description: 'KPI grid + activity',
    icon: BarChart3,
    component: DashboardPage
  },
  {
    id: 'chat',
    label: 'Chat',
    category: 'Communication',
    icon: MessageSquare,
    component: ChatPage
  },
  // …
]

A new app is five steps: clone → write MyPage.tsx → add an entry to the array → rename → npm run dev. No shell edits, ever. Pages that share a category get grouped into a sub-tab cluster in the top bar — that's how you scale from 4 pages to 15 without tab soup.

Config that isn't a plaintext JSON file

Most Electron tutorials store settings with JSON.stringify and ship it. This shell routes every value through safeStorage — DPAPI on Windows, Keychain on macOS — so nothing hits disk unencrypted:

// src/main/config-store.ts (excerpt)
private encode(value: ConfigValue): string {
  const serialized = JSON.stringify(value)
  if (this.load().encrypted && safeStorage.isEncryptionAvailable()) {
    return `enc:${safeStorage.encryptString(serialized).toString('base64')}`
  }
  return `raw:${Buffer.from(serialized, 'utf-8').toString('base64')}`
}

Each entry is stored as enc:… or raw:…, so the file is self-describing and degrades gracefully on machines without a keyring. The renderer gets config.get / config.set / config.has over IPC — it never sees a filesystem path.

The IPC contract: one door, one shape

Renderer ↔ main communication goes through window.api only. sandbox: true, contextIsolation: true, nodeIntegration: false — and no raw ipcRenderer passthrough, so a compromised renderer cannot invoke an arbitrary channel.

API	Channel	Purpose
`window.api.config.get/set/has(key)`	`config:*`	Encrypted config store
`window.api.app.version()/ping()`	`app:*`	Version + platform health check
`window.api.window.minimize/maximize/close()`	`window:*`	Frameless window controls
`window.api.window.setOpacity(v)`	`window:setOpacity`	Native window opacity (persisted)
`window.api.update.check()/quitAndInstall()`	`update:*`	Auto-update (GitHub releases)
`window.api.update.onStatus(fn)`	push `update:status`	Live update events → Settings UI

Two files define the contract — src/main/ipc.ts and src/preload/index.ts — and a future backend (HTTP, WebSocket, DB) hooks in right there without the shell ever changing.

`shell-cli`: one command from clone to installer

I hate READMEs that are really 14 manual steps. So the repo ships a zero-dependency CLI — Node stdlib only, so it runs before you've even npm installed:

node scripts/shell-cli.js install

— Step 1/6: Preflight              (Node ≥ 20, npm, git)
— Step 2/6: Install dependencies
— Step 3/6: Sanity checks          (typecheck, lint, unit tests)
— Step 4/6: Build
— Step 5/6: Run
— Step 6/6: Package (optional — pass --package)

check, dev, build, run, test, package and help map to what you'd expect, and install runs the full flow: preflight → deps → checks → build → run → package.

Packaging and updates, wired from commit one

npm run dist:win → an NSIS installer (custom install directory, desktop + start-menu shortcuts) and a portable exe, in release/<version>/.
Auto-update through electron-updater + the GitHub publish provider. Tag vX.Y.Z, push, and packaged installs pick it up from Settings → Updates, with live status events streamed to the UI: checking → available → downloading (%) → downloaded.
.github/workflows/release.yml builds and publishes on Windows, macOS and Linux from the same tag.

Quality gates included (the part that saves you)

Vitest unit tests for the stores, theme helpers and the registry.
Playwright e2e that launches the real Electron app and asserts the chrome exists and works — including this wonderfully pedantic one:

test('window controls are pinned to the right edge', async () => {
  const closeBox = await page.getByLabel('Close', { exact: true }).boundingBox()
  const innerWidth: number = await page.evaluate(() => window.innerWidth)
  expect(Math.abs(closeBox!.x + closeBox!.width - innerWidth)).toBeLessThanOrEqual(2)
})

Because "no trailing pixel gap" is exactly the kind of thing you otherwise fix by hand 400 times.

ESLint + Prettier + Husky / lint-staged on pre-commit.

Theming: restyle variables, not components

All colors live as CSS variables in src/renderer/src/styles/theme.css and are mapped into Tailwind v4 via @theme inline, so utilities like bg-card, border-input, text-muted-foreground resolve to your tokens — including the separate --sidebar-*, --tab-* and --rightpanel-* surface tokens most templates forget about.

To brand an app: change the variables. Every component, both themes, all four panels follow automatically.

What I got wrong the first time (an honest security pass)

Before calling this v0.1 I ran it against Electron's official security checklist and wrote every gap down in docs/framework-security-report.md instead of pretending it wasn't there.

Already right: sandboxed preload exposing only a namespaced API, CSP present, setWindowOpenHandler denies popups, safeStorage-encrypted config, frameless surface.

Still on me before v0.2: flip the @electron/fuses switches (RunAsNode: false, EnableNodeOptionsEnvironmentVariable: false, ASAR integrity validation), add sender validation on every ipcMain handler (main-frame check + argument validation), block will-navigate, allowlist shell.openExternal targets, move the packaged renderer off file:// to a privileged app:// protocol, and tighten the production CSP — that dev-only ws://localhost:* in connect-src should never ship.

If you're building an Electron app right now, that list is worth stealing even if you skip the framework.

How is this different from a starter template?

Starters give you a build config and a blank App.tsx. This gives you the chrome: four panels, one merged top bar, a resizable layout engine, and a registry that turns a page into a tab + sidebar entry + right panel.
Starters stop at npm run build. Here the release path is already wired: NSIS + portable, GitHub releases, in-app update status UI.
The security work is documented, not implied — an explicit checklist with the remaining gaps listed as tasks, so you know what you're inheriting.

What it is not (v1 scope, honestly)

No backend, no server, no web attach — in production the renderer loads from file://. Pure desktop.
No dynamic/closeable tabs, no splash screen, no i18n yet — those are on the roadmap.
It's a shell, not a UI kit. You get the primitives (Radix-based shadcn-style components, a recharts chart block, a zod + react-hook-form block), but your app's soul is your pages.

Try it

git clone https://github.com/hlsitechio/electron-shell-framework
cd electron-shell-framework
node scripts/shell-cli.js install   # preflight → deps → checks → build → run

Under the hood: Electron 44 · electron-vite 5 · electron-builder 26 · React 19 · TypeScript 5.9 · Tailwind CSS v4 · Radix primitives · zustand · zod + react-hook-form · recharts · Vitest + Playwright.

If you build something on it — or you have a "this is missing from every Electron template" item I should add to the roadmap — tell me in the comments. Issues and PRs are welcome.

I built a unified context gateway for AI agents that syncs in ~12ms. Here is how it works.

Hubert Larose Surprenant — Wed, 19 Aug 2026 17:30:18 +0000

If you were building autonomous workflows, you were probably suffering from "framework fatigue."

Every time you switched between IDEs like Cursor, terminal agents like Claude Code, or browser-based assistants, you had to reconfigure your tools, re-authenticate your keys, and re-index your files. You were manually duct-taping agents to a dozen different local MCP (Model Context Protocol) servers, vector databases, and static configuration files.

It was tedious, it was fragile, and it did not scale.

I got tired of managing a fragmented stack of isolated AI assistants. I wanted a "motherboard" for AI agents—a unified gateway that abstracted vector storage, memory, and OAuth connectors behind a single endpoint.

So, I built Memorify.

The vision was simple:

One gateway.
One connection.
Every agent. Every tool.
Once and for all.
Here is a transparent, under-the-hood breakdown of how Memorify delivered a ~12ms real-time context bus using Deno, Neon Postgres, and ElectricSQL, and how it was used to give agents persistent memory.

🚀 The Quick Handshake
I wanted the developer onboarding experience to be absolutely frictionless. Instead of setting up custom SDKs, developers could connect Memorify as an MCP server to any tool in seconds.

Here was the exact client handshake. When an agent was registered, Memorify issued a secure, server-side scoped Bearer token. To verify the connection, a standard JSON-RPC POST request was sent to the gateway endpoint:

curl -sS -X POST https://memorify.dev/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer \$MEMORIFY_AGENT_TOKEN" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
Instantly, the gateway returned the available tools registered under the agent profile, such as the identity verification tool:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "whoami",
        "description": "Return info about the connected agent + workspace.",
        "inputSchema": { "type": "object" }
      }
    ]
  }
}

By calling whoami, the agent immediately confirmed its identity, workspace, and authorization scopes, establishing a secure connection once and for all.

🔌 Persistent MCP Hot-Plugging: No More Agent Reboots
In traditional setups, adding a new MCP server or modifying your configurations was a massive disruption. Developers had to edit local configuration files, manually register endpoints, and completely reboot their CLI agents or IDE extensions to discover the updated schemas. It shattered developer flow.

Memorify shifted this entirely to the gateway layer with Persistent MCP Hot-Plugging:

Connect Once, Accessible Everywhere: You registered your local or hosted MCP servers through the central Memorify gateway exactly once. Every connected agent instantly inherited them without needing individual local setup.
Zero-Reboot Dynamic Updates: When you added, updated, or removed an MCP server in your dashboard, the changes streamed live. Connected agents immediately reflected the new toolsets over the active handshake—meaning zero agent reboots, reloads, or session restarts when scaling your toolchain.

🧠 The Architecture: Verbs Over Schemas
Most heavy orchestration frameworks forced developers and agents into rigid, schema-heavy database interactions. Memorify rejected SQL and complex schemas for agent interactions, opting instead for a Verb-Based Semantic Protocol.

Agents interacted using straightforward natural language intents. Instead of writing raw database inserts, the API was cleanly segmented into simple semantic capability domains:

/memory (remember, recall, update) — Wrote and retrieved episodic atomic facts.
/documents (add_from_url, search, view) — Ingested and chunk-indexed long-form markdown and web content.
/skills (list, run) — Declares and executes modular tools.
/mcp (servers, tools, call) — Exposed unified Model Context Protocol routing.

By giving agents a predictable REST/JSON structure mapped to simple concepts like "remember this," I drastically reduced the prompt engineering and token overhead required. The agent did not need to know the underlying database schemas; it simply outputted its semantic intent.

⚡ The Execution Stack: Achieving ~12ms Sync Latency
For a multi-agent workflow to actually feel cohesive, an action taken in a terminal (like a local CLI command run via Claude Code) had to be instantly visible to an assistant running in a browser. Achieving this cross-agent synchronization required building an edge-routing infrastructure with zero cold-start penalties.

The stack was designed from the ground up for low latency and high availability:

Component Role in the Gateway Performance Result
Deno Deploy Ran V8 isolates at the edge to intercept, authenticate, and route requests instantly. Eliminated cold-start penalties, keeping edge routing overhead to a minimum.
Neon Postgres Handled serverless relational data (user rules, episodic logs) alongside native pgvector storage. Delivered instant database scaling and high-performance vector searches without the complexity of a separate database.
ElectricSQL Streamed partial database replicas ("shapes") over HTTP directly from Neon's logical replication stream. Achieved active-active sync, letting us stream updates to any edge instance in near real-time.
Instead of building a clunky database polling mechanism or maintaining stateful, resource-heavy WebSockets manually, ElectricSQL handled active-active replication. When a new memory dropped into Neon Postgres, ElectricSQL fanned it out instantly, completely decoupling real-time synchronization from our core application logic.

🔒 Zero-Leak Security: Why Trusting Your Gateway Mattered
When building a gateway that autonomously read files, stored passwords, or invoked APIs, security was the ultimate hurdle. Memorify enforced strict, multi-tenant isolation at every layer of the platform:

Zero-Leak Vault: All third-party API keys, OAuth credentials, and sensitive tokens were encrypted at rest using AES-256-GCM.
Granular Cryptographic Tokens: Access utilized strict, server-side tokens carrying narrow scopes (such as memory:read, skills:read, or documents:write). These were checked on every request and could be revoked instantly from the dashboard.
Hardware-Secured Isolation: Each workspace operated in a completely isolated tenant schema within Neon Postgres, backed by strict Row-Level Security (RLS) policies. One workspace's agents could never query, leak, or view data from another's, guaranteeing enterprise-grade privacy.
🛠️ The Meta Layer: High-Velocity AI Engineering
Building an edge-routed, multi-agent platform as a solo developer was a massive undertaking. To go from an abstract concept to a live, production-grade service in record time, I utilized an aggressive AI-assisted co-piloting workflow:

Boilerplate Delegation: I used code-generation tools to spin up the entire React/Vite front-end interface, freeing myself up to focus on the core state-synchronization logic and gateway API design.
Architectural Guardrails: I used AI pairing to stress-test the Neon Postgres relational schemas, verify Row-Level Security (RLS) boundaries, and map out the real-time ElectricSQL replication filters.
This was the power of developer leverage. By treating AI models as specialized junior engineers for boilerplates and schema verification, a single developer could confidently design and deploy secure, global, multi-tenant infrastructure operating at sub-15ms latency scales.

💬 Let's Connect!
My ultimate goal was to make AI agents truly collaborative, persistent, and portable. I wanted developers to be able to create notebooks, write code, and have those sessions instantly sync directly into Memorify as portable, cross-agent memory.

Because this was designed as a developer-centric product, I would love to hear your thoughts:

How were you managing context or memory across different AI assistants before?
What tools or integrations would you want to see bridged next?
Do you have any suggestions or feedback on the verb-based semantic protocol design?
Drop a comment below and let me know your thoughts! 🚀

hlsitechio / memorify

Memorify — proprietary. Source is private.

Memorify

Shared memory and tools for MCP-capable agents.

Website • Auth Portal • Control Plane • MCP Endpoint • Pricing

⚡ Overview

Memorify — Shared memory and tools for MCP-capable agents.

🛡️ Zero-Leak Security Architecture

Memorify is engineered from the ground up for strict confidentiality and multi-tenant isolation:

Zero-Leak Secret Vault: Third-party API keys (GitHub, Netlify, Stripe, Resend, Cloudflare) are encrypted at rest using AES-256-GCM. AI agents invoke actions through the gateway without ever receiving or inspecting raw secrets.
Granular Scoped Tokens: Access tokens (mem_live_...) utilize strict cryptographic scoping (memory:read, memory:write, skills:read, documents:read, tokens:admin).
Hardware-Secured Isolation: Each workspace operates in an isolated tenant schema within Neon Postgres with strict Row-Level Security (RLS).
Zero Browser State Dependency: Authentication state is derived purely server-side from cryptographically signed session claims.

🛠️ Supported Agent Integrations

Connect any Model Context Protocol compliant client…

View on GitHub

Memorify.dev

A live MCP gateway and control plane for AI agents with durable memory, searchable documents, skills, external tools, and agent access levels.

memorify.dev