Skip to content
DEEP-DIVE·Apr 16, 2026·6 min read

Introducing Agent Packs: How We Monetize Without Betraying Our Users

architecturepacksopen-sourcebusiness-model

There is a well-worn path for open-source AI projects that start making money: gate the features people actually need behind a subscription, call what remains "community edition," and gradually shift the good stuff to the paid tier. The technical term for this process is enshittification. The business logic is obvious. We are not going to do it.

Here is the architecture we built instead, and why the technical decisions are inseparable from the economic ones.

The problem

Open-source AI tooling has a funding problem that is different from most open-source software. The models you need to run useful local inference are large — 7B to 70B parameters — and keeping up with them requires real engineering time. Documentation, packaging, security reviews, plugin APIs, cross-platform testing: none of it happens on goodwill alone.

At the same time, the moment you put a paywall in front of a privacy-first tool, you have destroyed the reason your users chose you. Someone who picked Cognithor because they do not want their data in the cloud is not going to pay a monthly subscription to a cloud billing provider to keep using it.

The constraint is: we need revenue that does not require us to become the thing our users are avoiding.

Our answer: Agent Packs

An Agent Pack is a paid add-on that ships entirely new capability — new MCP tools, new skill markdown, new prompt libraries, new onboarding wizards — without touching the Core OS in any way. The rule is simple: packs can add, they cannot gate. If a feature was free yesterday, it is free tomorrow.

The Core OS ships with web_search, search_and_read, and three bundled lead sources (Hacker News, Discord server monitors, and RSS feed scanning). Those stay free. A pack can ship a better, more specialized version of any of those things, but it cannot remove or degrade the free version.

This is an architectural commitment, not a policy commitment. Policies change. Architecture enforces.

The three-repo model

Under the hood, we run three repositories:

cognithor-core is public on GitHub under Apache 2.0. Everything the Core OS does — the PGE loop, the Gatekeeper, all 122 base MCP tools, the Flutter command center, the memory system — is in there. No obfuscation, no minification, no "source available" hedge. Apache 2.0. Fork it, audit it, self-host it.

cognithor-packs is a private repository that holds pack source code. Each pack builds to a signed archive with a canonical SHA-256 embedded in the public registry. You cannot audit the source of a paid pack before buying — that would be a piracy problem — but you can verify that the archive you installed matches the one in the registry, and you can inspect the manifest before installing.

cognithor-site (this site) pulls from both. The public registry is a static JSON file auto-synced from the packs repo on every release. The site never has credentials to the packs repo; it only reads the registry JSON.

PackLoader and isolation

When you install a pack, PackLoader extracts the archive into ~/.jarvis/packs/{pack-slug}/ and validates the manifest. The manifest declares every MCP tool the pack may call. That list becomes an allowlist in ToolEnforcer.

ToolEnforcer sits between the Planner and the Gatekeeper. When a pack skill is active, the Executor can only call tools in that pack's declared allowlist plus a small set of Core primitives (read-only vault access, structured output, etc.). Any attempt to call an undeclared tool — including Core tools outside the allowlist — is a Gatekeeper RED. The PGE loop halts. The user sees an error.

The isolation model uses importlib to load pack Python modules into a sandboxed namespace rather than the main jarvis package tree. A pack cannot import from jarvis.core directly. It can only call the MCP tool interface — the same interface any external MCP server would use. This means a malicious or buggy pack cannot reach the Planner's system prompt, the Gatekeeper's risk tables, or the memory system's raw SQLite connection.

EULA acceptance is SHA-256 pinned. The EULA text for a pack is hashed at pack build time and embedded in the manifest. When you click through during installation, the timestamp, pack version, and EULA hash are written to ~/.jarvis/pack_licenses.db. If the publisher later modifies the EULA without bumping the version, the hash mismatch is caught at load time and the pack is quarantined. This is not DRM — you can still run a quarantined pack by explicitly acknowledging the change — but it ensures you always know what you agreed to.

The first two packs

Reddit Lead Hunter Pro (€75 one-time) is what most people will encounter first. It ships five MCP tools — reddit_scan, reddit_score_leads, reddit_reply, reddit_crm_upsert, and a scoped vault_write — plus a four-dimensional lead scoring system tuned to keep false positives below 10%. The free bundled lead sources are still there. This pack adds Reddit specifically, with a quality bar higher than you would get writing the integration yourself in an afternoon.

Deep Research Analyst (€65 one-time) is for multi-hop research workflows. You give it a question that requires synthesizing across dozens of sources — competitive landscape, regulatory review, technical feasibility assessment. It runs search_and_read calls in a structured tree, builds a citation graph in the vault, and produces a structured report with confidence scoring per claim. The free search_and_read tool is unchanged and still works exactly as before. This pack adds the orchestration layer on top.

Both packs are one-time purchases. You own the version you paid for. Future versions are optional paid upgrades, not subscriptions. The Core OS that runs them is always free.

What stays free

To be precise about it:

  • The entire Core OS: PGE loop, Gatekeeper, all 122 base MCP tools, memory system, Flutter UI, Telegram/Discord/Slack channels, skill generation, Evolution Engine, Computer Use, Kanban, ARC-AGI-3 integration
  • web_search and search_and_read — both MCP tools, both free, both unlimited on your own hardware
  • The three bundled lead sources: Hacker News, Discord server monitors, RSS feeds
  • All future Core OS updates for the version line you are on
  • The pack manifest format, PackLoader, ToolEnforcer — the entire pack infrastructure is in Core

If you never pay us anything, Cognithor is still a fully functional local-first agent OS. That is not a marketing sentence. It is what the Apache 2.0 license guarantees.

The promise

We have a /promise page that states this in plain language and will remain up indefinitely. The short version: Core features do not move to paid. Paid packs do not degrade free alternatives. Your data does not leave your machine unless a tool you explicitly invoked sends it somewhere — in which case the manifest must declare that network access.

We wrote it as a page rather than a tweet because pages have URLs that stay linkable when someone wants to hold us to it.

What comes next

The creator marketplace opens in Q4 2026. The model is 70% to the creator, 20% to Cognithor, 10% to payment processing. No exclusivity requirement. No approval gatekeeping on features — only on security. The same PackLoader, ToolEnforcer, and EULA infrastructure that ships commercial packs today will handle community packs. The validator pipeline that currently runs on our CI will be available as a CLI command so creators can check their packs locally before submission.

If you are thinking about building a pack, the /publish page has the spec.

The packs themselves are at /packs. The promise is at /promise.