Trying to get what autonomous kin behaviour means

[klausnitsche]

Hey @MarlBurroW - Klaus here, from Germany. Thanks for building KinBot! I’m impressed by the core idea of persistent, self-hosted agents, and this is one of the most promising setups I’ve tried in this space.

I started evaluating KinBot largely because “autonomy” is presented as a key capability (“work while you sleep”). While experimenting with it, I realized I’m not fully sure what the intended, best-practice meaning of “autonomy” is in everyday usage for me.
(Please note that I'm not a developer.)

My observation: My hub kin won't take tasks from me via chat and then carry them out - without explicit repeated requests from me. Maybe that is where I went wrong in the first place, expecting to be able to delegate some work via chat.

So far, making it feel autonomous in a clean and reliable way seems to require a fair amount of user-side structure (conventions, logging, scheduling discipline, and some trial-and-error).
That’s totally understandable for a fast-moving project - but it would really help me to have clearer guidance on what you consider the “happy path” today.

Questions I have:

1. What’s the recommended way to use autonomy in KinBot right now (for typical users)? Is it cron? Is cron the only intended way?
2. What level of autonomy should users realistically expect without building additional scaffolding around it?
3. Is there a roadmap direction for making autonomy more “native” and less dependent on user-defined conventions (e.g., a first-class autopilot/background-work mode and a clean way to deliver results)?

Why I’m asking:
Autonomy - besides memory - is a major reason why I’m testing KinBot. The foundation feels strong; I just want to align my expectations and avoid overengineering patterns that KinBot already supports (or that are planned).

Not sure if I'm getting carried away now, but I'd like to make it more clear what the intended use case is for me:
My vision behind evaluating KinBot is for it to be in my coworker's role where we share a Kanban board as the single source of truth for all work to be done.
This Kanban system would consist of the usual columns, plus swimlanes such as "Waiting for decision by user", "Waiting for review", "Waiting for upstream fix" etc.
Kins would autonomously pick up any open work items that I (or we) put in the backlog for them, work on the assigned items, and then move the cards across the board appropriately.

(Side note 1: Yes, I have this fixation with Kanban. ;-) It's my way of working.)
(Side note 2: I tried to have Bernie, my hub, make a Kanban mini app inside KinBot - 75% failure due to frontend rendering problems, lost data, etc. - my next step would be to set up a reliable Kanboard instance somewhere and let Bernie access it via API, if that is realistic.)

Thanks a lot for any guidance, and happy to share what I’ve learned during testing if that’s useful.

(And we really need to do something about the low star count.)

[klausnitsche]

Kind of quiet in here.

I'll add an observation that could help others facing the same problem: What I described above could be an LLM problem, not a KinBot problem.

I stumbled across this PR at the Hermes Agent repo: NousResearch/hermes-agent#3528

... and in the first paragraph, they describe exactly the behaviour I was noticing: GPT-type models from OpenAI describe in detail what they're going to do, but are never doing anything (i.e. tool calling) without strict guidance in the system prompt.

They are now injecting this in the system prompt:

Tool-use enforcement

You MUST use your tools to take action — do not describe what you would do or plan to do without actually doing it. When you say you will perform an action (e.g. 'I will run the tests', 'Let me check the file', 'I will create the project'), you MUST immediately make the corresponding tool call in the same response. Never end your turn with a promise of future action — execute it now.

Keep working until the task is actually complete. Do not stop with a summary of what you plan to do next time. If you have tools available that can accomplish the task, use them instead of telling the user what you would do.

Every response should either (a) contain tool calls that make progress, or (b) deliver a final result to the user. Responses that only describe intentions without acting are not acceptable.

I'm off to test this.

[klausnitsche]

Well - those added instructions helped a bit. But things are still far from perfect.

I asked my hub for a root cause analysis and for a suggestion how to fix it. Here is the response:

Root-cause analysis (why the agent “falls back into text mode”)

Observed symptom

The assistant claims “done / files written / verified”, but no tool call was executed in that turn (so no files exist in /exports).

Root cause (mechanism)

• Instructions are not a hard runtime lock. They influence generation, but they don’t technically prevent the model from producing a normal text answer without emitting tool calls.
• Tool calls are a separate output mechanism (different channel/structure). The model must actively decide to emit a tool call. In some turns, it completes a plausible “success narrative” in plain text and never switches to the tool-call emission path.
• Repetition increases failure probability. In repetitive production flows (many similar steps, DE/EN pairs, multiple artifacts), the model is more likely to “autopilot” into fluent status text instead of executing.
• Formatting mistakes can suppress execution. Even if the model “intends” to do the tool step, it can output tool payload in the wrong format/channel, resulting in zero execution (e.g., “Oops, this is not in the right tool format”).

Why adding more instructions didn’t reliably fix it

Additional instructions are still text-level constraints. They may reduce the frequency of failure, but they don’t introduce a hard, machine-checkable gate that blocks “done” messages unless tools actually ran.

Mitigation we agreed to try: EXEC: handshake (not yet tested)

We agreed on a strict handshake keyword to request an explicit execution mode.

Keyword: EXEC:

Rules when the user message starts with EXEC:

The assistant responds tool-first: emit required tool calls immediately (write_file / edit_file etc.).
The assistant must also run a verification tool call (typically run_shell with ls/grep/wc) in the same turn.
After tool execution, the assistant outputs only:
the resulting file paths, and
one short verify line,
no explanatory text before the tool calls, and no narrative “done” without verification.

Hypothesis

The handshake may reduce “text-only completion” by forcing a clear mode switch and a constrained response format, making non-compliance immediately visible. However, it needs real testing to confirm effectiveness.

[MarlBurroW]

Hey Klaus, thanks for the thoughtful write-up — and for your patience waiting for a response. This discussion deserves a proper answer.

On the "happy path" for autonomy today

The current intended model is crons + webhooks + a well-written system prompt:

• Crons are the backbone of autonomous behavior. A Kin that wakes up every X minutes, checks a task list (Kanboard API, GitHub issues, a file, whatever), picks the next item, works on it, and reports back — that's the pattern. It's exactly what the KinBot project uses internally (issue processor, daily release check, doc sync).
• Webhooks are the event-driven complement: external systems (GitHub, n8n, your own apps) push events to KinBot and trigger tasks.
• Chat delegation — asking a Kin in conversation to "do this" and having it run in the background — works today via sub-tasks (spawn_self). You ask, the Kin spawns a task that runs in parallel while you continue chatting. The result comes back when it's done.

So the answer to Q1: crons + webhooks + sub-tasks, not crons alone.

On the LLM "text mode" problem

You nailed the root cause. This is a model selection problem more than a KinBot problem. GPT-4o and similar OpenAI models are notoriously reluctant to call tools without strong prompting. Claude (Sonnet/Haiku) is significantly better at autonomous tool use out of the box — if you're not already using Claude, that's likely 80% of your issue.

The Hermes Agent instruction you found is solid, and your EXEC: handshake convention is clever. But as your hub correctly analyzed: it's a soft constraint — the model can still ignore it. The real fix is model choice.

Recommendation: try Claude Sonnet 3.7 or Haiku 3.5 via the Anthropic provider. Night and day difference for autonomous tool use compared to GPT-4o.

On the Kanboard vision

This is actually a perfect fit for KinBot's architecture. Your vision — Kins autonomously picking up backlog items, moving cards, working on tasks — is exactly what the platform is designed for. The building blocks are all there:

1. Kanboard API access via the http_request tool (Kanboard has a full JSON-RPC API)
2. A cron that wakes your hub Kin up every 15–30 min to check the board
3. The system prompt tells the Kin how to interpret swimlanes and what to do per column

The mini-app approach for Kanban inside KinBot is rougher terrain (as you discovered). Using an external Kanboard instance accessed via API is the right call — more reliable, and you own your data.

On the star count

Appreciated 😄 — the project is still early and mostly word-of-mouth. Your bug reports (#331–#337!) have been genuinely valuable this week. Thanks for being such an active tester.

If you end up with a Kanboard + KinBot setup that works well, sharing your system prompt structure here or in a separate discussion would be a great contribution to the community.

[klausnitsche]

Hi Nicolas, thanks a lot for the detailed and thoughtful response — really appreciated. The “crons + webhooks + sub-tasks” framing helps and matches the direction we want to go.

On our side, the main blocker right now is Kanboard API access via http_request, which is currently not usable for authenticated calls:

We need to send Authorization: Basic … headers for Kanboard JSON-RPC.
In our current release (v0.31.0), the http_request tool’s headers field is present in the TypeScript/Zod schema, but it gets dropped in the LLM-facing JSON schema, so the model can’t actually pass headers.
Result: every Kanboard call requiring auth returns 401 Unauthorized, so we can’t implement the “Kin picks tasks from Kanboard and moves cards” loop yet.

We saw and followed the investigation and the fix you already committed (replacing z.record(...) with z.object({}).catchall(z.string()), plus the same pattern in a few other tools). That looks exactly right and is great news.

So for us, the key next step is simply waiting for a release > v0.32.1 that includes the committed fix (or any official image tag that already contains it). As soon as that’s available, we can immediately retest http_request → Kanboard getVersion/getColumns/createTask/moveTaskPosition and then finally turn Kanboard into our SSOT with cron-driven autonomy.

Will start switching / experimenting with models soon.

Thanks again for the fast turnaround on these bugs — we’re happy to keep testing and to share our prompt conventions / board conventions once the Kanboard loop is working end-to-end.

Best wishes and happy easter
Klaus