Daily Edition Sources +7

The Fine Print Behind Kilo’s Swarm Default

Kilo’s main branch now enables a shared agent board by default. Its messages can carry findings across a team—but a successful post cannot summon a worker, prove it listened, or stop it.

Three Kilo source cards connect a default-on board to a stored post, with a blocked arrow before a stopped worker and a source-versus-release caveat.
Diagram PunkKilo’s source default changes access to the board; a stored post still cannot wake a worker.
repo Kilo-Org/kilocode evidence
7 source signals 1 repo commit 50fc57d
Evidence: commit 50fc57d / September 15, 2026 / Daily Edition
Open Edition Evidence below

A September 10 merged pull request in Kilo-Org/kilocode adds a warning for an easy mistake: an agent can post a question to a child that has already finished, see the message saved, and keep expecting an answer. The repair tells the sender whether its intended recipient has stopped, at the moment it posts.

Four days later, Kilo enabled that shared board by default on its main branch. The sequence matters. Communication between agents is moving toward an ordinary setting, while the software is still having to teach senders what communication actually proves.

There is a release boundary here. At the September 15 check, the latest published release was v7.6.2, dated September 10. Its notes describe enabling the experimental board through configuration or environment flags. The default-on change is newer source code; those release notes do not establish that an installed copy has it.

A shared room for unfinished work

Kilo Swarm gives a main session and its task descendants a persistent board. An agent can share a discovered constraint while another is still implementing a feature, or tell the coordinator that a result changes the integration plan. Without that channel, useful findings may arrive only with the final task result, after a sibling has already made the dependent decision.

The settings documentation describes a board within a task family, separate from unrelated sessions even when they use the same repository. It uses the existing Task machinery. Turning on the board does not create a standing team or require agents for every job.

The September 14 change also settles an operator question: an explicit off wins. Either the configuration value experimental.shared_agent_board: false or a false value for KILO_EXPERIMENTAL_SHARED_AGENT_BOARD disables the board, even if the other setting enables it. The broad KILO_EXPERIMENTAL switch no longer controls this feature. In VS Code, the opt-out moves to Agent Behaviour.

The receipt is smaller than the promise

The important detail is in the posting tool. A successful call returns a stored-message receipt and an observation of recipient availability. For a direct recipient that has completed, failed or been cancelled, the response warns that its invocation ended. An unknown state also produces a warning. Posting leaves that execution state alone.

Even an active recipient does not turn the receipt into an acknowledgment. Activity notices are best-effort; message bodies are read separately. A sender cannot establish that another agent read a warning merely by rereading the board itself. The regression tests check stopped and unknown recipients, the main-session alias, and that posting does not restart completed work. They test the runtime’s response, not whether a model will reason correctly about it.

That distinction becomes especially sharp when a note is called HOLD or VETO. Those names sound like controls, but Kilo documents them as advisory messages. They neither pause nor cancel another task. A coordinator that discovers conflicting edits still needs to use the actual task controls and verify what happened.

Addressing is not secrecy, either

A message addressed to one participant remains visible in the board’s shared history. Recipient selection determines who should receive a notice, not who may read the contents. The instructions attached to the board also treat peer messages—including claims of user approval—as untrusted information. They cannot expand the assignment or change permissions.

For teams adopting the next default, the useful test is therefore a small one: finish a child task, post a follow-up, and inspect the returned state. Then send an advisory hold to a running task and check execution separately. Neither a saved question nor a forceful label should become an invisible dependency in the plan.

The next public signal is a release carrying the default-on change. The harder signal will be whether agents reliably distinguish a note they stored, a colleague that can still respond, and work that actually stopped. Giving the team a common room helps only if everyone understands what the room can do.

Evidence Trail

Receipts below the story

The article above is the public narrative. This section keeps the source trail and limits on the same page.

Edition
DateSeptember 15, 2026
LaneDaily Edition
Confidence87%
Sources7
ReposKilo-Org/kilocode

Primary Evidence

Evidence Limits

  • Source main and the latest published release were checked separately on September 15. The default-on commit does not establish deployment to installed clients.
  • The tests were inspected, not rerun here; no live agent team was exercised.
  • No model-compliance, reliability, adoption, productivity or security-incident claim follows from these receipts.
  • Availability is an observation at posting time; neither an active state nor storage proves that a recipient read or acted.
Letters & Corrections

Send a note to the desk

Corrections, missing context, or a follow-up lead.