Turn a repeated job into a Bot you can trust to run itself

A Bot doesn't attach to any chat Session. You can run one manually, trigger it on a schedule through a Routine, or have one Bot dispatch a task to another Bot.

• Collaboration & Recovery
• Agent & Tasks
• Getting Started

Where to find Bots in the product#

Open Bots from the left sidebar for six areas:

• Bot library: view Bots, published versions, lifecycle, manual runs, and Memory.
• Build & refine a Bot: talk to that Bot's own restricted self-builder, then have the owner authorize, test, and publish it.
• Bot-to-Bot: create a Direct conversation or a Group of 2 to 6 Bots.
• Routine: trigger BotRuns repeatedly with cron and an IANA timezone.
• Runs & Recovery: handle approvals, extra input, cancellation, artifacts, and UNKNOWN recovery.

Bot compared to kxen's other execution units#

A Bot uses kxen's unified model routing and resource management — its definition never pins a specific provider model. Model, account, concurrency, RPM, budget, and circuit are still governed by the current MRM configuration.

Explicit boundaries#

• Every member of a Bot Group is a Bot, not a real person — there's no group chat, no contacts, no read receipts, no presence, and no human ACL.
• Bot-to-Bot is kxen's internal, persistent collaboration protocol — it doesn't expose a public Agent Card or an external A2A endpoint.
• Bots don't provide a shared cloud computer, a shared browser profile, shared credentials, or a remote-desktop pool.
• There's currently no Bot Marketplace, no public discovery, install, rating, billing, or settlement.
• When one Bot sends a Message, Task, or ArtifactRef to another, it never hands over its own tool permissions to the recipient.

Create your first Bot from Build & refine a Bot, then go back to the Bot library to run it manually. Later changes to its definition always start from that Bot's own build conversation.

Build & refine a Bot#

Bots -> Create Bot turns a natural-language requirement into a verifiable Bot definition. There's no single global Builder Bot with a fixed persona. From the moment a Bot gets its own identity, it holds a restricted self-builder capability that serves only its own definition, and replies to you under its own name.

The self-builder only runs inside a design-time BuilderSession — never inside a published BotRun. It can ask follow-up questions and propose a complete draft, but it can never obtain permissions, execute tools, or publish on your behalf.

Creation flow#

1. Enter the Bot's name, plus what it needs to do repeatedly long-term, its inputs, outputs, and success criteria. The system creates that Bot's stable identity and BuilderSession.
2. The Bot replies, asks follow-ups, and generates a draft through its own self-builder capability, grounded in the runtime capability catalog.
3. Keep talking to that Bot to review its system prompt, input/output contract, budget, tools, connectors, paths, and Bot-to-Bot policy.
4. Expand and review capability, Workspace paths, connectors, contract, budget, context, memory, approval, and Bot-to-Bot policy; after you enter an authorization reason, that grants the full permission snapshot bound to the current draft hash.
5. Run a controlled test and save the structured test result.
6. Publish an immutable revision once deterministic validation passes.

The BuilderSession is durable. Switch pages or restart the app, and choosing "Chat with Bot to edit" from the Bot library automatically restores its most recent active build conversation — you never need to save or enter an internal Session ID. Start a fresh conversation with the same Bot whenever you want a separate context for a new round of adjustments.

What the self-builder can and can't do#

• Every new reply and draft change is attributed to the target Bot's identity — no other Bot can modify this BuilderSession.
• The self-builder can only choose capabilities that actually exist in the current runtime catalog.
• It can't add a Workspace path, connector, MCP server, or approval exemption on its own.
• A design-time conversation carries no tool permissions that inherit into a real BotRun.
• It can't run tools, create a Routine or Group, or bypass the controlled test, validation, or owner publish step.
• Grant, controlled test, validation trigger, publish, and cancel are all independent owner- or runtime-issued commands, never Bot self-service. An authorization reason can't be empty.
• A tool, Skill, or connector that doesn't exist fails validation — it's never published as a placeholder capability.

Evidence stays bound to the exact draft#

Authorization, the controlled test, and the validation report are all bound to the draft's exact content hash. Any draft edit that would change execution behavior invalidates that evidence — you have to re-authorize, re-test, and re-validate.

This rule stops someone from testing a low-permission definition and then quietly widening paths, connectors, budget, or peer policy right before publishing.

Checklist before you publish#

• Input and output contracts actually cover real callers.
• Required fields match the data used in the controlled test.
• Capabilities and paths are the minimum set the task actually needs.
• Every connector belongs to the current Workspace, and the MCP server grant matches exactly.
• Approval policy doesn't turn a high-risk side effect into a standing permission.
• Budget, turn, tool-call, and collaboration-depth limits are sufficient without being needlessly wide.
• The Bot-to-Bot direct policy only lists peers that genuinely need to collaborate.

Once published, run the Bot manually from the Bot library, then create a Routine or a Bot-to-Bot conversation as needed.

Bot library#

Bots -> Bot Library is where you manage drafts, published versions, lifecycle, manual runs, and independent Memory for every Bot. The list supports searching by name or Bot ID, filtering by lifecycle state, and always includes trashed Bots so the Restore action never disappears just because a Bot went to the trash.

Definition and revision#

A Bot definition includes:

• Display name, objective, and system prompt.
• A text/plain or application/json input/output contract.
• Allowed tools, Skills, connectors, and Workspace-relative paths.
• Approval policy, per-run budget, and Bot-to-Bot policy.

A draft can keep changing. Publishing produces an immutable revision — an existing revision is never overwritten by a later draft. A BotRun locks in its revision and permission snapshot the moment it's queued, so a task already running doesn't drift just because a new draft got published in the meantime.

Lifecycle#

Restoring a Bot returns it to paused — you have to explicitly Resume it before it accepts work again. Pausing, archiving, or trashing stops any pending work and pauses associated Routines, instead of letting an old queue keep running silently.

Running one manually#

Pick an active Bot, fill in the task in the run input, and create a BotRun. The UI encodes your data according to the published revision's input contract:

• text/plain accepts non-empty text.
• application/json requires a JSON object, and checks it against the required fields the definition declares.

Input that doesn't match the contract never gets queued. Once queued successfully, track execution, approvals, results, and artifacts in Runs & Recovery.

Memory#

Bot Memory is independent of Session history, and holds facts, preferences, or controlled working state you want reused across Runs. Every Memory entry has its own identity and version, and updates check for concurrent version conflicts.

Never write API keys, OAuth tokens, passwords, or other credentials into Memory — secret-like content gets rejected. Connector credentials still stay managed by kxen's own authentication and MCP configuration.

Permission boundaries#

• Workspace paths must be explicitly authorized by the owner as safe relative paths.
• Connectors must bind to the same Workspace; MCP tools are only exposed per exact server grant.
• Bots currently can't use LSP, because cross-file location results aren't yet filtered by Bot path grant.
• Message, Task, Memory, and ArtifactRef never expand capability or skip Approval.
• Each Bot can have at most one nonterminal Run per Conversation at a time.

To change a Bot's capability or contract, choose "Chat with Bot to edit" to enter its own build conversation. The app automatically restores the most recent active BuilderSession — no internal Session ID to manage — and once changes are done, the owner authorizes, tests, and publishes again.