Background Tasks

Kyber handles long-running tasks without blocking the conversation. Everything happens automatically — no special commands needed.

How it works

When you send a message, the agent decides how to handle it using a structured intent system:

1. Simple question — the agent responds directly with text. No tools, no delay.
2. Quick task — the agent handles it inline and responds when done.
3. Complex task — the agent declares a spawn_task intent with an estimated complexity, and the system creates a worker to handle the work in the background. You get an immediate acknowledgment with a task reference code (e.g. ⚡a3f1b2c4), and the worker runs independently.

The acknowledgment is generated in the bot’s own voice:

You: Can you set up a new Python project with tests and CI?

Bot: On it — spinning up the project structure, tests, and CI config now. ⚡b7e2f1a9

You’re free to keep chatting, ask about other things, or check on progress while the bot works.

Intent system

The agent uses a structured intent schema to declare actions. This prevents hallucination — the agent can’t claim it started work without actually spawning a task. Available intents:

If the agent says “working on it” but didn’t declare a spawn_task intent, the system catches this and forces it to actually commit before responding.

Task complexity

When spawning a task, the agent estimates complexity:

Status tracking

All tasks are tracked with live progress:

• Current step number
• Elapsed time
• Which tool is currently running (human-readable, e.g. “reading src/main.py”)
• Recently completed actions
• Final results when done

Ask the bot “what’s the status?” or reference a specific task code and it checks the tracker and responds immediately — no waiting for the task to finish.

Workers

For complex work, the agent spawns workers — lightweight agent instances that run independently in the background. Workers inherit the bot’s full personality (from SOUL.md), so every response — including the final result — sounds like your bot.

Workers have access to:

• read_file, write_file, edit_file, list_dir — full file system access
• exec — shell command execution
• web_search, web_fetch — web access

When a worker finishes, its result is delivered directly to the user. There’s no intermediate summarization step — the worker’s final message IS the deliverable, already in the bot’s voice.

Step budget and wrap-up

Workers run until they’re done or hit their step limit. When a worker approaches ~80% of its budget, it’s prompted to start wrapping up. If it exhausts all steps, a final summary turn runs with tools disabled — the worker must deliver its findings. There’s no scenario where a task completes silently without a result.

If the worker’s final message is unusable (too short, contains prompt leakage, or is just meta-chatter), a finalization turn forces a proper user-facing response. This runs up to 3 retries to ensure quality.

Context management

For long-running tasks that generate large message histories, the worker automatically compacts older messages to prevent unbounded context growth. It preserves the system prompt, a summary of earlier work, and the most recent messages. Tool message ordering is maintained to avoid breaking the tool-calling schema.

Progress updates

When backgroundProgressUpdates is true in your agent settings, the bot sends periodic progress pings to the chat channel while a task is running. These are lightweight status updates so you know the bot is still working. Set to false for silent execution.

Task persistence

Completed tasks are persisted to disk as JSONL. This means task history survives gateway restarts and is available in the dashboard’s Tasks view. Active (in-progress) tasks are in-memory only — if the gateway restarts mid-task, those tasks are lost.

Concurrent channels

Messages from different channels (Discord, Telegram, WhatsApp) are fully independent. A long task triggered from Discord doesn’t block Telegram messages. Even within a single channel, multiple conversations can run simultaneously.