Bundles and versions

A bundle is the portable, inspectable part of an agent: Markdown instructions, runtime configuration, lifecycle hooks, schedules, skills, and supporting files.

Immutable by design

Each changed publish creates an immutable version. An identical bundle reuses the latest version. Earlier versions remain unchanged, so reviewers can identify the exact files being used.

Agent instructions, skills, schedules, and nested memory/**/*.md files belong to a specific immutable version. Conversations remain separate, and secret values remain protected in the scoped Vault.

Runtime version selection

For owned agents and independent clones, enabling pins the reviewed bundle version. Every turn reconstructs that version in an isolated sandbox before adding the relevant conversation and attachments.

You can still open earlier or newer bundle versions to inspect files and settings. While you are not on the pinned live version, the agent page shows a warning with a link back to live; conversations only run against the pinned version.

Agent self-modify

New agents default to allowing self-modify. When enabled, the agent is instructed to stage at least one concrete harness improvement each turn (skills, schedules, AGENTS.md, hooks, sandbox config, and so on). After the turn ends Aleph validates the merged tree, creates a new immutable version, and enables that version. The current turn keeps the previous pin; the next turn materializes the update. Installed agents cannot enable this — only the source agent may change its harness. Creators can turn the setting off in agent settings.

Installations and clones

An installation follows the source agent's currently enabled harness. New source versions affect the installation on its next run. The installation has its own placement, permissions, Vault values, variables, Connections, channels, conversations, and enable/disable state. New source permissions are never silently granted; configure them in your own scope first.

The installation version menu is an inspector, not a pin control. It marks the source owner's live version and lets you review other source versions without changing what the installation runs. Enable or disable the installation independently when your own configuration is ready.

Disabling new installations on the source does not revoke existing installations. Source lifecycle mirroring is out of scope: each installer controls its own enable/disable state and may uninstall independently.

A clone is an independent, editable fork. It receives a complete snapshot of the selected source version, including its memory files, and does not receive future source updates.

Continue with Bundle structure to build one.