The Bundle Is the Moat
Every serious AI agent platform has solved one or two of the hard problems. Snippbot is the only one we know of that has solved all of them together — self-hosted execution, cognitive memory, a signed marketplace, mobile human-in-the-loop approval, defense-in-depth security, and a native economic layer. This page is the argument for why that combination is the product.
Security layers
Cognitive memory
Package scan pipeline
Marketplace package types
A Category of One
Hosted platforms optimize for distribution. Open-source orchestration frameworks optimize for flexibility. Self-hosted chat UIs optimize for privacy. Specialist memory libraries optimize for recall benchmarks. Each of these is a real product with real strengths — and each one is a partial answer. Snippbot is what happens when you refuse to pick one axis.
- The daemon runs on your hardware.
- The memory system learns across every conversation.
- The marketplace is signed and scanned.
- The mobile app turns your phone into an approval console for anything the agent wants to do.
- The defense envelope wraps all of it.
No single competitor will be wrong — they will just be incomplete. The bundle is the moat.
The Bundle: Six Capabilities, One Platform
Each capability is real and implemented today. Most platforms ship one or two. We ship all six — and the interactions between them are the product.
Self-hosted execution with OS-level isolation
Snippbot runs as a local daemon on your machine — no managed cloud, no account required, no data egress by default. Agent tool execution runs inside isolated containers (Docker or Podman) with enforced resource limits. MCP servers are additionally wrapped in OS-level sandboxes (macOS Seatbelt, Linux bwrap/firejail). When no sandbox is available, execution is denied — the system fails closed.
Cloud platforms route your data through their infrastructure. OSS orchestration frameworks leave sandboxing to you. Snippbot ships the daemon, the container isolation, and the OS-level sandbox as one integrated stack.
5-tier cognitive memory, fully local
A sensory buffer filters noise before any exchange becomes a permanent episode. A working-memory layer manages the active context window and tracks hot entities per session. An episodic store uses SQLite FTS5 + 384-dimensional HNSW embeddings merged by Reciprocal Rank Fusion. A knowledge graph captures entities and relations with confidence scoring. A meta-cognitive layer closes the loop with recall feedback — memories that influence output get boosted, memories that are ignored get decayed, and a forgetting curve archives stale content automatically.
Specialist memory libraries publish strong recall benchmarks — but they ship as a cloud service or a single library, not as part of an agent platform with marketplace, security, and mobile approval already wired in. Read the memory architecture →
Signed, audited Singularity marketplace
Every package in the Singularity registry passes a 4-layer scanning pipeline — static analysis, VirusTotal artifact scan, permission-manifest validation, and sandbox execution test — before it can be published. Publishers sign packages with Ed25519 keys; the registry enforces signature verification and tracks key fingerprints. Nine distinct package types are supported: tools, MCP servers, hooks, scheduled jobs, workflows, sandbox presets, agent profiles, shared assets, and combined agents. Installed packages get per-capability permission grants enforced at runtime by the local daemon.
The largest MCP catalogs optimize for package count. We optimize for what happens when a bad package is published — and for what happens after install, when runtime permissions are checked against the declared manifest.
Mobile owner-approval console
The native iOS and Android client is not a chat mirror — it is a remote-control and approval surface for the self-hosted daemon. Push notifications route approval requests (session joins, elevated tool calls, trust decisions) to the owner's phone with biometric verification and a 5-minute default approval timeout. Device pairing uses QR codes with deep-linked approval flows, and every decision is logged to the local audit trail. Mobile overview →
Self-hosted agent platforms typically ask the user to be at the keyboard when approval is needed. Push-based owner approval is a distinct UX category — and to our knowledge no other self-hosted agent ships it.
9-layer defense envelope
AES-256-GCM encryption at rest with PBKDF2 (600K iterations) and OS-keychain master keys. Ed25519 agent authentication with replay protection. A 5-tier permission model with audit logging on every check. Container plus OS-level sandboxing. Command validation with evasion-detection regex and environment-variable whitelisting. Prompt-injection defense scanning external content against 27 detection patterns across instruction-override, role-spoofing, obfuscation, XML/JSON, and data-extraction categories. SSRF protection with DNS-rebinding defense, private-IP and cloud-metadata blocking, and sliding-window rate limiting. Supply-chain validation of installed packages. Audit trails and error sanitization on every 5xx response.
Every layer is independent. A breach at any single layer is contained by the others. Read the security architecture →
Native economic layer
The marketplace has a first-class payment surface. A dedicated Solana bridge (snipp-api) exposes routes for balance checks, paid relays, escrow holds, publisher staking, claim payouts, price quotes, and verified transactions. Publisher reputation, feature bounties, and bundle payouts all settle through the same rails. The token itself — SNIPP — is a Solana SPL deployed for devnet/testnet; mainnet migration and on-chain escrow are in progress.
Package marketplaces generally rely on third-party payment processors bolted on. An agent platform with a native token, escrow, staking, and on-chain verification as first-class registry primitives is a different shape of product.
The MCP Ecosystem Has a Security Problem
The open Model Context Protocol catalog grew faster than its safety story. The numbers from recent ecosystem audits are not good.
Server-side request forgery
Of roughly 8,000 public MCP servers audited in 2026 were found vulnerable to SSRF.
Unsafe command execution
Accepted agent-controlled input into shell execution without meaningful validation.
No authentication at all
Exposed tool surfaces with zero authentication — anyone on the network could invoke them.
Singularity's answer
The Singularity marketplace does not treat MCP servers as trusted by default. Every submitted package — including MCP servers — flows through four independent defenses before and after install.
4-layer scan pipeline
Every submitted package flows through the 4-layer scan pipeline (packages/registry/src/singularity_registry/scanning/orchestrator.py).
Runtime permission grants
Installed packages get per-capability permission grants stored in SQLite and checked at runtime (packages/core/src/snippbot_core/marketplace/permission_grants.py).
MCP command validation
Local MCP command validation blocks shell metacharacters and enforces a transport allowlist before any connection is made (packages/core/src/snippbot_core/security/mcp_validation.py).
Outbound egress defense
SSRF protection, DNS-rebinding defense, and a domain egress allowlist sit in front of every outbound HTTP call the daemon makes.
The goal is not to replace the MCP ecosystem. It is to give users a curated, scanned, signed, permission-gated subset they can trust — and to enforce that trust in the runtime, not just at the catalog listing.
Mobile Approval Is a Product Category
Push-based owner approval turns the phone into a remote control for the self-hosted daemon. It is not a chat mirror. It is a new UX shape.
How it works
- A remote user (or a background job) triggers an action that requires owner consent — joining a session, invoking an elevated tool, pairing a new device.
- The daemon emits an approval request and the mobile app receives a push notification with an actionable category and a 5-minute default timeout.
- The owner confirms with biometrics; the decision posts back to the daemon and unblocks the agent's execution — or times out to a safe default if ignored.
- Every approval, every denial, every timeout is logged locally. Trusted-device registration and revocation are first-class primitives.
Why it matters
Self-hosted agents have always had an availability problem: the owner is not always at the keyboard. The standard workarounds are bad — leave the agent permissioned to do whatever it wants (unsafe), or make it block forever (useless).
Push-based owner approval breaks the tradeoff. The agent can run fully autonomously for low-risk work and escalate to the owner's phone for the rare moment that matters. The phone is already a trusted device with a biometric sensor and a secure enclave — the infrastructure has existed for a decade. No other self-hosted agent platform we have seen ships this loop end to end.
Code paths: packages/local/src/snippbot/api/remote_sessions.py, packages/mobile/app/session/approval-wait.tsx, packages/mobile/src/services/pushNotifications.ts.
How the Categories Stack Up
An honest comparison across the four broad categories of AI agent product. No brand names — every real product lands inside one of these columns.
| Capability | Snippbot | Cloud Platforms | OSS Orchestration | Self-Hosted Chat UIs |
|---|---|---|---|---|
| Self-hosted by default | Yes | No | Yes | Yes |
| Persistent cognitive memory | Yes | Partial | Partial | No |
| Signed marketplace with runtime permission grants | Yes | Partial | No | No |
| Mobile push-based owner approval | Yes | No | No | No |
| OS-level sandbox for tool execution | Yes | Yes | No | No |
| Multi-layer package scan pre-publish | Yes | Partial | No | No |
| Native economic layer (token, escrow, staking) | In progress | No | No | No |
| Full data sovereignty (no telemetry, no phone-home) | Yes | No | Yes | Yes |
"Partial" means the category typically ships the capability in some form but not at parity with the Snippbot implementation — for example, hosted platforms have session memory but not a local 5-tier cognitive stack; some hosted catalogs sign packages but do not enforce permission grants at runtime on the user's machine.
What we are not building
The bundle is a strong position precisely because it rejects adjacent ones. We are opinionated about what Snippbot is not:
- Not a hyperscaler distribution play. We will never win on raw user count against the hosted assistants — and we do not need to. A smaller, deliberate audience of users who care about sovereignty, memory, and safety is the target.
- Not the biggest catalog. Singularity will not out-ship the open MCP aggregators on package count. It will out-ship them on the fraction of its catalog that is actually safe to install and run.
- Not a no-code workflow builder. There are excellent ones; we are not replacing them. Snippbot's workflow primitive exists to let an agent compose multi-step tool calls safely, not to be a visual automation canvas.
- Not a benchmark chaser. We have not yet published numbers on common memory-recall benchmarks. The memory architecture is built for honest long-term behavior — sensory filtering, forgetting curves, closed-loop recall feedback — and we would rather publish our first benchmark results after real users have stressed the system than claim scores we have not earned.
What is shipped and what is in flight
- Self-hosted daemon
- 5-tier memory
- Signed marketplace
- Mobile approval loop
- 9-layer security envelope
- Multi-agent chat orchestration is present in the codebase with five interaction modes (Solo, On-Demand, Collaborative, Freeform, Structured); the canonical
TurnOrchestratorrefactor to replace the current inlined multi-agent SSE path is tracked as a v1.2 task. - The economic layer (SNIPP) has devnet/testnet deployments and a working Solana bridge; mainnet migration and on-chain escrow settlement are in progress.
We would rather be specific about this than overstate maturity.
Run the bundle
The thesis is only interesting if the product runs. Install Snippbot and you get the daemon, the memory system, the marketplace client, the mobile pairing flow, and the full security envelope active from the first start — no configuration required.