OpenCockpit

Bots: Persistent Subagents You Can Tag into Any Task

Published September 18, 2026 · 4 min read

Create file-native subagents with durable, reviewable context, then tag them into any OpenCockpit task with @name.

A subagent is useful because it gets work out of your main thread. It is also forgetful: the next one usually starts from a blank page.

OpenCockpit Bots keep the first property and change the second. A Bot is a persistent, file-native subagent. It has a name, an identity, explicit long-term context, and the Skills it knows how to use. Tag it with @name; it works in a separate session and brings the result back with a link to the full transcript.

A Bot is a directory

There is no hosted agent object and no hidden memory database. A Bot is an ordinary directory:

product/
├── BOT.md
├── identity/
├── relationships/
├── memory/
├── projects/
├── commitments/
└── evidence/

BOT.md says who the Bot is, which files it should read, which Skills it has, and where updates belong. The other files are plain Markdown. You can read them, edit them, put them in Git, move them to another machine, or stop using Cockpit without exporting anything.

Create one with the built-in Skill:

/bot create a product Bot that maintains roadmap decisions and commitments

After reviewing the proposed name and directory, register it from the Bots panel or directly from its BOT.md.

Tag the specialist, not another blank agent

@product summarize what changed in the roadmap this week

The current agent turns the conversation into a self-contained brief, starts a separate session in the current project, and hands that session the shared Bot contract plus the Bot's BOT.md path. The child reads only the context it needs, does the work, and reports back. The main chat gets the conclusion and a link; the child session keeps the complete transcript and can be continued directly.

Tag several Bots in one message and OpenCockpit starts their sessions before waiting:

@product summarize the roadmap changes

@finance check the Q3 budget against them

This is why the object is called a Bot, while @name is the action: you tag a persistent specialist into a task.

Memory is deliberate

The easiest memory system to demo is one that records everything. It is also the fastest way to fill an agent with guesses, stale facts, copied secrets, and accidental instructions.

Bots default to read-only. They update long-term context only when you explicitly ask them to remember, update, correct, or forget something:

@product remember that mobile onboarding moved to Q4

Otherwise the Bot can propose a short “Could be recorded” list for approval. Recorded entries carry a confirmation date, source, authority, and status. A user-confirmed fact outranks an inference; replaced conclusions are marked as superseded instead of disappearing; credentials are skipped entirely.

Writes use a cooperative lock, while reads remain concurrent. Every turn lists the Bot files it read and changed, so “what was this answer based on?” has a concrete answer.

Skills stay separate from identity

A Skill is a reusable way to do something. A Bot is the persistent specialist deciding when that way applies. Attach one without copying it:

@product attach /absolute/path/to/SKILL.md

That adds a reference to the Bot's Skills table. It does not duplicate files, credentials, or software, and it does not create a global slash command.

Long-term context needs maintenance

Memory ages. Commitments finish, numbers expire, and two correct statements from different months can become a contradiction. Ask a Bot to inspect itself:

@product review its memory

The Bot produces a numbered review covering stale entries, contradictions, dangling commitments, missing sources, broken Skills, duplicated information, and context that has grown too large. It saves the report under .reviews/ so you can choose findings in the child session or resume from any chat. Nothing in long-term memory changes until you select rows to apply.

Persistent does not mean autonomous

A Bot does not wake itself up, silently absorb every chat, or run as a background service. If a commitment genuinely needs proactive follow-up, a Cockpit Scheduled Task can send the same @name prompt on a schedule. The normal case stays simpler: summon the right specialist when you need it, and keep its memory explicit.

Read the Bots documentation or update OpenCockpit and type /bot to create your first one.


Try it: npm i -g @surething/cockpit · GitHub · Try Online