Flagship Products

Three products instantiate the thesis — each a system, each mapped to its role. Together they cover what the system knows, how it’s delivered to end users, and what it’s allowed to do. For how they’re built — the shared @fractalboxdev/* package families — see Product Stack.

Principles

1. Position as an alternative with a twist — don’t compete head-on; reframe the category with a differentiated angle the incumbent can’t easily copy.
2. Solve a new hair-on-fire problem — target pain that didn’t exist 12 months ago; urgency beats awareness every time.
3. Sell outcome, not tool — buyers pay for results; the workflow is invisible.
4. Unique scenarios — win where generic solutions can’t reach.
5. Own the soul — the key selling point is owning the core identity and value prop, not hyping a fancy new workflow or UX. We don’t build a “Notion alternative.”
6. Trojan horse — simple-to-integrate recipes (e.g. compliance checklist) that land easily, then expand. Support single-player mode first, unlock multi-player mode as the team adopts.
7. Collaboration = product-led growth — multi-player features are the expansion engine; every invite is distribution.
8. Ecosystem as channel — integrate with Obsidian, Notion, and agent harnesses (Claude Code, Hermes, Codex) as both source and sink. Every integration is a distribution surface.

Contextful

Collaboration-first agent context & memory for known teams, built on the Hakiri context engine. This is the product launching now.

What it is

A single-binary, local-first data movement runtime that gives agents and teams a portable, shareable context layer — sync-able across teammates, sandboxed, inspectable end-to-end, compliant by design, and independent of any LLM vendor. The audience is a known, controlled team — engineers, analysts, ops, compliance — collaborating on the same context.

Core properties

• Local-first. Pipelines work offline; sync is opt-in convenience, not a requirement. Data never leaves the customer’s environment unless they choose to sync.
• Agent-first. Agents are first-class authors of connectors and pipelines via a built-in MCP server, schema discovery, dry-run, and sandboxed compile+install.
• Provider-agnostic. Context and memory are infrastructure, not a feature of any one model vendor. MCP is the only mandatory agent interface — swap Claude for Codex or local Llama without re-platforming context.
• Declarative. Manifests describe desired state (Terraform/dbt style); the runtime owns reconciliation, retries, schema evolution, and checkpointing.
• Portable. The same binary runs as a local CLI, a long-running daemon, a Cloudflare Workflows step, or an AWS Lambda/Fargate workload.

Architecture highlights

• WASM-sandboxed connectors — typed WIT contract that agents can author and maintain. No subprocess soup, capability-declared host access, hot-swappable without redeploy.
• MCP-native context store — Parquet files + SQLite catalog + JSON manifests. Queryable with DuckDB, exportable as a tar, deletable per-row. One MCP tool surface unifies structured filters with vector and full-text retrieval.
• Capability-based access control — tokens carry { subject, actions, tables, constraints, ttl }, verifiable offline. Agents are first-class principals with composable, attenuatable capability tokens.
• Sync over plain object storage — push/pull directly to any S3-compatible bucket (R2, S3, MinIO). No sync server, no relay.

Why it’s defensible

The structural moat is vertical depth in regulated workflows + provider independence:

1. A frontier-API-dependent rival cannot match the data-residency promise (data plane never leaves customer environment).
2. A horizontal lab won’t encode one domain’s deterministic rules into the context layer.
3. The MCP-only boundary means switching model vendors changes nothing about the context — no migration, no re-ingest.

Positioning

Somewhere between dlt (Python ELT library), Airbyte (large connector marketplace, heavy infra), and Meltano/Singer (declarative ELT framework) — but with WASM Component Model connectors instead of subprocesses, a context store instead of “ship to your warehouse”, and an MCP server in the box.

Meerkat

github.com/fractalboxdev/meerkat

A toolkit to build harness and safety guardrails for AI agents in risk management and compliance.

What it is

Meerkat is the governance and control-plane layer that decides and proves what an AI agent is allowed to do in a specific regulated workflow — with a replayable, regulator-legible audit trail, running local-first so data never leaves the buyer’s infrastructure.

Core capabilities

• Use-case guardrails. Define what actions each agent can take in each workflow — deterministic rules for a regulated domain, not probabilistic “alignment.”
• Permissions & scoping. Per-agent, per-task, per-data-slice permissions that model the real principal: (agent, host, on-behalf-of, task-id), not flat roles.
• Audit & accountability. Every agent action produces a replayable, regulator-legible audit trail. Show exactly what happened, what policy allowed it, and prove no data egress.
• Exception handling. When an agent hits a boundary, Meerkat captures the exception as a signal — escalate to a human, log for review, or auto-remediate within policy.
• Compliance mapping. Map guardrails to regulatory frameworks (AI Verify, EU AI Act, SOC 2, sector-specific rules) so the governance layer speaks the auditor’s language.

Why Meerkat

Like meerkats standing sentinel over their colony — always watching, always alert to threats — Meerkat stands guard over your AI agents: monitoring actions, enforcing boundaries, and raising alerts the moment something crosses a line.

Target buyers

• SMB finance/compliance firms — regulatory and audit pressure they can’t staff for. A full-time CISO is overkill; Meerkat + fractional CISO fills the gap.
• Enterprises deploying agents into regulated workflows — need to prove to auditors what the AI did, why it was allowed, and that data stayed within policy.
• Crypto/DeFi teams — smart contract and agent interactions with real money need deterministic safety guarantees, not probabilistic ones.

The wedge

The productized security-assessment + compliance-readiness engagement (~S$8–12k, 5–10 MD) is the front door. Meerkat is the continuous governance layer that follows — the reason the buyer stays.

Spore

Agent context as a SaaS building block — multi-tenant, isolated, designed to be embedded in another vendor’s product to power their end-customer-facing agent.

What it is

Spore takes the Hakiri / Contextful engine and exposes it as a SaaS surface another product embeds. The host SaaS plugs in connectors, isolates each of their customers as a tenant, and ships an agent to their end users — without having to build the context layer, the connector runtime, or the per-tenant permission model themselves.

Where Contextful is for the team running it, Spore is for the SaaS vendor’s customers. Spore’s user is one step removed: the SaaS vendor integrates Spore; the SaaS vendor’s customer (and their end users) is who the agent actually serves.

Why it’s a separate product, not a Contextful SKU

Same engine, fundamentally different product surface:

• Trust boundary. Contextful trusts the team running it. Spore must isolate untrusted, unknown end-tenants — multi-tenant from day one, no shared blast radius.
• Buyer. Contextful is sold to a team. Spore is sold to a SaaS vendor whose buying criteria are tenant isolation, embeddability, SLAs, and per-tenant billing — not local-first sync to a teammate.
• Pricing. Contextful sells the sync layer recurring on compute & storage. Spore prices per-tenant / usage-based, in a shape the host SaaS wraps into their own pricing.
• Surface. Contextful exposes a CLI/daemon and an MCP server to teammates’ agents. Spore exposes an embeddable SDK + per-tenant API + admin/observability dashboard for the host SaaS.
• Roadmap. Forking the products lets each one optimize for its buyer; collapsing them into one SKU forces compromises that hurt both.

Why we still build it

It’s the same engine. The connector runtime, context store, capability tokens, and MCP surface are reused — Spore is the second go-to-market for an asset we’re already building, not a second codebase. Sequencing matters: ship Contextful first (faster path to revenue, simpler trust story, shorter sales cycle), then productize Spore once the engine is proven and SaaS embed prospects (Vascue) are ready to integrate.

Target buyers

• Vertical SaaS vendors shipping an agent to their customers (analytics, customer support, finance ops, compliance) — they need per-customer context isolation but don’t want to build the data movement and permission stack.
• Embedded-AI infrastructure buyers — product teams that have decided to add an agent to their SaaS but don’t want to take on the context-layer engineering risk.

How Contextful, Spore, and Meerkat compose

Contextful holds what the team system knows; Spore holds what each end-tenant’s system knows; Meerkat governs what any of them is allowed to do.

• Contextful’s capability tokens enforce what data an agent can see inside a team.
• Spore’s tenant boundary enforces what data each end-customer’s agent can see — same token model, applied per-tenant.
• Meerkat’s guardrails enforce what actions any agent can take, in either deployment.
• All three produce machine-readable audit trails that compose into a single compliance story.

Client profiles (Prospect)

Early prospects map cleanly onto Contextful (team / collaboration) vs. Spore (embedded SaaS, user-facing). The split shapes the connector roadmap, the embed story, and the permission model.

The pattern: known team → Contextful, end-customer-facing embed → Spore. Vascue is both, served by the same engine through two different products.

Milestones

The Q3 dev block (Jul–Sep 2026) builds Contextful + Meerkat to launch into the Q4 window. Spore is sequenced after Contextful traction — same engine, productized into a SaaS-embed surface once the early Contextful + Spore prospects (AX, Numu, Vascue) prove the demand. The Sep-30 gate is the Q3 checkpoint.