Tips and tricks

Practical workflow recipes for running Talon as a real day-to-day operating system, not just a chat bot.

Run a real heartbeat

The most useful proactive routine is not “message me every hour.” It is “check a few trusted systems and only interrupt when something genuinely deserves attention.”

A good heartbeat usually combines:

open tasks that are aging or due soon
waiting items that have gone quiet
meetings that need prep soon
newly captured notes that may hide follow-ups
a compact footer with the next truly important task

The key is restraint. If every run produces a ping, people learn to ignore it.

Extract GTD from meeting notes

Meeting notes are often the richest capture stream in the system. Instead of treating them as passive archives, treat them as a queue of possible commitments.

A strong pattern is:

scan new or changed meeting notes
extract actions, owners, and deadlines
deduplicate against existing tasks
surface proposed follow-ups for review

This works especially well when you want the agent to help with capture without silently creating a mess of duplicate tasks.

Turn a notes folder into a wiki

Raw notes and durable knowledge should not live at the same level.

Use scheduled routines to promote recurring themes from a notes folder into a more useful wiki layer:

project summary pages
decision logs
people pages
topic indexes
missing-page suggestions
stale-page checks

This is a good example of progressive disclosure. Keep the raw notes for detail and provenance, but promote only the stable, high-value layer upward.

Send morning and end-of-day reports

Two small routines can make Talon feel dramatically more useful:

a morning briefing with today’s meetings, carried-over tasks, and likely blockers
an end-of-day summary with what moved, what slipped, and what needs attention tomorrow

These reports work best when they are short and operational. If they read like essays, people stop reading them.

Split reminders, tasks, and memory

Many automations get noisy because everything goes into one bucket. Talon works better when each kind of thing has one clear home:

reminders: something time-bound that should actively ping later
tasks: actionable work that still needs triage or execution
memory: durable facts, preferences, decisions, or reference knowledge
documents: captured notes or material that should stay retrievable as source text

That one decision point makes downstream automation much easier to reason about.

Prepare for upcoming events

Another strong pattern is a forward-looking prep routine.

Scan the next few days for:

important meetings
demos or presentations
travel or logistics
medical or administrative appointments

If the prep is small, draft it directly. If it is too large for the current run, create a concrete follow-up task with the relevant context attached.

Keep proactive messages scarce

The best automated assistant is often quiet.

Prefer:

one high-signal notification over five medium-signal ones
deduplicated reminders over repeated nudges
a small actionable summary over a verbose report

Silence is a feature when there is nothing useful to say.

Use showToolCalls for debugging

When an agent seems to be doing the wrong thing, it is often hard to tell what tools it is actually calling. Enable showToolCalls on the channel to get real-time visibility:

channels:
  - name: my-telegram
    type: telegram
    showToolCalls: true
    config:
      botToken: ${TELEGRAM_BOT_TOKEN}

Each tool invocation sends a short message like ”🌐 Using Brave Search: weather Amsterdam”. Disable it once you’ve diagnosed the problem — it’s noisy in normal use.

One persona per use case, not per channel

The persona-per-channel binding is a routing mechanism. You do not need a different persona for every channel. A better pattern is one persona per distinct use case, then bind it to whatever channels make sense:

bindings:
  - persona: assistant
    channel: my-telegram
    isDefault: true
  - persona: assistant
    channel: my-terminal
    isDefault: true
  - persona: researcher
    channel: work-slack
    isDefault: true

assistant on both Telegram and terminal, researcher only on Slack. Same config, clean separation.

Keep capabilities minimal

The default-deny capability model only works if you actually treat it as default-deny. Avoid channel.send:* unless the persona genuinely needs to send to multiple channels. Grant db.query only to personas that explicitly need it, and put it in requireApproval by default.

capabilities:
  allow:
    - channel.send:my-telegram   # specific, not *
    - memory.access:*
  requireApproval:
    - db.query                   # user confirms each query

This catches mistakes early and makes the audit log meaningful.

Test sub-agents without a running daemon

Sub-agents run in-process, so talonctl run-subagent lets you iterate on them without the full daemon:

npx talonctl run-subagent --name file-searcher \
  --input '{"query": "deployment", "rootPaths": ["/home/user/docs"]}'

npx talonctl run-subagent --name session-summarizer \
  --input '{"transcript": "User: What are my tasks?\nAssistant: Here are your open tasks..."}'

Useful for checking sub-agent output format before wiring it into the system prompt.

Use prompt files for recurring schedules

Inline prompts in schedules are hard to maintain as your routines evolve. Store them as files:

data/prompts/morning-summary.md

Check my open tasks and any pending messages. Summarize:
- What's carried over from yesterday
- What's due today
- Any blockers I should know about

Keep it to 5 bullets.

Tell the agent to use schedule_manage with promptFile: "morning-summary". Update personas/<name>/prompts/morning-summary.md whenever the format needs to change and the schedule keeps working.

Use schedule prompts for real routines

Prompt files become much more valuable once you attach them to concrete recurring jobs:

morning briefing
end-of-day summary
weekly review
meeting prep
notes-to-wiki maintenance

This keeps the routine logic editable without forcing you to rebuild the schedule definition each time.

Use talonctl doctor before every deployment

Before starting the daemon on a fresh machine or after a config change:

npx talonctl doctor --config talond.yaml

It catches the most common problems: missing directories, invalid config schema, pending migrations, missing environment variables. Takes 2 seconds and saves 20 minutes of puzzled log reading.

Use env-check after config changes

After editing talond.yaml to add a new channel:

npx talonctl env-check --config talond.yaml

This diffs your config against the current environment and reports any ${ENV_VAR} references that aren’t set. Catches missing credentials before the daemon tries to start the connector and silently fails.

Keep the system prompt focused

The system prompt is injected before every turn. Longer prompts are not necessarily better. They eat context window space and can dilute the model’s focus. Aim for 200–400 words covering:

Role and personality
What tools the agent has and when to use them
Constraints (what it should never do)
Formatting preferences

Put extensive examples and edge cases in skills instead, where they’re loaded lazily on demand.

Use the terminal channel for development

Before connecting a bot to production Telegram or Slack, develop and test the persona locally:

channels:
  - name: dev
    type: terminal
    enabled: true
    config:
      port: 7700
      token: ${TERMINAL_TOKEN}

bindings:
  - persona: assistant
    channel: dev
    isDefault: true

talonctl chat --host localhost --port 7700

Full rendered Markdown, persistent thread, same agent — no bot token needed.

Keep long-running tasks running through context compression

When the context roller is active, context compression can happen mid-task. The agent loses momentum and often stops to ask what to do next, even when it had a clear task list a moment ago.

Fix it by adding this block to your persona’s system prompt:

## Long-Running Tasks

When context is compressed mid-task, DO NOT stop to summarize or ask what to do next.
Check your active tasks (TaskGet/TaskList) and continue working on the next incomplete item.
Only stop if you are genuinely blocked.

When compression fires, the agent checks its task list and picks up where it left off instead of stalling for direction. The instruction is small enough that it doesn’t meaningfully eat context, and it only matters in the one situation where it would otherwise cause friction.

Context rotation keeps long conversations cheap

If you’re running long conversations (100+ messages), the rolling context window kicks in automatically when configured. After rotation, the agent resumes with a summary + the last 10 messages. It doesn’t know the session was rotated.

Watch for the context.rotation log line if you want to see when it happens:

journalctl -u talond -f | grep context.rotation

If rotation is happening too aggressively, increase thresholdRatio:

agentRunner:
  providers:
    claude-code:
      contextManagement:
        thresholdRatio: 0.7   # rotate at 70% of context window

Back up before migrations

talonctl migrate is non-destructive for the current schema but back up first anyway:

npx talonctl backup --output backups/pre-migration-$(date +%Y%m%d)
npx talonctl migrate

Backups include the database, config, personas, and skills in one archive.