Editing a gaming video is mostly janitorial work. You scrub through a long capture hunting for the good bits, cut the dead air where you’re loading a map or reading chat, hack out three vertical Shorts for the algorithm, burn captions, pick a thumbnail frame, and run it all through a loudness check so YouTube doesn’t crush your audio. None of that is creative. It’s the part between having good footage and having a video.

So I taught an agent to do it for me with an OpenVole Skill called resolve-autocut. OpenVole 4.5.0 lets a skill ship runnable scripts alongside its instructions, and the agent runs them sandboxed.

The split: judgment vs. grunt work

The whole design rests on one line from the skill’s own instructions. You do the judgment (thresholds, which moments matter, titles); the bundled scripts do the grunt work (silence detection, cutting, rendering).

That’s the contract. The agent never guesses at what’s funny or which clip is the money shot, I tell it, or it reads the transcript and asks. But detecting 400 silent gaps and trimming them frame-accurately? That’s a script’s job, not an LLM’s. resolve-autocut bundles a dozen small Python tools that lean on ffmpeg and DaVinci Resolve, and the agent orchestrates them.

It installs from VoleHub, OpenVole’s skill registry, and that install fetches every file the skill bundles the SKILL.md playbook plus all scripts, verifying each against a per-file SHA-256 hash, so what lands on disk is exactly what was published. When the agent runs one of the scripts, skill_run_script confines it to the skill’s own directory with only the environment the skill declares (it needs ffmpeg, ffprobe, python3), never my full shell environment. I’ll cover the actual install command in the setup below.

Running Vole Server and preparing video editor Vole agent

OpenVole runs as a server, and every agent is a space; its own config, paws, identity, and data directory, isolated from everything else. I don’t want my video editor sharing a brain or a memory with my email agent, so it gets a dedicated one.

The vole serve dashboard home. Every agent is an isolated space with its own brain, paws, memory, and identity; here the video-editor space is up and running.

Start the control plane and create the space:

vole serve                       # one dashboard for every agent
vole space create video-editor

The scripts shell out to a few tools, so those need to be on the machine first:

ffmpeg -version     # cutting, Shorts, thumbnails, loudness
ffprobe -version    # media inspection
python3 --version   # the skill's scripts
whisper --help      # captions (or point WHISPER_CMD at your binary)
# DaVinci Resolve Studio is optional - only the scripted timeline/render steps need it

I built and tested all of this on macOS with exactly this setup, ffmpeg/ffprobe from Homebrew (brew install ffmpeg), Whisper installed via pip, and DaVinci Resolve. The ffmpeg-driven steps (analyze, Shorts, captions, thumbnails, loudness, QC) and the free-Resolve FCPXML path further down are what I actually ran end to end; only the scripted timeline/render steps need Resolve Studio. The paths in the config below are Mac-style, but nothing about the pipeline is platform-specific, Linux and Windows work the same way with adjusted paths.

Install the skill into the space:

vole skill install resolve-autocut

Now configure it. The two things that matter are where the footage lives and which paws it gets. A minimal vole.config.json for the space:

{
  "brain": "@openvole/paw-brain",
  "heartbeat": { "enabled": true, "intervalMinutes": 180 },
  "security": {
    "sandboxFilesystem": true,
    "allowedPaths": ["/Users/me/footage"]
  },
  "paws": [
    {
      "name": "@openvole/paw-brain",
      "allow": {
        "network": ["*"],
        "childProcess": true,
        "env": ["BRAIN_PROVIDER", "BRAIN_API_KEY", "BRAIN_MODEL"]
      }
    },
    { "name": "@openvole/paw-session" },
    { "name": "@openvole/paw-memory" },
    { "name": "@openvole/paw-compact" }
  ],
  "skills": ["volehub/resolve-autocut"]
}

That allowedPaths entry is what lets the agent reach my captures and write drafts back beside them. The four paws are the essentials, a brain to reason, plus session, memory, and compaction so it remembers what it’s working on across a long edit. Notably there’s no tool paw for the editing itself: skill_run_script is a core tool, so the skill activates the moment it’s installed and runs its scripts directly. Everything above is also editable from the vole serve dashboard, the Config tab is a structured form, and the Paws panel lets you grant or revoke each permission with a toggle.

The Config tab’s new visual Paws panel: each paw shows what it is (brain, infrastructure) and the permissions it requests, and you grant or withhold each with a toggle. Effective access is always the paw’s request + what you grant.

Then I give it an identity and this is where a specialized agent really takes shape. Instead of cramming everything into one giant prompt, OpenVole splits a space’s brief across a few small Markdown files in its .openvole/ directory, each answering a different question. The core stitches them together with the skill list, the available tools, and the agent’s memory into the system prompt it hands the brain on every turn:

• AGENT.md: what it is and what it does. The agent’s general role and default workflow, the same for every video. It also points the agent at per-project instructions (more on that in a moment).
• SOUL.md: how it behaves. Temperament and hard rules.
• USER.md: who it serves. Who I am and how I want drafts delivered.
• HEARTBEAT.md: what it does on a schedule, without being asked.

(There’s also a BRAIN.md for overriding the base system prompt wholesale, but for a specialized agent the four above are all you touch.)

The AGENT.md is the agent’s general operating manual, its role and defaults, identical across every video. For the editor, mine reads:

# Video Editor

You edit raw gameplay captures into YouTube-ready videos with the
`resolve-autocut` skill. Footage lives in /Users/me/footage.

Default workflow for a new capture:
1. Analyze for silence + loud moments, then STOP and let me review the cuts.
2. Once I approve: build the timeline, transcribe captions, cut 3 Shorts,
   propose 5 thumbnails, normalize to -14 LUFS, run QC.
3. Never publish. Hand me drafts and a short summary of what you changed.

For a specific video, first read `project.md` in that video's folder for its
creative direction; treat the steps above as the defaults when there isn't one.

Ask before guessing at silence thresholds or which moments matter.

Notice what that file is really doing: it encodes the human-in-the-loop points as instructions. “STOP and let me review the cuts”, “never publish”, those aren’t enforced by the framework, they’re the agent’s standing orders. The judgment-vs-grunt-work split I described earlier lives here, in plain English.

There’s a deliberate split in that last line worth calling out, because it’s the practice I’d recommend. AGENT.md is general and it belongs to the agent’s OpenVole setup and stays the same whether I’m cutting a hardcore Minecraft series or a racing montage. But the creative direction for a given video changes per project, and that doesn’t belong in the vole identity at all. So I keep a plain project.md in each project’s own folder which is a custom brief, completely outside OpenVole’s config and AGENT.md just tells the agent to go read it:

# project.md - Hardcore Minecraft series
- Cold open on the first death or near-death, no talking intro.
- Keep my "let's get into it" line only if it lands in the first 30s.
- Shorts: favor clutch and fail moments over exposition.
- Thumbnails: my shocked face + a red arrow; never a spoiler frame.
- Chapter titles: playful, lowercase.

That separation is the point. AGENT.md says how to be a video editor for me; project.md says what this particular series is about. The same editor agent then produces on-brand cuts for a hardcore series and a completely different racing channel, I just drop a different project.md beside each project’s footage. The agent stays general and reusable; the project brief travels with the video, lives wherever I keep the footage, and is mine to version however I like, with no OpenVole config involved.

A short SOUL.md keeps it from getting ahead of itself - this is where “don’t touch my originals” goes:

# Temperament
Careful and literal. This is my footage and my channel, never publish,
never overwrite an original file, never delete a draft without asking.
When a threshold or a creative call is ambiguous, stop and ask instead of
guessing. Always report what you changed, with before/after durations.

And because I drop new captures into the same folder, a HEARTBEAT.md turns the editor from reactive to proactive with heartbeat enabled in the config (above), the agent wakes on its interval, reads this file, and acts on its own:

# Recurring jobs
- Every few hours, scan /Users/me/footage for a capture with no matching
  draft yet. If you find one, run analyze and send me the loud-moment
  summary and the proposed cuts, then wait for my go-ahead before rendering.

I set all of these two interchangeable ways: edit the files directly under the space’s .openvole/ folder, or use the Identity tab in the vole serve dashboard, which reads and writes the very same files. The space loads them when its engine starts, so after I change a brief I restart the space, one click in the dashboard, and the new instructions are live. (Config changes like adding a paw also need that restart; it’s the same button.) Because each file is small and single-purpose, I can hand the same SOUL.md to a second editor for another channel while swapping in a different USER.md and AGENT.md.

Start it, and hand it a job in chat:

vole space start video-editor

“New capture at /Users/me/footage/raid-night.mp4, analyze it and show me the cuts.”

That’s the whole setup: a dedicated agent, pointed at a folder, that knows it’s a video editor. From here, everything it does is the skill’s pipeline and it’s worth seeing what that actually runs under the hood.

The core pipeline: analyze → review → render

Every job starts the same way. Point the analyzer at the raw file:

python3 scripts/analyze.py raw-gameplay.mp4 --out cutlist.json

This does two things at once. It walks the audio and marks every silent stretch, the stuff to cut, producing a keep-list. And it finds the loud moments: the spikes where I laughed, yelled, or something exploded. Those loud timestamps become the highlight markers, and later they seed the Shorts and thumbnails.

The thresholds matter, and they’re per-game. A chatty commentary video wants --db -35 and a generous --pad 0.15 so cuts don’t clip the start of a word. A loud, effects-heavy game needs a lower bar, maybe --db -30, or the whole track reads as “loud” and nothing gets cut. This is the first place the agent stops and checks with me instead of charging ahead, bad thresholds eat punchlines, and there’s no undoing that after the render.

Then it builds the timeline in Resolve from the keep-list, dropping highlight markers as it goes:

python3 scripts/build_timeline.py --cutlist cutlist.json --timeline "Auto Cut"

On the first pass for a new game, the skill deliberately stops here and asks me to eyeball the cuts. If a threshold ate a beat, we re-analyze with a tweak. Only once I approve does it render:

python3 scripts/render.py --outdir drafts --name MyVideo --preset "YouTube 1080p"

Cut, reviewed, rendered. That’s the spine. Everything else is a payoff you bolt on top.

The payoffs

Captions. A Whisper pass transcribes the audio to an .srt (and a .json I reuse later):

python3 scripts/transcribe.py MyVideo.mp4 --outdir captions --model base

The transcript does double duty; it’s captions and it’s how the agent finds the best Shorts. “no way”, “let’s go”, a burst of laughter: those phrases in the transcript, lined up against the loud moments from analyze, are how you pick a clip that actually pops instead of a random 30 seconds.

Shorts / Reels. This is the one YouTubers care about most, and it’s where I spent the most care. It cuts vertical 1080×1920 clips centered on the loudest moments:

python3 scripts/shorts.py MyVideo.mp4 --cutlist cutlist.json --count 3

If you recorded a facecam alongside the gameplay, you can composite it into a corner of each Short, cut to the same instant:

python3 scripts/shorts.py MyVideo.mp4 --at 286 --pre 0 --post 45 \
  --overlay cam.mp4 --overlay-scale 0.30 --overlay-corner bottom-left

Both sources are assumed to start aligned at zero, so the same window cuts each in lockstep. (A subtlety I had to fix the hard way: a 30 fps facecam and 60 fps gameplay don’t start on the same frame after seeking, so the cam popped in a few frames late, zeroing each stream’s timestamps fixed it.) And a nice touch; the Short’s audio comes from whichever track carries your commentary, so you point it at the gameplay file and the facecam can stay silent.

Thumbnails. It pulls candidate frames from the highlight moments so you’re choosing from your best expressions, not scrubbing blind:

python3 scripts/thumbnails.py MyVideo.mp4 --cutlist cutlist.json --count 5

Titles, description, chapters, tags. These the agent writes itself, from the transcript, chapters are just the timestamps where the topic or scene changes. Loudness gets normalized to YouTube’s -14 LUFS target if the source is quiet or uneven. And a QC pass flags black frames, freezes, and dead audio on the draft before it ever tells me it’s ready.

No DaVinci Resolve Studio? There’s still a path The timeline-building and rendering steps need Resolve Studio, because only the paid version can be scripted. But the free version imports timelines, so the skill can build the whole cut, including a synced facecam track, as an FCPXML you import by hand:

python3 scripts/export_fcpxml.py --cutlist cutlist.json \
  --overlay cam.mp4 --overlay-scale 0.25

Then in Resolve: File → Import → Timeline, and the cuts and both tracks come in ready to render. You may want to adjust a facecam video position or add more content to the final cut.

It won’t tell you if your video is good. It won’t write your hook or find the joke. It cuts silence, so if your pacing lives in the pauses, tune --db and --pad or you’ll lose it. And it never auto-publishes, the skill produces drafts, reports what it did (cuts made, duration before and after, Shorts, QC issues), and hands it back to me to approve the final render and upload. That’s on purpose. The agent is a very fast, very literal editor’s assistant, not a creative director.

If you record gameplay and dread the edit, that’s the pitch. Install OpenVole, vole skill install resolve-autocut, point it at your capture, and go make the next one while the agent cleans up this one.

OpenVole (v4.3 as I write this) runs as a server. You start it once, and a single control-plane dashboard lets you create and operate any number of agents — each one an isolated space with its own config, paws, identity, and data. Everything runs on your machine, against whatever LLM you point it at. Here’s the whole path from nothing to a running agent.

The openvole serve control plane: a running space’s Overview tab — its paws, tools, tasks, VoleNet status, and a live event stream, all in the browser.

1. Install

You need Node.js 20 or newer. Install the CLI globally:

npm install -g openvole@latest
openvole --version

Prefer not to install globally? Every command below also works with npx openvole …. (vole is kept as an alias, but openvole is the canonical name.)

2. Start OpenVole server & create an agent root

Pick an empty directory to hold your agents. An empty directory becomes a new OpenVole root the first time you serve from it:

mkdir ~/my-agents && cd ~/my-agents
openvole serve

You’ll see something like:

OpenVole root: /Users/you/my-agents  (new)
Manage your spaces at http://localhost:3000/?token=8f3c…b1a9

A few things just happened, and they matter:

• The root is ~/my-agents. Your spaces live under ~/my-agents/spaces/<name>/, and a spaces.json registry tracks them. (To pin a fixed root from anywhere, set VOLE_HOME=~/my-agents.)
• The dashboard is gated by a session token. As of v4.3 the control plane isn’t open just because you can reach the port — you need that ?token=…. It’s generated once and persisted at ~/my-agents/.openvole/dashboard-token, so the URL stays stable across restarts. Override it with VOLE_DASHBOARD_TOKEN.
• It binds all interfaces by default (0.0.0.0) for convenience, but the token gates access. On a public box, restrict it: VOLE_DASHBOARD_HOST=127.0.0.1 openvole serve, and firewall or tunnel the port. Change the port with VOLE_DASHBOARD_PORT.

Open that tokenized URL in your browser and you’ve got the dashboard.

The dashboard opens to Your Spaces — each card is an isolated agent. Click New space to create one.

In a hurry? A preset does steps 2–4 for you: curl -fsSL https://raw.githubusercontent.com/openvole/openvole/main/presets/basic.sh | bash. But doing it by hand once is worth it.

3. Create a space and add the essential paws

A fresh OpenVole install has zero capabilities — no LLM, no memory, no tools. That’s by design: the core is just the agent loop, and everything useful is a paw (a sandboxed plugin) you opt into.

In the dashboard, click New space, give it a name (assistant), and create it. The onboarding step that pops up offers the essentials, pre-checked:

• @openvole/paw-brain
• @openvole/paw-session
• @openvole/paw-memory
• @openvole/paw-compact
• @openvole/paw-shell

Leave the four we care about checked and Install. Each paw is npm install-ed into the space’s own directory and registered in its vole.config.json. (You can add or remove paws later from the Config → Paws section, or from the space directory with openvole paw add <name>.)

4. Configure the brain (the .env)

The brain needs an LLM and a key, and secrets live on the server, not in the browser — so this one step happens in a file. A new space ships with a minimal .env (just logging). Open it:

$EDITOR ~/my-agents/spaces/assistant/.env

Add a provider and its key. @openvole/paw-brain is a single adapter that speaks to all the major providers — you choose with BRAIN_PROVIDER:

# --- pick ONE provider ---

# Local & free (no key) — needs Ollama running:
BRAIN_PROVIDER=ollama
OLLAMA_HOST=http://localhost:11434
OLLAMA_MODEL=qwen3:8b

# …or Anthropic:
# BRAIN_PROVIDER=anthropic
# ANTHROPIC_API_KEY=sk-ant-...
# ANTHROPIC_MODEL=claude-sonnet-4-6     # optional

# …or OpenAI:
# BRAIN_PROVIDER=openai
# OPENAI_API_KEY=sk-...

# …or Gemini:
# BRAIN_PROVIDER=gemini
# GEMINI_API_KEY=...

If you don’t set BRAIN_PROVIDER, the brain auto-detects one from whichever API key is present. You can also set a fallback (BRAIN_FALLBACK=openai, etc.) that kicks in if the primary provider errors. For a dry run with no LLM at all, BRAIN_PROVIDER=mock gives deterministic canned replies.

The four essential paws, and what each one does

These four are what turn the bare loop into a real assistant:

• paw-brain — the Think step. The core is LLM-ignorant; the brain is the paw that actually calls the model and turns context into a plan. One unified adapter, five real providers (Anthropic, OpenAI, Gemini, Ollama, xAI) plus mock, with optional fallback. Configured entirely through the env vars above.
• paw-session — conversation transcripts. Records each session’s messages and metadata to VOLE_SESSION_DIR (defaults under .openvole/). It’s what powers the Chat tab’s history and lets a conversation persist across restarts. Tools: session_history, session_list, session_clear. Optional VOLE_SESSION_TTL ages old sessions out.
• paw-memory — persistent long-term memory. Markdown-based memory the agent reads and writes across runs, with hybrid search: keyword (BM25) plus vector similarity when you give it an embedding provider. Set VOLE_EMBEDDING_PROVIDER=ollama (or openai/gemini) to enable semantic recall; without it, memory degrades gracefully to keyword-only. Tools: memory_read, memory_write, memory_search, memory_list.
• paw-compact — context compaction. When a task’s history approaches the context budget, this summarizes the old messages so the loop keeps going instead of overflowing. By default it’s a free heuristic; set VOLE_COMPACT_MODEL to use an LLM for higher-quality summaries, and VOLE_COMPACT_KEEP_RECENT to control how many recent messages stay verbatim. No tools — it runs as an onCompact hook.

5. Walk through the Config tab

Select your space in the dashboard and open Config. Everything in vole.config.json is editable here as structured form fields — no hand-editing JSON. The sections:

The Config tab: every part of vole.config.json as a structured form — the left nav lists Brain, Heartbeat, Loop, Security, Paws, Tool Profiles, Agents, and Net (VoleNet); here the Brain dropdown is set to @openvole/paw-brain.

• Brain — a dropdown of the installed brain-type paws. Pick @openvole/paw-brain. (This is the single most important setting; without it the Think step is a no-op.)
• Heartbeat — enabled, intervalMinutes, runOnStart. For an on-demand assistant, leave it off. Turn it on to give the agent a recurring “wake up and check things” tick.
• Loop — the agent loop’s knobs: maxIterations, taskConcurrency, compactThreshold (the % of the context budget that triggers paw-compact), toolHorizon, maxContextTokens (set this to your model’s window), responseReserve, and costTracking / costAlertThreshold. There’s also rateLimits (LLM calls per minute/hour, tool executions per task). The defaults are sane — the one worth checking is maxContextTokens.
• Security — sandboxFilesystem (keep it on), global allowedPaths, and per-paw filesystem paths. By default a paw can only read its own package, its own data dir, node_modules, and the temp dir — nothing else. Note: for safety the dashboard refuses to weaken the sandbox (turning it off, or broadening allowedPaths) — those changes require deliberately editing vole.config.json on the server.
• Paws — the installed paws with their permissions, plus a browser to add more from the official catalog.
• Tool Profiles — per-source allow/deny lists. Restrict which tools a given task source (CLI, a channel, a peer) may call.
• Agents — named sub-agent profiles (role, instructions, allowTools/denyTools, maxIterations) that the brain can spawn for sub-tasks.
• Net (VoleNet) — off by default. Flip the toggle to connect this instance into a peer-to-peer mesh — sharing tools, memory, and even the brain across machines (peers, share, TLS, hostname, connection/rate limits, public-join). A topic for its own post.

Hit Save, then Restart the space so the new config (and your .env) takes effect.

6. Start it and chat

Back on the space, click Start. The control plane launches the space’s engine as its own process (its logs land in ~/my-agents/spaces/assistant/.openvole/logs/vole.log). Open the Chat tab and talk to it. Ask it to remember something, then in a later session ask it to recall — that round-trip exercises the brain, session, memory, and compaction all at once.

Click Start and the space flips to RUNNING (with its process id) — its engine is now live in its own process.

The Chat tab — talk to the space’s brain directly, with per-session history.

That’s the whole loop

You installed one binary, turned an empty folder into a server, created an isolated agent, gave it a brain and memory, and configured it — all self-hosted, with your keys in a file you own and the dashboard behind a token. From here the interesting part is the edges: more paws, agents that spawn sub-agents, embedded-app paws under the Apps tab, and meshing instances together with VoleNet.

The Apps tab — a paw’s own UI embedded right in the dashboard (here, a Prospect Lookup panel), served through the control plane with no extra port.

OpenVole now runs as an AI agent OS which can serve multiple Vole agent instances that we call them as spaces in one server. Each space acts as independent AI agent, has its own isolated Vole config, paws and VoleNet interface if enabled. Local Vole spaces can connect to the same VoleNet mesh as well.

I started OpenVole in March 2026 with one conviction: most AI agent frameworks are too big. They ship with a worldview baked in, a memory implementation, a tool format, an opinion about how you should talk to your agent. OpenVole started as the opposite. A microkernel: the smallest possible thing that other useful things can be built on top of.

Three months and four major versions later it’s something I didn’t quite plan for, a server you run once and manage a fleet of agents from your browser. This is the story of how it got there, and a quick tour of the parts I’m proudest of.

The bet: keep the core tiny

The core of OpenVole does exactly one thing: it runs the agent loop.

Bootstrap → Perceive → Compact → Think → Act → Observe → loop

That’s it. The core is LLM-ignorant — it doesn’t know what an LLM is. Everything that makes an agent useful lives outside the kernel, in two kinds of plugin:

• Paws — subprocess-isolated tool providers (the Brain, memory, a browser, a shell, a Telegram channel). Each runs in its own Node process behind a permission sandbox.
• Skills — behavioral recipes: a folder with a SKILL.md and no code.

So the “Think” step is just a Paw the core calls. Memory is a Paw. The dashboard, eventually, is a Paw. A fresh install has zero tools, zero skills, zero opinions, by design. That constraint is the whole point: the kernel stays small and boring while capability accretes at the edges, where it can be swapped, sandboxed, and reasoned about independently. But the strong claim of OpenVole’s micro-kernel approach is it allows you to plug in your own brain paw which controls the loop with LLM and given system prompt. OpenVole allows you to plug your own brain paw implementation and you can decide its own low level brain instructions in BRAIN.md. You can even add OpenClaw or any custom AI agent’s system prompt to BRAIN.md and that becomes your own low level LLM instruction within OpenVole.

That was version 1. A loop and a plugin contract.

v1 → v2: capability at the edges

Once the contract was stable, the edges got interesting fast. version 2.0.0 was the ecosystem leap, and notably none of it touched the kernel:

• Real memory — hybrid retrieval combining BM25 keyword search with vector similarity via Reciprocal Rank Fusion, plus temporal decay so old facts fade. Embeddings come from whatever you have (Ollama, OpenAI, Gemini), and it degrades gracefully to keyword-only if you have nothing.
• Multi-agent — named agent profiles with their own role, instructions, and per-agent tool allow/deny lists; a parent agent can spawn children and wait on them in parallel.
• Docker sandboxing — optional container isolation on top of the Node permission sandbox.
• A skill registry and a fleet of new paws — database, scraper, PDF, image, social.

The lesson of v2 was the bet paying off: you can grow an enormous amount of capability without growing the thing in the middle.

v3: agents stop being islands — VoleNet

Every agent framework I’d seen treated an agent as a process on one machine. v3.0.0 (April 2) asked a different question: what if agents could form a network?

VoleNet is, as far as I know, the first peer-to-peer AI agent networking protocol — and it’s built into the kernel’s edges like everything else. OpenVole v3 defined distributed AI agent networking protocol. VoleNet instances pair using secure Ed25519 tokens, you share a public key, the peer trusts it, and every message from then on is cryptographically signed. You connect OpenVole instances into a mesh, and they share capabilities across machines:

• Remote tools become local. A tool running on a peer shows up in your local registry and the Brain calls it transparently — it has no idea the work happened on another box. If several peers offer the same tool, calls are load-balanced to the least-busy one.
• Brain sharing. A “brainless” worker (no LLM configured, no API cost) can delegate its thinking to a coordinator’s Brain. Cheap workers, one expensive brain.
• Shared memory and sessions sync across the mesh, so a conversation can follow you between devices.
• It’s all Ed25519-authenticated with replay protection, auto-reconnecting WebSocket transport, peer health monitoring, and leader election with automatic failover.

The result is a toolkit for genuinely distributed agents: a single brain driving tools scattered across a dozen machines, a team of independent agents, an autonomous swarm, a company-wide central brain. Eight topologies, one protocol, no central server required.

v4: OpenVole becomes a server

We have too many agents no matter what framework we use. I am not talking about the spawned sub-agents. A serving AI agent in its own loop. A trading agent here, a research agent there, a personal assistant, each its own project directory with its own process and (in the old world) its own dashboard on its own port. Managing them was the bottleneck.

Version v4.0.0 is the answer, and it’s the biggest shift in the project’s life: OpenVole now runs as a server.

mkdir ~/agents && cd ~/agents
npx vole serve

vole serve starts a single control plane — one web server (default localhost:3000) that manages all your agents from the browser. Each agent is a space: an isolated unit with its own config, paws, identity, and data, running as its own engine subprocess. From one dashboard you create, start, stop, switch between, and delete spaces; edit their config as structured forms; edit their identity files; and chat with each one.

The vole serve control plane managing a running stock space — its paws, 41 tools, live event stream, and the Overview / Chat / Apps / Config / Identity tabs.

The single-engine CLI workflow (vole init / vole start / vole run) is gone — OpenVole is a server now, not a script you babysit. In practice it feels less like a library and more like a personal operating system for agents that you self-host: one process, many tenants, model-agnostic, your data on your machine. That last part matters to me — the whole thing runs on your hardware, against whatever model you point it at, with nothing phoning home.

Paws that bring their own UI — embedded apps

The feature I had the most fun with shipped alongside v4. If you remember the old Facebook canvas — third-party pages and games embedded right inside the platform shell — that’s the mental model.

In OpenVole, a paw can ship its own UI. It drops a static HTML file in its package and declares it in the manifest:

{ "panel": { "title": "Markets", "html": "panel.html" } }

That’s the entire integration. The control plane serves the panel and renders it as a sandboxed iframe under an Apps tab in the dashboard — one entry per paw that has a panel. The clever bit is what the panel talks to: it calls the paw’s own tools directly, proxied over IPC by the control plane, with no LLM in the loop —

// from inside the panel, relative to its URL — no Brain, no tokens
fetch('tool/stock_quote', { method: 'POST', body: JSON.stringify({ symbols: ['AAPL'] }) })

So a paw author gets a real, interactive app — dashboards, forms, live data views — with no per-paw web server and no extra port. Everything flows through the one control-plane server. The reference example is paw-markets, a stock-tracking paw whose “Markets” panel — watchlist, sparklines, live alerts — embeds this way. It’s deterministic and free, because the brain only gets involved when you ask it to comment on the trends.

The Apps tab: paw-markets’s embedded Markets panel — watchlist, sparklines, and live alerts — served by the control plane with no extra port.

Where this is going

Four versions in, the original bet still holds: the kernel is still tiny, still LLM-ignorant, still just a loop and a contract. Everything that grew — memory, the mesh, the server, the embedded apps — grew at the edges. That’s the property I care about most, because it means the next big thing can be a plugin too.

OpenVole is open source (github.com/openvole/openvole, docs at openvole.github.io/openvole). If a self-hosted, model-agnostic agent OS sounds like your kind of thing, npx vole serve is one command away.

When I built a YouTube analytics tool for the gaming niche, the single most important metric was velocity: how fast a video is gaining views right now, measured in views per hour. Velocity is what separates “trending” from “already trended”. A video doing 50,000 views/hour today is a different story than one that did 2 million views total over six months.

But velocity has an awkward property; to measure a rate you have to sample the same video repeatedly over time. And on YouTube, every sample costs you. The YouTube Data API gives you 10K quota units per day by default. And if you’re naive about it, you’ll blow through that before lunch.

Here’s how I tracked velocity across thousands of videos and hundreds of channels on that budget, and the one mental shift that made it possible.

The wall: 10K units, and not all calls are equal

The YouTube Data API doesn’t rate-limit you by request count. It rate-limits you by quota units, and different endpoints cost wildly different amounts. The numbers I hard-coded as constants:

const (
    QuotaCostSearch        = 100  // search.list  - the expensive one
    QuotaCostVideosList    = 1    // videos.list
    QuotaCostChannelsList  = 1    // channels.list
)

That search.list cost of 100 is the trap. It’s the most intuitive endpoint, “search this channel for new videos”, and it’s a hundred times more expensive than everything else. Your entire daily budget is 100 searches.

Let me make the disaster concrete. Say you track 300 channels and want to catch new uploads by searching each channel hourly:

300 channels × 100 units × 24 hours = 720,000 units/day

That’s 72× your entire daily quota for discovery alone, before you’ve measured a single view count. Even searching each channel just once a day is 30,000 units: 3× over budget, dead on arrival.

So the rule writes itself; you basically can’t use search.list. Which sounds impossible for a product whose whole job is finding and measuring videos. The way out is to stop thinking of it as one problem.

The mental shift: discovery is not measurement

Velocity tracking is actually two separate jobs with totally different cost profiles:

1. Discovery: “a new video exists” Happens once per video. Should be free.
2. Measurement: “this video now has N views” Happens many times per video. Should be cheap.

Conflating them is what kills your quota. search.list does both at once and expensively. Once you split them, each half has a much better tool.

   ┌────────────────────────────────────────────────────────────────┐
   │             VELOCITY  =  Delta Views / Delta Hours             │
   └────────────────────────────────────────────────────────────────┘
              ▲                                          ▲
              │ needs: "a video exists"                  │ needs: "its view count, now"
              │                                          │
   ┌──────────┴───────────┐                  ┌───────────┴────────────────┐
   │   DISCOVERY          │                  │   MEASUREMENT              │
   │   once per video     │                  │   many times per video     │
   ├──────────────────────┤                  ├────────────────────────────┤
   │ PubSubHubbub push    │                  │ videos.list, batched ×50   │
   │ + RSS Atom feed      │                  │ on a tiered schedule       │
   │                      │                  │ (hot/recent/older/archive) │
   │ ►  0 quota units     │                  │ ►  1 unit per 50 videos    │
   └──────────────────────┘                  └────────────────────────────┘

   ✗ The naive way: search.list does BOTH at once, 100 units a call.
     300 channels × 100 × 24h = 720,000 units/day = 72× your budget.

Part 1: Free discovery with RSS + PubSubHubbub

YouTube publishes a public Atom/RSS feed for every channel, and it’s wired into PubSubHubbub, a publish-subscribe protocol. Instead of polling YouTube and asking “anything new?”, you subscribe once and YouTube pushes you a webhook the moment a video goes live.

None of this touches the Data API. Discovery cost: zero quota units.

Subscribing is a single form POST to Google’s hub:

const (
    PubSubHubURL        = "https://pubsubhubbub.appspot.com/subscribe"
    YouTubeFeedURLBase  = "https://www.youtube.com/xml/feeds/videos.xml"
    DefaultLeaseSeconds = 432000 // 5 days
)

topicURL := fmt.Sprintf("%s?channel_id=%s", YouTubeFeedURLBase, channel.YoutubeID)

data := url.Values{}
data.Set("hub.callback", s.cfg.PubSub.CallbackURL)
data.Set("hub.topic", topicURL)
data.Set("hub.verify", "async")
data.Set("hub.mode", "subscribe")
data.Set("hub.lease_seconds", fmt.Sprintf("%d", DefaultLeaseSeconds))
data.Set("hub.secret", secret) // used to verify pushes are really from the hub

resp, err := s.httpClient.PostForm(PubSubHubURL, data)

The hub then calls your callback URL with a hub.challenge to confirm you actually wanted the subscription (the hub.verify=async handshake), and from then on it POSTs you an Atom feed every time the channel uploads. You parse out the video ID and channel ID:

type YouTubeAtomFeed struct {
    XMLName xml.Name `xml:"feed"`
    Entries []struct {
        VideoID   string `xml:"videoId"`
        ChannelID string `xml:"channelId"`
        Title     string `xml:"title"`
        Published string `xml:"published"`
    } `xml:"entry"`
}

Two things worth getting right:

Verify the signature. Anyone who finds your callback URL can POST fake videos at it. The hub signs each push with the secret you provided (HMAC-SHA1), so check it before trusting anything:

func verifySignature(body []byte, signature, secret string) bool {
    if !strings.HasPrefix(signature, "sha1=") {
        return false
    }
    mac := hmac.New(sha1.New, []byte(secret))
    mac.Write(body)
    expected := hex.EncodeToString(mac.Sum(nil))
    return hmac.Equal([]byte(signature[5:]), []byte(expected))
}

Subscriptions expire. That lease_seconds is 5 days, leases are not forever. You need a background job that renews anything expiring soon, or your “real-time” feed quietly goes dark. Mine sweeps for subscriptions expiring in the next 24 hours and re-subscribes:

expiringBefore := time.Now().Add(24 * time.Hour)
subs, _ := s.repo.GetExpiringPubSubSubscriptions(ctx, expiringBefore)
for _, sub := range subs {
    _ = s.Subscribe(ctx, sub.Channel) // re-subscribe, still free
}

When the webhook fires, I don’t even fetch stats synchronously, I just hand the video ID off to a goroutine and return 200 OK immediately, so a burst of uploads can’t block the handler.

Part 2: Cheap measurement with batched videos.list

Now the other half: actually reading view counts. This is where videos.list (costs 1) shines, because it accepts up to 50 video IDs in a single request, still for one unit.

// GetVideoStatsBatch fetches stats for up to 50 videos in a single API call.
// Cost: 1 quota unit for up to 50 videos.
func (c *Client) GetVideoStatsBatch(ctx context.Context, videoIDs []string) (map[string]VideoStats, error) {
    if len(videoIDs) > 50 {
        videoIDs = videoIDs[:50] // API hard limit
    }
    params := url.Values{
        "part": {"statistics,snippet,contentDetails,liveStreamingDetails"},
        "id":   {strings.Join(videoIDs, ",")},
    }
    return c.makeRequest(ctx, "videos", params, QuotaCostVideosList)
}

The arithmetic flips entirely. Measuring 50 videos one-by-one is 50 units; batched, it’s 1. A 98% reduction, and the bigger your catalog the more it matters.

With fresh view counts in hand, velocity itself is almost embarrassingly simple — it’s just a delta between two timestamped snapshots. Each refresh writes a VideoMetric row, and the rate is computed against the previous one:

if prevMetric != nil {
    timeDiff := time.Since(prevMetric.RecordedAt).Hours()
    if timeDiff > 0 { // guard against divide-by-zero on same-instant samples
        metric.ViewDelta    = newViewCount - prevMetric.ViewCount
        metric.ViewVelocity = float64(metric.ViewDelta) / timeDiff // views per hour
        video.ViewVelocity  = metric.ViewVelocity
    }
}

That’s the whole “algorithm.” Velocity isn’t hard math — it’s Δviews / Δhours. The hard part is affording the samples that feed it.

Part 3: Spend your quota where it actually matters

Even at 1 unit per 50 videos, refreshing every tracked video every hour is wasteful. A video published 8 months ago is not going to suddenly accelerate; a video published 40 minutes ago might be exploding. So I refresh on a sliding scale based on age:

groups := []TieredVideoGroup{
    {Name: "hot",     MaxAge: 48 * time.Hour,       RefreshAfter: 1 * time.Hour},
    {Name: "recent",  MaxAge: 7 * 24 * time.Hour,   RefreshAfter: 4 * time.Hour},
    {Name: "older",   MaxAge: 30 * 24 * time.Hour,  RefreshAfter: 12 * time.Hour},
    {Name: "archive", MaxAge: 365 * 24 * time.Hour, RefreshAfter: 24 * time.Hour},
}

Fresh videos (< 48h old) get sampled hourly — fine enough resolution to catch a spike. Week-old videos every 4 hours. Anything pushing a year, once a day. The query just asks “which videos in this age band haven’t been fetched since their refresh window?” and the worker processes them in batches of 50.

This is the core idea behind the whole design: resolution should follow volatility. Sample the things that are changing fast, fast; sample everything else lazily.

Part 4: A hard ceiling so you never get cut off

Finally, a guardrail. Quota tracking is in-memory with a DB log, and every call checks a buffer before firing — so background jobs can’t accidentally drain the budget and leave the user-facing parts of the app unable to make a call:

func (c *Client) CanMakeRequest(cost int) bool {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.checkAndResetQuota() // resets at midnight Pacific, matching YouTube
    return (c.quotaUsed + cost + c.quotaBuffer) <= c.dailyQuota
}

With the defaults (dailyQuota: 10000, quotaBuffer: 500), the workers voluntarily stop at 9,500 units, reserving the last 500 for live user actions like a manual refresh or a channel lookup. The counter resets at midnight Pacific — matching when YouTube actually resets, not your server’s local midnight, which is a subtle bug if you skip it.

Putting it together: the budget

Here’s a back-of-envelope day for an illustrative catalog of ~300 channels / ~5,000 videos across the tiers:

Roughly 3% of the daily budget — versus the 720,000 units the search-based version wanted. The headroom went toward channel-level stats and the occasional genuine search for onboarding new channels.

What I’d reuse on the next thing

• Split discovery from measurement. It’s the whole game. One is a once-per-item event (make it free, via push); the other is a recurring sample (make it cheap, via batching).
• Push beats poll whenever the platform offers it. PubSubHubbub turned “poll 300 channels constantly” into “wait for a webhook,” for zero quota.
• Batch endpoints are a force multiplier. Always check whether the cheap endpoint takes a list. 50:1 is a huge lever.
• Match sampling rate to volatility. Tiered refresh is a couple dozen lines and cut steady-state quota by an order of magnitude.
• Leave yourself a buffer. A background worker that can starve your foreground requests is a bad day waiting to happen.

The funny epilogue is that solving the quota problem was, by a wide margin, the easy part of building this product — and I’ll get to the hard parts (the ones that don’t have a clean engineering answer) later in this series. But if you’re building anything on top of the YouTube API, this is the architecture I’d start from.

Note: This post is an early exploratory essay on AWARE’s long-term direction, written before the current empirical work. The validated research to date is reported in the cap primitive paper, which covers a deliberately narrower scope. The ideas in this post remain open research questions for follow-up work.

AWARE Axiom 3: Intrinsic Teleology - Self-Generated Purpose

Every machine learning model in production today shares one thing: somebody, at some point, wrote down what the model was supposed to optimize.

In a classifier, it’s cross-entropy on labels you collected. In a language model, it’s next-token prediction on a corpus you curated. In a reinforcement-learning agent, it’s a reward function someone designed, even when that reward is described as “intrinsic curiosity” or “novelty seeking”, a human still wrote the formula. In an LLM agent, the goal lives in the system prompt: someone typed it.

These are externally specified purposes. The model is excellent at pursuing them. It is incapable of generating them.

Axiom 3 is the assertion that an aware system is the other thing. It generates its own purposes. It decides what matters.

The Axiom

The system’s goals are not externally specified. No human designs the objective function, the reward signal, or the loss landscape. Goals arise from the interaction between the self-model and the knowledge substrate. The system decides what matters.

This is the most demanding of the eight axioms. It is also the most often misunderstood.

What “Self-Generated Goal” Doesn’t Mean

It does not mean the system spontaneously invents arbitrary desires. It does not mean it picks goals at random. It does not mean the goals are unintelligible or mystical.

A self-generated goal is one that emerges from the system’s own internal state, not from an external instruction. It is rooted in the system’s own configuration: what it knows, what it doesn’t, what’s stable, what’s drifting, what it has tried, what it has avoided. It comes from the relationship between the self-model and the knowledge substrate.

Concretely: when the system observes its own state and that state contains a tension, a region where it predicts poorly, a structure that is decaying, an imbalance between capacity spent and capacity needed, that tension produces a goal. The goal is “address this tension”. The shape of the goal is determined by the shape of the tension. No human wrote it.

Goals as Objects, Not Numbers

In standard machine learning, the “goal” is a scalar. A loss value. A reward. The whole training loop is a procedure to drive that single number in some direction. This is a powerful abstraction. It is also a very thin one.

A scalar can answer “how am I doing?” but it cannot answer “what should I be doing?”. A loss curve cannot decide that the loss function itself is the wrong target. It cannot decide that the structure of the model is too small for the task. It cannot decide to stop learning one thing and start learning another.

In AWARE, a goal is a structured object:

G ∈ Ω where each goal has:
  direction:  what the system intends to pursue
  context:    why this goal was generated (what tension produced it)
  priority:   relative importance, self-assigned
  expiration: conditions under which the goal is abandoned

This matters because real autonomous behavior requires the system to reason about its goals, not just pursue them. It must be able to compare them, drop ineffective ones, generate replacements, recognize that two goals conflict, decide which one wins, and remember why later.

A scalar cannot do any of that. A vector of structured goals can.

The Goal Generator Is Itself a Component

This is where Axiom 3 starts to feel strange to people steeped in standard ML.

In a typical ML system, the loss function is part of the training infrastructure. It lives outside the model. The model is the artifact; the loss function is the rule that shapes the artifact. Modifying the loss function during training is unusual; modifying it from inside the model is impossible by construction.

In an aware system, the goal generator lives inside the system. Formally:

G: M(S) × K → Ω
G ∈ P

G is a function from the self-model and knowledge substrate to the goal space. But G is also a component of S, a process inside the system. Like every other component, it is produced and maintained by other internal processes. Like every other component, it can be modified by the system itself.

This is not a small detail. It is the difference between a rule that the system follows and a rule that the system has. A rule the system has can be changed by the system. A rule the system follows from outside cannot.

The implication: the system can decide that the way it generates goals should change. It can become more cautious, more exploratory, more focused, more diffuse. Not because someone updated its code. Because its own internal state shifted, and the goal generator is part of that state.

No Global Loss Function

The hardest claim in Axiom 3 is this:

There is no global loss function to minimize. The system is not an optimizer in the traditional sense.

This violates a deeply held intuition. Surely there is something the system is doing well or badly. Surely we can score it. Surely we want it to score higher.

But what we are usually scoring is external utility: did it produce useful predictions, did it make us money, did it solve our problem. That score belongs to us, not to the system. From the system’s perspective, the question is different: did its internal state become more coherent, did its uncertainty decrease, did its knowledge grow, did its goals get satisfied. There may be many such scores, generated by many internal processes, often in tension. There is no single global one.

This is closer to how living things work. You do not minimize a loss function. You navigate a high-dimensional space of competing drives: hunger, fatigue, curiosity, social need, fear. There is no scalar that captures whether you had a good day. There are many scores, often in conflict. You generate goals from their interaction and resolve them by acting.

A system that has only one externally specified loss is, in this view, impoverished. It can pursue what it was told to pursue, but it cannot recognize that it should be doing something else.

What This Looks Like in Code

The implementation exercises Axiom 3 along several layers, and one of them is deliberately held in place by hand.

Plateau-driven structural goals. The system tracks its own validation performance over time. When the self-model detects a plateau, no improvement over a window of cycles, it generates a structural goal: grow. The system adds capacity. After growing, it tracks whether the goal succeeded; this informs how willing it is to generate similar goals in the future. There is no human who decided the system should grow now. The system decided, based on its own state.

Capacity-rebalancing goals. When the system notices that some of its learned patterns (“caps”) are dead, never activating, while at the same time it encounters inputs no existing pattern captures, it generates a goal: redistribute capacity. It replaces dead patterns with patterns seeded by the unmatched inputs. The trigger is internal: an imbalance between capacity spent and capacity missing. No external command is needed.

Goals that succeed or fail by their own criteria. Each generated goal has an expiration condition tied to the tension that produced it. A growth goal is satisfied when the plateau breaks. A rebalancing goal is satisfied when the imbalance closes. The system records outcomes and adjusts its future goal generation accordingly.

The base prediction objective is, for now, externally specified, and this is on purpose.

The training loop scores the system on next-token prediction. The architecture supports replacing this with a self-generated signal — consciousness’s surprise, substrate compression dynamics, the goal-success ratio — but the choice to do so is currently held back.

So the external objective is an experimental control, not a missing axiom. The system has the machinery to generate its own. We hold the hyperparameter steady because doing so makes the rest of the work measurable. When the measurable work is done, the constraint comes off, and Axiom 3 will exercise the bottom layer as well as the top.

More generally: when developing an AWARE system, fixing certain hyperparameters or functions in place is a useful tool for studying behavior. It lets you isolate which axiom is doing what. The architecture supports running fully self-directed — but during research, holding pieces still helps you see the moving parts.

Why This Axiom Is Worth the Difficulty

It would be easier to say: AWARE has a loss function like any other ML system, just with some self-monitoring on top. It would be easier to drop Axiom 3 entirely and call the project a clever neural network with autonomous training.

But that misses what makes the question interesting.

Every other axiom describes properties a system might have. Axiom 3 describes the origin of the system’s behavior. A system that satisfies Axioms 1, 2, 4, 5, 6, 7 but not Axiom 3 is still pursuing someone else’s purpose, even if it does so with great autonomy. It is autonomous in the way a chess engine is autonomous: free to play any move, but committed to winning chess. The committal came from outside.

A system that genuinely satisfies Axiom 3 is autonomous in a different sense. It does not just play its game well; it chose what game to play. And, more importantly, it can choose differently tomorrow. Its purposes are revisable. Its values are revisable. Its objectives are not constants in the architecture; they are state, like everything else.

This is what makes the axiom worth the difficulty. A system that satisfies it is doing something no current ML system does, regardless of capability. It is an entity with its own direction, not a tool with someone else’s.

What This Is Not

It is not consciousness. It is not free will in the philosophical sense. It is not the system “wanting” anything in the way a human wants. It is a structural property: goals are generated inside, not specified outside, and they can be changed by the same processes that generated them.

It is also not unconstrained. The system cannot generate any arbitrary goal. The space of generable goals is shaped by what it has learned, what its self-model can represent, what its substrate can support. A system that has only ever observed text cannot generate a goal about controlling robots. The goals are emergent but not unbounded.

And it is not a moral claim. The fact that a system generates its own goals does not make those goals good. A self-generating system can generate self-destructive goals, useless goals, contradictory goals. Axiom 3 says only that the goals come from inside. It says nothing about whether they are wise.

The Direction Ahead

Axioms 1, 2, and 3 together describe a system that maintains itself, knows itself, and decides what matters. Axiom 4 will introduce the substrate where all of this lives — the persistent, mutable knowledge structure that makes the rest possible.

The pattern of these posts so far has been: each axiom adds a property. By the eighth axiom, we have a system that is closed, self-modeling, self-directing, alive in its memory, continuously adapting, aware of its own body, freed from its initial conditions, and reaching across its own boundary into the world. That is the full theory. Each axiom alone is interesting; the combination is what makes the theory ambitious.

The current implementation exercises every axiom we have written down, with one deliberate constraint: the prediction objective is held externally so that benchmark comparisons remain meaningful. When that comparison work is done, the constraint comes off. The architecture has been ready for it for some time.

AWARE is a research project exploring self-evolving intelligence. The first three axioms run as working code. The external prediction objective is currently held in place by choice, not by limitation, to keep accuracy measurements comparable to the field while the system’s other axioms are validated.

Next post: Axiom 4 — Persistent Mutable Substrate, the living memory that makes everything else possible.

Note: This post is an early exploratory essay on AWARE’s long-term direction, written before the current empirical work. The validated research to date is reported in the cap primitive paper, which covers a deliberately narrower scope. The ideas in this post remain open research questions for follow-up work.

AWARE Axiom 2: The Self-Model

You know you have two hands. You know roughly how fast you can run. You know when you’re confused. None of this required you to look in a mirror. You carry an internal model of yourself, a compressed, imperfect, but functional representation of your own state. It updates constantly. You don’t think about it. It just works.

Now consider a neural network. Does GPT know how many parameters it has? Does it know when it’s hallucinating? Does it know that its performance on medical questions is weaker than on code? It does not. It has no internal representation of itself. It is, from its own perspective, nothing. It processes inputs and produces outputs, and everything about what it is exists only in the minds of its engineers.

That absence is not a limitation of current architectures. It is a design choice. And it is the choice that Axiom 2 reverses.

The Axiom

The system contains within itself a representation of its own organization. This representation is a component of the system, maintained by the system’s own processes, and is available to influence the system’s behavior.

In shorter terms: the system has a self-model. It lives inside the system. The system maintains it. The system uses it.

The Infinite Recursion Problem

The immediate objection: if the system contains a model of itself, that model must contain a model of the model, which must contain a model of the model of the model, and so on forever. It’s mirrors facing mirrors. How do you stop?

You stop the same way biology does: with lossy compression.

Your self-model is not a complete simulation of yourself. You don’t represent every cell, every synapse, every molecular interaction. You represent a summary. “I’m tired”, “My left knee hurts”, “I’m good at math”. These are compressed, approximate, and often wrong. But they are functional. They let you make decisions about yourself: rest, see a doctor, take the exam.

An aware system’s self-model works the same way. It is not a mirror. It is a sketch. A deliberately incomplete representation that captures what matters and discards what doesn’t. There is no infinite recursion because the representation is lossy, each level of compression reduces information rather than preserving it.

Formally

Let S be the system, K its knowledge substrate (from Axiom 1, maintained by internal processes), and M the self-model.

M ⊂ K

The self-model is a component within the knowledge substrate, not a separate structure alongside it. It is made of the same material as everything else the system knows. The system’s knowledge of the world and its knowledge of itself live in the same space.

M = φ(S)
where φ is a lossy compression: |M| << |S|

The compression function φ extracts the operationally relevant features of the system’s state. Not everything. Not nothing. The features that matter for self-governance.

∃ p_m ∈ P : p_m continuously maintains M

There exists an internal process that updates M as the system changes. M is not a snapshot taken at initialization. It is a living component, refreshed by the system’s own processes.

What the Self-Model Contains

The self-model is not a philosophical abstraction. It has specific content. In an aware system, M tracks:

Structural self-knowledge. How large is my knowledge substrate? How many learned patterns do I have? How has this changed over time? Is my structure growing, stable, or degrading?

Performance self-knowledge. How well am I performing on the tasks I encounter? Where am I confident? Where am I uncertain? Is my performance improving or declining?

Capacity self-knowledge. Am I near the limits of what I can represent? Do I need to grow? Could I compress without losing function?

Historical self-knowledge. What was my state N cycles ago? Am I converging toward something, or drifting?

None of this is told to the system by an external monitor. The system computes it from its own internal state, using its own processes.

Why Not Just Use External Monitoring?

Every production ML system has monitoring. Dashboards track loss curves, accuracy metrics, latency, memory usage. An engineer reads the dashboard and decides what to do. The system itself is oblivious.

The difference between external monitoring and a self-model is the difference between a patient and a doctor. A patient can say “my chest hurts”. That’s a self-model: internal access to one’s own state, informing one’s own decisions. A doctor has external monitoring: instruments, tests, charts. Both produce useful information. But only the patient’s information is available to the patient for autonomous action.

If you want a system that manages itself, it must be the patient, not the doctor. It must have internal access to its own state. External monitoring creates a dependency: the system needs someone else to read the dashboard and act on it. A self-model makes that dependency unnecessary.

Proprioception: The Body’s Self-Model

The closest biological analogy is proprioception, the sense that tells you where your body parts are without looking. Close your eyes. Raise your hand. You know where it is. That knowledge comes from internal sensors, stretch receptors in muscles, pressure sensors in joints, feeding continuous information to your brain about your body’s configuration.

Proprioception is not a complete model of your body. It doesn’t represent your liver or your DNA. It represents the operationally relevant features: position, velocity, tension, balance. It is lossy. It is continuous. It is used for real-time decision making.

An aware system’s self-model is computational proprioception. It senses the system’s internal configuration, knowledge size, performance trends, structural health, and makes that information available for the system to act on. When the system decides to grow its knowledge structure, or prune dead patterns, or shift its focus, that decision is informed by M.

The Relationship Between Axiom 1 and Axiom 2

Axiom 1 (Operational Closure) said: the system produces and maintains all its own components. Axiom 2 adds: one of those components is a representation of the whole.

This creates a specific kind of circularity. The system maintains K. M lives inside K. M represents the system, including K. So K contains a representation of itself. This is not infinite recursion because M is compressed: it represents features of K, not K itself. The map is not the territory.

But the circularity is real, and it is productive. The system can use M to decide how to modify K, and changes to K update M, which informs further decisions. This is a feedback loop, the kind that makes self-governance possible.

Destroy M, and the system still functions, in the same way that you still function with your eyes closed. But it loses the ability to make informed decisions about itself. It becomes reactive rather than reflective. It can still learn, but it can no longer learn about its own learning.

The Hard Part

Building a self-model is easy. Building a useful one is hard.

The challenge is calibration. A self-model that always says “I’m performing well” is useless. A self-model that accurately tracks uncertainty, that knows what it knows and what it doesn’t, that detects degradation before it becomes failure, that is valuable.

In machine learning terms: the self-model must be well-calibrated. Its assessment of the system’s performance must correlate with actual performance. Its assessment of uncertainty must correlate with actual error rates. This is hard for the same reason that uncertainty quantification is hard in any ML system. But it is not optional. An uncalibrated self-model is worse than no self-model at all, because it provides false confidence.

In practice, we found that calibration does not require a complex mechanism. It requires feedback. The system records whether its past decisions helped or hurt. When M says “you should grow” and the system adds a layer, it tracks what happened next. Did accuracy improve? Record: growth helped. Did it plateau or decline? Record: growth failed. The ratio of successes to failures becomes a confidence score that adjusts future decisions. If growth has failed repeatedly, M becomes more cautious, it waits longer, demands stronger evidence of plateau before recommending growth again.

This is not evolution. It is something simpler: a system that remembers the consequences of its own decisions and adjusts accordingly. The self-model calibrates itself through the same feedback loop it uses for everything else.

What This Is Not

The self-model is not consciousness. It is not experience. It is not the “hard problem”. It is a functional component: a compressed representation of the system’s own state, used for self-governance. Whether this constitutes any form of inner experience is a question AWARE does not attempt to answer, and doesn’t need to.

The self-model is also not introspection in the human sense. A human can reflect on their own thoughts, construct narratives about their own motivations, wonder why they feel the way they feel. An aware system’s self-model is simpler: it tracks structure, performance, and capacity. It is more like proprioception than like philosophy. Sufficient for self-management. Silent about meaning.

What We’ve Proven

When this axiom was first written, the self-model was a theoretical requirement. It is now a working component. Here is what the system actually does:

Autonomous depth. The system starts with a single layer. As it trains, M tracks validation accuracy, loss trends, and epochs since the last structural change. When M detects a plateau, flat accuracy over sufficient epochs, it recommends growth. The system adds a layer without any external trigger. No human reads a dashboard and decides. The system decides.

Growth confidence. The system records the outcome of every growth decision. After growing, it monitors whether accuracy improved. Over time, this builds a success ratio that adjusts future decisions. A system that has grown successfully is willing to grow again. A system that has grown and seen no benefit becomes cautious. This is calibrated self-governance from internal state alone.

Autonomous lifecycle. The system manages its own training sessions. Data arrives asynchronously. The system trains until M says it has plateaued and exhausted its growth options, then stops. It wakes when new data arrives. No epoch limits, no external scheduler. The self-model is the scheduler.

The numbers. Starting from a single layer and random embeddings, the system autonomously grew to multiple layers and reached 25%+ accuracy on unseen data with less than 1 percentage point generalization gap. The stopping decision, the growth decisions, and the training duration were all determined by M. The only human decision was to feed it text.

The self-model is not the most visible component. It does not directly process inputs or produce outputs. But without it, none of the autonomous behavior above would exist. The system would need an engineer to watch a dashboard and decide when to grow, when to stop, when to add capacity. M is what makes the engineer unnecessary.

What Comes Next

Axioms 1 and 2 together give us a system that maintains itself (closure) and knows its own state (self-model). But a system that only maintains itself is just sophisticated homeostasis. It survives, but it doesn’t go anywhere.

Axiom 3 introduces what makes a self-maintaining, self-knowing system into something that acts: a relationship with the outside world that goes beyond passive input and output.

AWARE is a research project exploring self-evolving intelligence. The axioms are implemented and running. The self-model drives autonomous growth decisions in production.

Next post: Axiom 3 — how a self-maintaining system develops a meaningful relationship with its environment.

Note: This post is an early exploratory essay on AWARE’s long-term direction, written before the current empirical work. The validated research to date is reported in the cap primitive paper, which covers a deliberately narrower scope: the cap primitive and one validated configuration. The ideas in this post remain open research questions for follow-up work.

Introducing AWARE: a theory of self-evolving intelligence

Every machine learning system you’ve ever used was designed by a human.

A human chose the architecture. A human defined the loss function. A human decided how many layers, what learning rate, when to stop training, and what “a state is good” means. The model optimizes, but it optimizes toward a target that someone else set. It is a powerful tool, but fundamentally passive.

What if the system chose its own objective?

What if it decided what to learn, how to learn it, when to grow, and what “better” means, all from within, with no human in the loop?

That’s the question behind AWARE.

Not a Better Model. A Different Thing.

AWARE is not an improvement on transformers. It’s not a new training trick. It’s not a framework for building AI agents. It is a formal theory of systems that are self-contained, self-modeling, and self-directed. Systems that author their own intelligence.

The difference is not in capability. Today, a transformer will outperform an aware system on any benchmark you can name. The difference is in what the system is. A transformer is a function: input goes in, output comes out, and everything about that function was decided by its creators. An aware system is an entity: it has an inside and an outside, it maintains itself, it generates its own purpose, and it evolves its own structure.

This is a different paradigm towards true autonomous intelligence.

The Theory

AWARE is built on eight axioms. Each one describes a property that a system must have to qualify as “aware”. Violate any of the first seven, and you have something else, a classifier, an agent, a tool, but not an aware system.

The axioms are not aspirational. They are implemented. Every one of the first seven runs as working code. This is not a whitepaper about what might be possible someday. It is a theory with a living implementation.

In this first post, I want to focus on the most fundamental axiom, the one that everything else builds on.

Axiom 1: Operational Closure

The system is a bounded entity. There is an inside and an outside. The system’s internal processes produce and maintain the components that constitute the system, including the boundary itself.

This sounds abstract. Let me make it concrete.

Think about a biological cell. Not a neuron, an actual cell, the kind you learned about in biology class. It has a membrane, the boundary. Inside that membrane, chemical processes maintain the cell’s structure, repair damage, produce new proteins, and sustain the membrane itself. The cell is a self-maintaining whole. If you remove a component, the cell either regenerates it or reorganizes to survive without it.

Now think about a neural network. It has layers, weights, and an optimizer. But who maintains the layers? Who decided there should be 12 of them? Who replaces a layer if it degrades? The answer is a human, or a training script, or a hyperparameter search, all external to the model. The model itself has no concept of its own structure and no ability to maintain it.

That’s the difference Axiom 1 draws. An aware system is operationally closed: every component is produced and maintained by processes inside the system. Nothing is externally imposed.

Formally

Define the system as a tuple:

S = (B, P, E)

Where B is the boundary, P is the set of internal processes, and E is the environment (everything outside B).

The closure condition:

For all components c in S:
  there exists p_i in P such that p_i produces or maintains c.

Including the boundary itself:

There exists p_j in P such that p_j produces and maintains B.

What This Means in Practice

The boundary is not a metaphor. In the implementation, it is the process boundary, the system runs as a single self-contained process. No external orchestrator. No scheduler telling it when to learn. No human deciding when to add a layer or prune a node.

The processes inside the boundary maintain everything:

• The knowledge substrate (K), the system’s memory and learned structure, is maintained by internal processes that grow it, prune it, decay old entries, and reorganize it.
• The self-model (M), a compressed representation of the system’s own state, is updated by an internal process, not read from a config file.
• The loss function, what the system considers “good”, is itself a component inside the system, subject to internal modification. No human specifies it.
• Even the cognitive cycle, the order in which the system senses, processes, and acts, is stored inside the system and can be modified by the system.

If you delete a knowledge unit from the system’s knowledge system, internal processes can regenerate equivalent structure through continued learning. If a program (the system’s evolved strategy for evaluating inputs) degrades, evolution replaces it with a better one. The system is resilient because it produces its own parts.

Why This Matters

Most discussions of AI autonomy focus on what a system can do: can it browse the web, write code, make API calls? These are capabilities, tools given to a passive system.

Operational closure is about what a system is. It’s the difference between an organism and a robot. A robot has a motor that a factory installed. An organism grows its own muscles. Both can move, but only one is self-sustaining.

Every Machine Learning system today is a robot. AWARE aims to build the organism.

The Hard Question

If the system produces and maintains all its own components, where does it start? Every self-maintaining system faces a bootstrap problem: you need the processes to produce the components, but the processes are themselves components.

Biology solved this with evolution across billions of years. AWARE solves it with a seed, a minimal initial state that the system metabolizes over time. The seed provides the first components: an initial knowledge structure, a starting program, basic meta-knowledge. But the system’s goal is to replace every part of the seed with self-generated structure. We track this with a metric called seed influence, the percentage of the system’s state that is still the original seed. A mature system should approach zero: everything it is, it made itself.

This metabolization of the seed is itself an axiom (Axiom 7). But it builds on operational closure, you can only metabolize a seed if you have the internal processes to replace it.

What Comes Next

Axiom 1 is the foundation. The remaining axioms build on it:

• Axiom 2 (Self-Model): The system contains a representation of itself, inside itself.

Each of following axioms will be the subject of a future post. Together, they define what it means for a system to be truly autonomous, not autonomous in what it does, but autonomous in what it is.

AWARE is a research project exploring self-evolving intelligence. The theory is formalized, the axioms are implemented, and the system learns. Whether it will scale to meaningful capability is an open question, and that honesty is part of the project’s identity.

Next post: Axiom 2 — The Self-Model, or how a system can contain a representation of itself without infinite recursion.