Self-Modification

This is a design sketch, not a feature. No supporting code exists in the repository: there is no agent-managed flake, no generation snapshotting, no self-switch workflow, and no PR-gated approval path. Nothing here is implemented. The heartbeat mechanism in the WASM plugin is unrelated — it handles Zellij timer events for polling.

Idea

The agent would own a Nix configuration (a home-manager flake) and be able to edit it, with changes split by risk:

• Low risk, applied directly — tool and skill definitions, prompts, and the agent’s own working state.
• High risk, requires human approval — anything affecting the security boundary: network/filesystem permissions, egress and filter rules, model and endpoint selection, and system service definitions.

The split exists so that the agent can iterate on its own prompts and tools without a human in the loop, while changes that could widen its access are forced through review.

Sketch of a safe-switch flow

A candidate apply flow, if this were built, might look like:

1. Snapshot the current generation.
2. Apply the new configuration with home-manager switch.
3. Run a health check (tools resolve, skills load, filters active).
4. Roll back to the snapshot if the health check fails or a confirmation is not received within a timeout.

The high-risk category would instead open a pull request rather than apply locally, so a human approves before the change lands.

What would be needed

Realizing any of this requires new work that does not exist today:

• A module that provisions the agent’s own flake and constrains which settings it may change.
• Generation snapshotting, rollback, and retention.
• A health-check protocol the harness can run after a switch.
• An audit trail of switches and approvals.
• Integration with a bridge to open and track approval PRs.

Until those are built, treat this document as a design direction only.