aigent-os

Claude Code harness and alternative to context compaction: at 80% context it writes a verified capsule, runs /clear and resumes with persistent memory in git.

View the Project on GitHub wrg32786/aigent-os

Getting Started with aigent-OS

Prerequisites

Required for the default managed install:

  1. Claude Code in the CLI, desktop app, or an IDE integration.
  2. Bash for installation and hook scripts.
  3. Node.js 18 or newer for the managed Auto-Refresh runner and semantic search.

Optional:

Use --no-deps only for an explicit unmanaged fallback without the managed PTY transport.

The Markdown kernel and normal vault workflow do not require a database or server.

Installation modes

The installer supports two explicit modes.

Activate the downloaded checkout in place

Open a terminal in the downloaded aigent-os directory and run:

bash install.sh

This leaves the source tree in place, installs and verifies the managed Auto-Refresh dependencies, configures .claude/, and wires the aigent command plus the platform launcher.

To deliberately skip Node dependencies and use the unmanaged fallback:

bash install.sh --no-deps

Install into another working directory

bash install.sh --target /path/to/your/project

A positional target remains supported:

bash install.sh /path/to/your/project

Flags may appear before or after the target:

bash install.sh --no-deps --target /path/to/your/project
bash install.sh /path/to/your/project --no-deps

Preview the installation without changing anything:

bash install.sh --target /path/to/your/project --dry-run

Run bash install.sh --help for the complete command reference.

What the installer changes

For an external target, the installer:

The npm step can use the network. Launcher wiring writes the user-level PATH/profile or platform shortcut; the remaining installer work stays inside the target directory.

Rerunning the installer is safe and idempotent for managed configuration. It refreshes the marked CLAUDE.md and .gitignore blocks, merges settings, and preserves existing framework and user files. It is deliberately conservative rather than pretending every customized installation can be upgraded by blindly overwriting files.

First session

Open a new terminal and run:

aigent

The installed front door starts Claude inside the managed runner. On the first launch it invokes /start, which owns first-run detection and onboarding, records setup progress in .aigent/state.json, learns the operator’s context, produces a first usable artifact, and marks setup ready only after durable writes succeed.

Use /setup later for deeper configuration or to revise identity, priorities, authority boundaries, decision logic, projects, people, or agent definitions.

Normal session flow

The lifecycle is two verbs, and both fire automatically at their hook points; you rarely invoke them by name. See two-verb-lifecycle.md.

  1. /resume loads the newest valid capsule by created_at, re-grounds on recent context and open threads, and acts on next_valid_action. It auto-fires on SessionStart(clear) via daemons/resume-verb.mjs; a warm reinject (showing the newest active capsule) runs on every other SessionStart source.
  2. Work normally. Skills and hooks route tasks, capture privacy-safe action metadata, and update durable notes when appropriate. A rolling, best-effort capsule autosave runs on every Stop (daemons/stop-capsule-writer.mjs).
  3. /context-capsule reconciles and writes a resume-ready capsule, then stops; invoke it for a deliberate mid-session checkpoint or a clean end-of-thread finalize. The autosave already covers the case where you just walk away.

/open and /close are retired (the skill files remain but are deprecated). The installed aigent front door is the default: it watches context pressure, requests and verifies one capsule, submits one clear, binds the fresh SessionStart identity, and sends one resume wake. /context-capsule, /clear, and /resume remain available for deliberate manual use, but they are not the normal operating path.

State layout

There are two memory trees, and both are actively written across sessions. They are not a clean “operator vs framework” split (an earlier version of this doc claimed root memory/ was framework-index-only; that was inaccurate).

vault/memory/: the operator’s flat ledgers

vault/
  daily/                         Date-stamped session notes
  projects/                      Project notes
  people/                        People and role context
  concepts/                      Durable doctrine and reusable knowledge
  agents/                        Human-readable agent definitions
  memory/                        Flat Markdown/JSON ledgers: no subdirectories:
    ACTIVE_PRIORITIES.md  DECISION_LOG.md  DECISION_OUTCOMES.md
    DELEGATION_TRACKER.md  SESSION_LOG.md  HONESTY_LEDGER.md
    MEMORY_CANDIDATES.md  BODY_STATE.json  AGENT_FITNESS.md  …
    capsules/                    Resume-ready capsules (created at runtime)

root memory/: framework indexes + the cognitive/runtime layer

memory/
  SKILL_LEDGER.md  SKILL_GAPS.md  SKILL_CHAINS.md    Caddy + capability-expansion indexes
  facts/                                             Temporal fact ledger (facts.jsonl)
  runtime/                                           Cognitive layer, written every session:
    ACTIVE_STATE.json  SELF_MODEL.json  GOAL_STACK.json  BELIEF_STATE.jsonl
    LESSONS.jsonl  PROCEDURES.jsonl  DREAM_LOG.md  STATE_EVENTS.jsonl
    improvements/                                    /meta-improve candidate reports

Root memory/ is not a passive index area: daemons plus the /dream, /meta-improve, /status, and /reconcile skills all read and write memory/runtime/ every session.

[!warning] Known path inconsistency (code issue, not a doc issue) daemons/runtime/update-active-state.py writes ACTIVE_STATE.json to vault/memory/runtime/, but every reader (/status, /reconcile) reads it from root memory/runtime/, which is the only populated copy on disk. This split should be reconciled to one canonical path; it is tracked separately from this docs pass.

Generated local state

.aigent/ contains installation state, close markers, caches, and backups. It is excluded from version control by default.

Customization

Start with:

Use the setup skills rather than editing every file manually unless direct editing is preferable. Every important state remains readable Markdown or JSON.

Diagnostics

Run:

bash scripts/doctor.sh

To inspect another installation:

bash scripts/doctor.sh /path/to/install

Common checks:

Security

Read install-security.md before installing into a sensitive project. Hooks run with the user’s permissions, and the vault can contain private operational context. Use full-disk encryption when the threat model requires encryption at rest, and never commit .aigent/ or generated embedding indexes.