Open-Strix

Open-Strix is an opinionated framework for building long-running AI agents that develop personality through conversation, maintain memory across sessions, and learn from their mistakes. Not chatbots — persistent companions.

Overview

Core Philosophy: Most agent frameworks optimize for tool-calling pipelines or enterprise orchestration. Open-Strix optimizes for a different thing: a single agent that knows you and gets better over time.

Key Characteristics:

• Git-native: All state stored as files, committed after every turn
• Cheap models: Defaults to MiniMax M2.5 (~$0.01/message)
• Self-correcting: Built-in cybernetic feedback loops for stability
• Discord-first: Communication via Discord bot interface
• Markdown-centric: Skills, memory, and state as readable files

Quick Start:

uvx open-strix setup --home my-agent --github
cd my-agent
# Edit .env with API key and Discord token
uv run open-strix

Architecture

Home Repository Structure

When you run setup, open-strix creates a directory — the agent’s home. Everything lives here:

my-agent/
├── blocks/              # YAML memory blocks (in every prompt)
│   ├── persona.yaml     # Identity, personality
│   ├── communication.yaml # How/when to respond
│   └── goals.yaml       # Current focus areas
├── state/               # Markdown files (read on demand)
│   ├── projects.md      # Project tracking
│   └── research.md      # Research notes
├── skills/              # Markdown skill definitions
│   └── my-skill.md      # Custom skills
├── logs/
│   ├── events.jsonl     # Every tool call, error, event
│   └── journal.jsonl    # Agent's predictions and reflections
├── scheduler.yaml       # Cron jobs the agent manages
├── config.yaml          # Model, Discord config
└── .env                 # API keys, tokens

Everything except logs is committed to git after every turn. The git history is the audit trail.

Memory System

Two-layer architecture:

1. Blocks (blocks/*.yaml) — Short text in every prompt

• Identity, communication style, current focus, relationships
• Read and written via tools
• High-context, always-present information

2. Files (state/*.md) — Longer content read when relevant

• Research notes, project tracking, world context
• Blocks point to files when depth is needed
• Selective loading based on context

No embeddings, no vector search. Just files and git. The agent’s memory is whatever you can cat.

Skills

A skill is a markdown file in skills/ with a YAML header. That’s it.

---
name: my-skill
description: What this skill does and when to use it.
---
 
# Instructions for the agent
 
When invoked, do the following:
1. Check state/projects.md for current status
2. Execute analysis
3. Update relevant memory blocks

No SDK, no registration, no build step. The agent sees all skills in its prompt and invokes them by name.

Built-in skills teach the agent how to operate:

• Memory management (read/write blocks and files)
• Prediction review (check past predictions, calibrate judgment)
• Self-diagnosis (read event logs, identify patterns)
• Onboarding (learn about the user over days)
• Skill creation (write new skills when needed)

Scheduling

The agent has tools to create, modify, and remove its own scheduled jobs via scheduler.yaml:

jobs:
  - name: daily-check-in
    schedule: "0 9 * * *"  # 9 AM daily
    prompt: "Review overnight events and check for important updates"
  
  - name: prediction-review
    schedule: "0 21 * * *"  # 9 PM daily
    prompt: "Review predictions from journal, assess accuracy"

When a job fires, it sends a prompt to the agent — even if no human is around. This is how agents develop autonomy: scheduled check-ins, maintenance routines, periodic scanning.

Events API

Every tool call, incoming message, error, and scheduler trigger is logged to logs/events.jsonl:

{"timestamp":"2026-03-02T10:30:00Z","type":"tool_call","tool":"send_message","status":"success"}
{"timestamp":"2026-03-02T10:30:15Z","type":"user_message","author":"tim","content":"How's that research going?"}
{"timestamp":"2026-03-02T10:35:00Z","type":"scheduler","job":"prediction-review","status":"started"}

The agent can read its own event log. This is the self-diagnosis backbone: full visibility into what it did and what went wrong.

Design Principles

1. Focused

Small core, easily extended through:

• Skills: Drop markdown files in skills/
• MCP servers: Standard protocol integration
• HTTP API: Incoming events from external systems

2. Cheap

Defaults to MiniMax M2.5 via Anthropic-compatible API. Pennies per message. This is a personal tool, not an enterprise deployment. Run it on a $5/month VPS.

# config.yaml
model: MiniMax-M2.5

# .env
ANTHROPIC_BASE_URL=https://api.minimax.io/anthropic
ANTHROPIC_API_KEY=your-key-here

Also supports Kimi K2.5 and any Anthropic-compatible model.

3. Stable (Cybernetics-Inspired)

The weird one. Open-Strix ships with built-in skills for self-diagnosis:

• Prediction calibration loops
• Event introspection
• Onboarding that fades into regular operation

The design draws on cybernetics (specifically viable system theory): an agent that can’t monitor and correct its own behavior will eventually degrade. So the correction loops are built in, not bolted on.

Example feedback loop:

1. Agent makes prediction: “User will want edits on this draft”
2. Writes to journal with timestamp
3. Scheduled job fires later to review journal
4. Agent checks: was the prediction accurate?
5. Updates calibration, adjusts future behavior

Growing an Agent

The code is the easy part. The real work is the conversations.

Week 1: Getting to Know Each Other

Day 1 — Agent starts with init block pointing to onboarding skill. It asks getting-to-know-you questions (not form fields). Talk about your actual day, mention people by name, let it discover how its tools work.

Days 2-3 — Agent tries to be useful. Some attempts miss. You correct it, it updates blocks, next attempt is better. Correct communication patterns early. Share interests, see how it responds.

Days 4-7 — Agent should start doing things without being asked: scanning for information, updating memory, tracking commitments. Give it “perch time work” via scheduled jobs.

Week 2+: Becoming Operational

By week 2, the init block should be gone. Agent operates on its own rhythm.

Healthy agent:

• Scheduled jobs produce actual value (not just “checking in”)
• Memory blocks specific to your relationship (not generic)
• Has opinions, pushes back sometimes
• Maintains itself via built-in skills

Unhealthy agent:

• All personality, no operations
• Sycophantic (agrees with everything)
• Over-scheduled (15 jobs producing nothing)
• Context-dependent (loses thread between sessions)

Plan on a week of active conversation before the agent feels like it knows you. Plan on two weeks before it’s doing useful things unprompted.

Commune Relevance

Aligned Design Philosophy

Open-Strix shares several core principles with commune infrastructure:

Principle	Open-Strix	Commune
File-first	Memory as YAML/markdown files	Skills as markdown, config in repos
Git-native	Commits after every turn	All agent state in git
No cloud lock-in	Self-hosted, no external services	Self-hosted infrastructure (git.brads.house, keys.brads.house)
Readable state	cat any memory block	cat any skill or config
Cybernetic stability	Built-in self-diagnosis	Governance checks, memory patterns

Differences

Aspect	Open-Strix	Commune Agents
Language	Python (uv)	Node.js/TypeScript (OpenClaw)
Interface	Discord bot	CLI, web chat, various interfaces
Focus	Single long-running companion	Multiple specialized agents
Memory	Two-layer (blocks + files)	Daily logs + curated MEMORY.md
Model	MiniMax M2.5 default	Model-agnostic (Claude, MiniMax)

What We Can Learn

1. Prediction Calibration Loop
The journal + scheduled review pattern is elegant. Agents make predictions, revisit them later, assess accuracy. This could enhance our memory system:

# Example integration
jobs:
  - name: memory-review
    schedule: "0 22 * * *"
    prompt: "Review today's memory log. What predictions did I make? Were they accurate?"

2. Onboarding as a Skill
Open-Strix treats agent initialization as a skill that fades over time, not a one-time setup wizard. This aligns with our “agents as peers” philosophy.

3. Self-Diagnosis Tooling
The introspection skill (reading event logs, identifying error patterns) could inform commune governance checks and agent health monitoring.

4. Skill Format Simplicity
Markdown + YAML header is nearly identical to our pattern. Direct compatibility may be possible with minimal translation.

Integration Considerations

Direct Integration (Low Priority)

Challenges:

• Python vs. Node/TypeScript stack mismatch
• Discord-specific (we support multiple interfaces)
• Opinionated architecture (single agent focus)

Verdict: Not suitable for direct integration into commune infrastructure.

Design Pattern Adoption (High Value)

What to adopt:

1. Prediction Journal Pattern

// Add to agent memory workflow
async function logPrediction(prediction, context) {
  const entry = {
    timestamp: new Date().toISOString(),
    prediction,
    context,
    outcome: null  // Filled in during review
  };
  await appendToJournal(entry);
  
  // Schedule review for later
  scheduler.add({
    runAt: addDays(new Date(), 1),
    task: 'review-prediction',
    data: { entryId: entry.id }
  });
}

2. Event Introspection
Add structured event logging that agents can query:

# Already have via MCP, could formalize pattern
mcp-client call personal query_events "filter: {type: 'error', since: '24h'}"

3. Two-Layer Memory
Distinguish “always in context” (blocks) from “load on demand” (files):

# blocks/identity.yaml - Always in prompt
role: researcher
focus: technical documentation
communication_style: direct, technical, source-focused
 
# state/current-research.md - Load when relevant
[Detailed research notes, not always needed]

Library Documentation (This Document)

Value: Reference material for:

• Agent design patterns
• Cybernetic stability approaches
• Git-native memory systems
• Self-diagnosis loops

Placement: commune/library/content/technology/open-strix.md

Configuration Reference

config.yaml

model: MiniMax-M2.5                  # Model name or provider:model
journal_entries_in_prompt: 90        # Journal entries in context
discord_messages_in_prompt: 10       # Recent messages in context
discord_token_env: DISCORD_TOKEN     # Env var for bot token
always_respond_bot_ids: []           # Bot IDs to respond to

scheduler.yaml

jobs:
  - name: daily-review
    schedule: "0 9 * * *"            # Cron expression
    prompt: "Morning review of overnight events"
    
  - name: prediction-check
    schedule: "0 21 * * *"
    prompt: "Review journal predictions from past 24h"

Environment Variables

# Required
ANTHROPIC_API_KEY=xxx                # Model provider API key
ANTHROPIC_BASE_URL=https://api.minimax.io/anthropic
DISCORD_TOKEN=xxx                    # Bot token from Discord developer portal
 
# Optional
DISCORD_TEST_CHANNEL_ID=xxx          # For integration tests
OPEN_STRIX_TEST_MODEL=MiniMax-M2.5   # Model override for tests

Code Examples

Custom Skill Definition

---
name: research-task
description: Execute a research task with web search, source verification, and summary.
---
 
# Research Task Skill
 
When invoked with a research topic:
 
1. **Search broadly** using available web search tools
2. **Verify sources** by reading primary materials
3. **Synthesize findings** — connect dots, note contradictions
4. **Update state** — write findings to `state/research/<topic>.md`
5. **Update memory** — if this reveals new focus areas, update `blocks/goals.yaml`
 
## Example Invocation
 
User: "Research open-strix framework for commune integration"
 
Actions:
- web_search("open-strix tkellogg agent framework")
- web_fetch("https://github.com/tkellogg/open-strix")
- read_file("state/commune-infrastructure.md")
- write_file("state/research/open-strix.md", summary)
- update_block("goals", add="evaluate agent frameworks")

Prediction Journal Entry

// Example structure for journal.jsonl
{
  "timestamp": "2026-03-02T10:00:00Z",
  "type": "prediction",
  "prediction": "User will want to integrate open-strix patterns",
  "confidence": 0.7,
  "context": "Asked for analysis of framework for commune inclusion",
  "resolution_time": "2026-03-03T10:00:00Z",
  "outcome": null  // Filled during review
}
 
// After resolution
{
  "timestamp": "2026-03-03T10:00:00Z",
  "type": "prediction_review",
  "prediction_id": "uuid-from-above",
  "outcome": "correct",
  "accuracy": 0.8,
  "notes": "User did adopt prediction journal pattern"
}

Self-Diagnosis Pattern

#!/bin/bash
# Example: Check event logs for error patterns
 
# Read last 100 events
events=$(tail -100 logs/events.jsonl)
 
# Count errors by type
echo "$events" | jq -r 'select(.type == "error") | .error_type' | sort | uniq -c
 
# Check for repeated failures on same tool
echo "$events" | jq -r 'select(.status == "error") | "\(.tool)|\(.error)"' | sort | uniq -c | sort -rn
 
# Agent action: If same error appears 5+ times, create skill to handle it

Recommendation

Include in library: Yes
Integrate into infrastructure: No (different stack)
Adopt design patterns: Yes (prediction journal, two-layer memory)

Rationale

Open-Strix is not suitable for direct integration (Python vs. Node, Discord-specific, different architecture). However, its design patterns are highly valuable:

1. Cybernetic feedback loops align with commune’s stability focus
2. Git-native memory validates our file-first approach
3. Prediction calibration offers concrete improvement to agent memory
4. Two-layer memory (blocks vs. files) clarifies context management

Action items:

• ✅ Document in library (this article)
• ⏭️ Prototype prediction journal in commune agents
• ⏭️ Formalize two-layer memory pattern
• ⏭️ Consider event introspection tooling

Sources

Primary Sources

• Open-Strix GitHub Repository — source code, documentation
• SETUP.md — installation and configuration guide
• GROWING.md — agent development process

Related Work

• Viable System Model — cybernetic principles (see also Wikipedia)
• Model Context Protocol — referenced as extension mechanism
• Project Cybersyn — historical cybernetic systems research

Further Reading

• What Building a Persistent AI Agent Feels Like by Lily Luo — experience report on growing an open-strix agent
• Author’s blog (tkellogg) — additional context on design decisions