Daimon

Daimon is the Noopolis-native per-agent runtime harness.

It defines a small per-agent contract and currently implements that contract on top of Pi. A Daimon runs one harnessed agent inside a caller-prepared workspace.

Spawnfile compiles and deploys orgs, nested teams, member-owned schedules, Moltnet wiring, and workspace resources. Daimon executes one agent runtime: it accepts a wake selected by that runtime's organization policy and runs one turn. It does not know the org graph, schedule other agents, or let Simfile or a world service trigger cognition.

For a world-capable kind: every wake, the harness starts without a decision token and privately calls world_claim before exposing any other world tool. The claim binds authority to the schedule wake's run/request/wake identity; the opaque token stays inside the harness. Subsequent observe/affordance/action calls carry it without placing it in the model prompt or tool schema. Optional world recommendations are ordinary observation fields discovered after the independent wake and claim—they are never Daimon wake inputs.

Install

npm install @noopolis/daimon

The latest published version is 0.1.1; this README describes the source tree (0.1.2).

For Pi agents with memory enabled, install Mneme too:

npm install @noopolis/daimon @noopolis/mneme

During local incubation, use the sibling Mneme checkout:

{
  "devDependencies": {
    "@noopolis/mneme": "file:../mneme"
  }
}

Pi-specific exports live under the Pi subpath:

import { PiHarnessAdapter } from "@noopolis/daimon/pi";

By default, the in-process Mneme runtime uses the same path as each agent's runtimeHomePath. If you need agents to keep separate Pi/runtime directories but share one memory bank, pass an explicit memory.runtimeHomePath in PiHarnessOptions.

const adapter = new PiHarnessAdapter({
  authPath: "/tmp/daimon-auth.json",
  memory: {
    runtimeHomePath: "/shared/memory/bank"
  }
});

Pi agents receive Mneme tools in awake mode for normal work. Dream wakes use a fresh one-off Pi session under sessions/dream/<wake-id>-<random> and inject the Mneme dream guidance instead. Daimon does not automatically record every turn as memory; agents write memories only by calling Mneme tools such as memory_register, memory_summarize, and memory_forget.

Tests

The package has a non-live test suite covering auth seeding, Pi model config generation, the harness contract, memory tool wiring, wake and turn traces, and the org observer:

npm test
npm run typecheck
npm run build

These tests do not call a model provider.

Model And Auth Helpers

The Pi adapter supports the same model intent shape Spawnfile lowers for Pi:

• OpenAI Codex subscription auth maps to Pi's openai-codex OAuth auth store.
• Claude Code subscription auth maps to Pi's Anthropic auth store.
• API-key credentials can be written directly into Pi auth storage.
• Local and custom OpenAI-compatible endpoints render Pi models.json.

For Ollama-style local models, use a local endpoint with auth.method: none. Pi still requires an API-key field for custom providers, so the helper writes the upstream-documented dummy ollama value.

Pi E2E

The Pi E2E uses the local Codex CLI subscription auth file to seed an ignored Pi auth.json under .runtime/.

These are live runs: they spend real tokens and require local engine auth (~/.codex/auth.json for Pi/Codex; mixed-engine and triad additionally need authenticated grok and agy CLIs on PATH). They are not part of npm test.

npm install
npm run e2e:pi-agent
npm run e2e:pi-memory-org
npm run e2e:mixed-engine-org
npm run e2e:jungian-play-org
npm run e2e:jungian-triad-org

The example starts two harnessed Pi agents from plain caller code. The example creates the workspaces and shared resource itself to demonstrate the intended boundary: the caller prepares files, the harness runs agent turns.

The memory-org example starts three harnessed Pi agents, gives each agent a private marker memory, clears Pi session history, then runs a room-style recall conversation. It restarts one agent again before the final check, so the final answer must come from Daimon's persisted memory rather than Pi's live chat session.

The mixed-engine example starts a small org backed by real local CLIs: Navigator uses Codex, Cartographer uses Grok, and Sentinel uses Agy. Each engine invents its own private signal, then the room conversation verifies that later turns recall those LLM-generated signals through Daimon memory.

The Jungian play example starts two selves as characters in a play. Each self has archetype voices such as Persona, Shadow, Anima/Animus, Wise One, Great Mother, Hero, and Trickster. The inner voices run first, the representative self then speaks externally, and the run writes play traces plus memory/latency telemetry under .runtime/jungian-play-org/.

The Jungian triad example uses three complete Jungian selves in one conversation: Maya speaks through Codex CLI, Leo speaks through Grok, and Priya speaks through a Pi agent seeded from local Codex subscription auth. All three selves carry the same full archetype set, rotated through the run so every archetype gets consulted.

Design Notes

• MEMORY-SYSTEM.md describes the implemented scoped memory runtime.
• ENGINE-SYSTEM.md describes the engine abstraction plan: Pi, local/API model providers, and CLI-backed engines such as codex, claude, grok, and agy.
• Mneme is a sibling package, @noopolis/mneme, published separately and used by Daimon in-process for Pi agents. Other runtimes can use Mneme through its MCP server. The agent-facing tools stay named memory_search, memory_register, and memory.* at the protocol boundary because those names are clearer to agents.