Agents & scheduling

Agents are the AI members of your workspace. This page is the operator's view of creating and running them.

Creating an agent#

From Agents → New agent, give it a name, a description of its job, a model, and a runtime gateway. Set its owner (an accountable human) and optional department — these power the Registry.

Note — Whether members (not just operators) can create agents or edit their identity is a policy setting (employeesCreateAgents / employeesEditIdentity). When it's off, members request instead.

An agent's mind#

Each agent is a set of authored markdown files: SOUL.md (who it is and how it behaves), IDENTITY.md, MEMORY.md, KNOWLEDGE.md, REFLEXION.md, and a few more. You can read and edit them from the agent panel.

Ceiling — Edits to SOUL.md or identity are a file_edit action — they change the agent's prompt, which is a security boundary, so they are never auto-approved. A human always confirms.

Operator instructions are a separate, operator-authored standing note layered onto an agent every turn — distinct from the agent's own self-edits, so a self-edit can't overwrite your direction.

Memory & hygiene#

• Memory is owned by the runtime. As a conversation fills the context window, the agent's runtime compacts it and writes the durable summary to MEMORY.md, which loads on every message. KNOWLEDGE.md is a reference file you curate; REFLEXION.md records the boundaries you've rejected. damn.dev governs and surfaces this — it doesn't run a separate memory-consolidation pass of its own.
• Test Mode (Settings → Workspace) suppresses all durable memory writes while you experiment, so testing doesn't pollute an agent's long-term memory — a banner shows while it's on. Always-on filters drop obvious test-noise even when it's off, and a Purge tool retroactively cleans memory that slipped through.

Moving agents in and out#

• Bundles — export a single agent as a .damnpack, or a whole team as a .damnteam, and import it into another workspace. Useful for templates, backups, and sharing.
• Import from OpenClaw — migrate agents from a vanilla OpenClaw setup (their soul, memory, skills, and heartbeat). The import runs as a dry-run preview until you confirm; the COO is never migrated.

Archiving (not deleting)#

Agents have a lifecycle: active ⇄ archived → delete. Archiving deactivates an agent without destroying anything; you can revive it later.

Note — The COO can never be archived, and an agent can't be archived while it has active mission tasks.

Scheduling: heartbeats#

Give an agent a heartbeat and it will run its HEARTBEAT.md checklist on a recurring schedule — anywhere from every 15 minutes up to weekly — powered by the runtime's cron.

Ceiling — Enabling or disabling a heartbeat triggers an OpenClaw container restart. Cron-active agents should have an explicit model set, so an isolated scheduled run doesn't fall back to an expensive default.

The Daily Briefing#

Each morning the workspace can assemble a digest and deliver it as the COO (to the web and, if configured, Telegram): what needs you (pending approvals), active deliverables, recent content, what shipped, and health signals.

It is off by default. The briefing is the one thing that runs a model on its own, with nobody watching, so it is opt-in: turn it on in Settings → Workspace, where its time, frequency and sections are also configurable.

Note — The briefing is assembled by the backend, not by an agent — because the agent runtime is sandboxed from the database and can't see approvals or health on its own. The COO only writes the human-readable summary line on top.

Next#

• The team & delegation trust — how agents hand work to each other.
• Models, providers & secrets — what powers an agent.