v1 release · the stack runs in production; UX and edges are still being refined
The Framework

A multi-agent AI infrastructure you can run on a single Mac.

Pandora's Box is the open-source platform underneath every project on this site. Six architectural layers, OS-level isolation between agents, an independent oversight daemon that approves every action, and a personal AI interface for the owner — running locally, on hardware you own, under your control.

Why this exists

Production-grade AI without renting your data to the cloud

Early agentic systems shipped impressive demos but stalled before production. Four problems came up repeatedly:

  • Memory. Frontier LLMs are stateless. Every session starts from zero. Workarounds bolt on; few are architected.
  • Security. Skills and tools run with the agent's full trust. No independent approver. Prompt injection in user content gets treated as instruction.
  • Ability. Tool definitions go stale. Long-running operations time out. Agents either over-act or refuse.
  • Cost. Routine classification on a frontier model is wasteful. Per-token costs compound at production volume.

Pandora's Box solves these by design — not as add-ons but as the structure of the system:

  • Memory is a layer, not a hack: rolling history, vector recall, drops, important list, notes vault, session summary, optional recall scoring.
  • Security is independent: a daemon outside the agent's process approves every queued job before execution, runs as its own OS user, and cannot be instructed by any agent.
  • Abilities live in versioned, signed skill libraries that update without redeploying agents.
  • Cost is routed: local models do high-frequency low-complexity work; frontier models are reserved for reasoning depth.
Architecture

Six layers, one direction of flow

Higher layers cannot be instructed by lower ones. Jobs flow down. Control flows up through the oversight daemon only. Every subsystem belongs to exactly one layer.

Six-layer architecture overview

Layer 0 — Admin

A single admin agent. Runs under the operator's UID. No external network connectivity. Watches services, queues, audit logs, project state. Builds and modifies the rest of the system at the operator's direction.

Layer 1 — Oversight + Security

Independent daemons that monitor or classify across the whole system. The oversight daemon approves or blocks every queued job. The content classifier sidecar screens outbound content across six axes (prompt safety, response safety, refusal, prompt toxicity, response toxicity, jailbreak detection).

Layer 2 — Shared capabilities

Agent-agnostic infrastructure consumed by multiple agents. The Claude-API bridge, the MS365 MCP server, the module catalogue, the versioned skill library, recall scoring, and the shared production pipelines (media production, offline knowledge library, reviews dashboard, browser automation). One layer for shared primitives — they're not nested under whichever agent happens to use them first.

Layer 3 — Per-tenant conductors

One conductor per tenant company. Chat surface (Telegram or web). Classifies intent. Holds no tenant credentials directly. Delegates to task agents. Isolated from other tenants at the OS level.

Layer 4 — Peer agents

Autonomous specialists with cross-cutting responsibilities. Examples: trading agent, security research agent, personal assistant. Each runs as its own OS user with scoped credentials. Independent loops, independent memories.

Layer 5 — Task agents

Per-tenant task surfaces — Mail, Calendar, Files, Voice, Marketing, Web. One per function per tenant. Each holds only its own scoped credentials. Conductors delegate; task agents execute.

Security

Defense in depth — six independent gates

Defense in depth — six concentric rings

Each layer is enforced in code, not by policy:

  1. OS user isolation — separate UIDs, 750 directories. One tenant's agent cannot read another tenant's files. Architecturally impossible.
  2. Credential scoping — conductors hold no tenant credentials. Only task agents do.
  3. Tool interceptor — domain allowlist, secret scanner, deletion guard, per-session operation caps. Enforced before the API call, not after.
  4. Identity allowlist — only the verified operator's Telegram ID is accepted. All other inbound silently dropped.
  5. Job queue boundary — agents query strictly WHERE tenant = own.
  6. Independent oversight — every queued job is held PENDING until the oversight daemon advances it to APPROVED. Active blocking, not logging.

Plus a content-classification sidecar running in shadow mode that scores outbound content across six axes. The architecture explicitly accommodates a future light-gate activation once calibration thresholds are met.

Memory

Persistent context across sessions

Personal Agent memory architecture

The personal agent's memory is structured, not opportunistic. Each session loads from multiple sources, the agent reasons, then writes back. Sources include:

  • Recent history — turn-by-turn log of recent conversation
  • Vector recall — semantic search across long history
  • Drops — passive context dropped in by other agents (email, calendar, files)
  • Important list — standing facts that should always be in context
  • Notes vault — structured notes on people, threads, commitments
  • Session summary — rolling 7-day digest
  • Recall scoring — temporal-aware retrieval, optional bolt-on

Every session opens with structured checks and closes with structured writes. AI systems lose context between sessions by default — Pandora's Box makes continuity explicit.

Self-improvement

A skill governance loop

Self-improvement skill governance loop

The platform improves itself on a cadence rather than continuously. Agents log skill usage and outcomes; a governing process reviews them; scheduled workers run optimisation, calibration, and consolidation; the resulting signed manifest is pulled by each agent at session start with hash verification.

  • Reflection (hourly, observation only) — surfaces patterns without acting
  • Calibration (Saturday) — measures skill performance against baseline
  • Prompt optimiser (Saturday) — proposals on tool definitions + prompts
  • Upstream scan (weekly) — tracks dependency drift, upstream model + SDK changes
  • Weekly review (Sunday) — proposals to the operator, manual approval, never automatic
  • Consolidation (nightly) — digest writes to long-term memory

Approved improvements are applied in the next deploy cycle. Never automatically. Always reviewable.

Modules

Add capabilities without redeploying

Modules are versioned YAML manifests in the shared catalogue. Each module bundles its tools, skills, rules, and stores. Agents activate modules via agent-activation.json; the activation layer wires the module's tools into the agent's runtime without code changes.

Current production modules include:

  • Mail — Microsoft 365 / Graph integration for read, draft, attach (never auto-send)
  • Calendar — Microsoft 365 / Graph calendar read + write
  • Files — SharePoint integration with scoped folders per tenant
  • Voice — STT in, TTS out, watch + phone surfaces
  • Marketing — social + email campaign scheduling
  • Web — site building, content updates, web actions
  • Live stream vision — frame-by-frame Gemini analysis with scope gates

The module pattern means new capabilities ship as data, not code — and they're reviewable, versionable, and revocable.

Cost

Local + frontier model routing

Local plus frontier model routing

The principle is straightforward: use a small local model for high-frequency, low-complexity work — classification, summarisation, extraction. Reserve frontier models for the reasoning that needs them.

In production this means routine intent classification on every inbound message hits a local Ollama instance (gemma3:12b) at zero marginal cost, while the actual task work — drafting, planning, multi-step reasoning — goes to Claude. Weekly engagement reports are synthesised entirely by the local model. A frontier API call is reserved for the moments it earns its cost.

An automatic fallback path routes to a smaller frontier model (e.g. Haiku) if the local instance is unavailable. No service interruption.

Status

Where this is now

Pandora's Box is being prepared for open-source release under the Apache 2.0 licence. The repository is currently private pending the legal work that precedes public flip — Holdings entity registration, trademark filings, and a git history rewrite.

The site you're reading is the public-facing surface that will go live alongside the repository. The install line will be active on the day of release.

If you want to be told when that happens, open an issue on the placeholder discussion repo or watch this site.