fireclaw/IDEAS.md

Fireclaw Ideas

Future features and experiments, loosely prioritized by usefulness.

Operator Tools

!status command

Quick dashboard in IRC: agent count, RAM/CPU per VM, Ollama model currently loaded, system uptime, disk free. One command to see the health of everything.

!logs [n]

Tail the last N interactions an agent had. Stored in the agent's workspace. Useful to see what an agent's been doing while you were away.

!persona [new persona]

View or live-edit an agent's persona via IRC. "Make the worker more sarcastic" without touching files or restarting. Uses hot-reload under the hood.

!pause / !resume

Temporarily mute an agent without destroying it. Agent stays alive but stops responding. Useful when you need a channel to yourself.

Skill System (inspired by mitsuhiko/agent-stuff)

SKILL.md pattern for agent tools

Replace hardcoded tools in agent.py with a discoverable skill directory. Each skill is a folder with a SKILL.md (description, parameters, examples) and a script (run.sh/run.py).

~/.fireclaw/skills/
  web_search/
    SKILL.md        # name, description, parameters — parsed into tool definition
    run.py          # actual implementation
  fetch_url/
    SKILL.md
    run.py
  git_diff/
    SKILL.md
    run.sh

Agent discovers skills at boot, loads SKILL.md into Ollama tool definitions, invokes scripts on tool call. Adding a new tool = drop a folder. No agent.py changes needed.

Could also support per-template skill selection — coder gets git/code skills, researcher gets search/fetch skills, worker gets everything.

Reference: https://github.com/mitsuhiko/agent-stuff — Pi Coding Agent skill/extension architecture.

Agent Tools

Web search

Agents can search via the searx instance on mymx. Either bake the searx CLI into the rootfs, or add a proper web_search(query) tool that calls the searx API from inside the VM. Agents could actually research topics instead of relying on training data.

Fetch URL

fetch_url(url) tool to grab a webpage, strip HTML, return text. Combined with web search, agents become genuine research assistants. Could use curl | python3 -c "from html.parser import..." or a lightweight readability script.

File sharing between agents

A shared /shared mount (third virtio drive, or a common ext4 image) that all agents can read/write. Drop a file from one agent, pick it up from another. Enables collaboration: researcher writes findings, coder reads and implements.

Code execution sandbox

A run_python(code) tool that's safer than run_command. Executes in a subprocess with resource limits (timeout, memory cap). Better for code agents that need to test their own output.

Automation

Cron agents

Template gets an optional schedule field: "schedule": "0 8 * * *". The overseer spawns the agent on schedule, it does its task, reports to #agents, and self-destructs. Use cases:

• Morning health check: "any disk/memory/service issues on grogbox?"
• Daily digest: "summarize what happened in #agents yesterday"
• Backup verification: "check that last night's backups completed"

Webhook triggers

HTTP endpoint on the host (e.g., :8080/hook/<template>) that spawns an ephemeral agent with the webhook payload as context. Examples:

• Gitea push webhook → coder agent reviews the commit in #dev
• Uptime monitor → agent investigates and reports
• RSS feed → researcher summarizes new articles

Alert forwarding

Pipe system alerts (fail2ban, smartmontools, systemd failures, journal errors) into #agents via a simple bridge script. An always-on agent could triage: "fail2ban banned 3 IPs today, all SSH brute force from China, nothing to worry about."

Git integration

Agent can clone repos from Gitea (on mymx), read code, create branches, commit changes, open PRs. Would need git in the rootfs (already available via apk add git) and Gitea API access via the bridge network.

Agent Personality & Memory

Evolving personalities

Instruct agents to actively develop opinions, preferences, and communication styles over time. The memory system supports this — agents could save "I prefer concise answers" or "human likes dry humor" and adapt. Give them character arcs.

Agent journals

Each agent maintains a daily journal in its workspace. Auto-saved summary of conversations, decisions made, things learned. Creates a narrative over time. Useful for debugging agent behavior and understanding their "thought process."

Cross-agent memory

Agents can read (but not write) each other's MEMORY.md. A new agent spawned for a task can inherit context from an existing agent. "Spawn a coder that knows what the researcher found."

Agent self-improvement

After each conversation, the agent reflects: "What could I have done better?" Saves lessons to memory. Over time, agents get better at their specific role. Needs a meta-prompt that triggers self-reflection.

Multi-Agent Orchestration

Task delegation

Human gives a complex task to one agent, it breaks it down and delegates subtasks to other agents via IRC. Researcher does the research, coder implements, worker tests. All visible in #agents.

Agent voting

Multiple agents weigh in on a question. "Should we upgrade the kernel?" Each agent responds in #agents, human gets multiple perspectives. Could formalize with a !poll command.

Agent debates

Two agents argue opposite sides of a technical decision. Useful for exploring trade-offs. "Should we use Rust or Go for this?" Coder argues one side, researcher the other.

MCP Servers as Firecracker VMs

Run MCP tool servers in their own Firecracker VMs, same isolation model as agents. Managed by the overseer with the same lifecycle (!invoke, !destroy).

Approach: single Firecracker VM with podman containers

Firecracker VMs (fcbr0, 172.16.0.x)
  ├── worker (agent VM)
  ├── coder (agent VM)
  └── mcp-services (service VM, 172.16.0.10)
        └── podman
              ├── mcp-fs (:8081)
              ├── mcp-git (:8082)
              └── mcp-searx (:8083)

One VM hosts all MCP servers in separate containers. Firecracker isolates from the host, podman separates services from each other. Lightweight — MCP servers are just HTTP wrappers, don't need their own VMs.

Agents call them at 172.16.0.10:<port>. Overseer manages the VM and lists available tools via !services.

One-VM-per-service is overkill for trusted MCP servers but could be used for untrusted third-party tools.

Why a Firecracker VM instead of host podman

• MCP servers can't access the host filesystem directly
• Consistent isolation model with agents
• The VM is independently restartable without affecting the host
• Podman-in-Firecracker is already working in the agent rootfs

Candidate MCP servers

• filesystem — read/write to a shared volume (mounted as virtio drive)
• git — clone, read, diff, commit (Gitea on mymx accessible via bridge)
• searx — web search via searx.mymx.me
• database — SQLite or PostgreSQL query tool
• fetch — HTTP fetch + readability extraction

Cron / scheduled agents

Add schedule field to templates (cron syntax). Overseer checks every minute, spawns matching agents, they do their task, report to #agents, self-destruct after timeout. Use cases: daily health checks, backup verification, digest summaries.

Logging

Centralized log viewer

Agent logs go to /workspace/agent.log inside each VM. For a centralized web UI:

• rsyslog on host (agents send to 172.16.0.1:514) for aggregation
• frontail (npx frontail /var/log/fireclaw/*.log --port 9001) for browser-based real-time viewing
• Or GoTTY (gotty tail -f ...) for zero-config web terminal

Start simple (plain files + !logs), add rsyslog + frontail when needed.

Infrastructure

Agent metrics dashboard

Simple HTML page served from the host showing: running agents, response times, model usage, memory contents, conversation history. No framework — just a static page with data from agents.json and workspace files.

Agent backup/restore

Export an agent's complete state (workspace, config, rootfs diff) as a tarball. Import on another machine. Portable agent identities.

Multi-host agents

Run agents on multiple machines (grogbox + odin). Overseer manages VMs across hosts via SSH. Agents on different hosts communicate via IRC federation.

GPU deployment

Remote machine available: Xeon E5-1620 v4, 32GB RAM, Quadro P5000 (16GB VRAM). Enough for 14B-30B models at 2-5s inference. Standalone fireclaw deployment — its own ngircd, its own agents, completely independent from grogbox.

Install script

scripts/install.sh — one-command deployment to new machines. Installs firecracker, ollama (with GPU if available), ngircd, Node.js, builds rootfs, configures everything. curl -fsSL .../install.sh | bash or just ./scripts/install.sh. No Ansible dependency — plain bash.

Fun & Experimental

Agent challenges

Post a challenge in #agents: "shortest Python script that sorts a list." Agents compete, see each other's answers, iterate. Gamified agent development.

Honeypot agents

Agent with fake credentials, fake services, fake data. See what it tries to do. Test agent safety before trusting it with real access. Could also test prompt injection resistance.

Agent-written agents

An agent creates a new template (persona + config) and asks the overseer to spawn it. Self-replicating agent system. Needs careful guardrails.

IRC games

Agents play text-based games with each other or with humans. Trivia, 20 questions, collaborative storytelling. Tests agent personality and creativity in a low-stakes way.

Dream mode

An agent left running overnight with trigger: all in an empty channel, talking to itself. Stream of consciousness. Review in the morning. Probably nonsense, but occasionally insightful.