← Knowledge Notes
AI Engineering / Knowledge note · English

The Product Problem in Multi-Agent Work: Knowing Which Task a Message Belongs To

RC runs his company on Slock, growing from one person to seven people and forty agents. That describes the contemporary team, not an experimentally optimal ratio. More useful are his responses to duplicated tasks, misplaced context, drifting identity and limited human review capacity.

Source collection:42 Zhangjing · Episode notes · Published here:2026-10-18 · Original release:2026-04-23

42 ZhangjingEpisode analysisAI Engineering

42 Zhangjing episode analysis · Human and agent collaboration
Guest: RC, founder of Slock.ai and author of Kimi CLI | Host: Qu Kai
Published: April 23, 2026 | Duration: 66 minutes 10 seconds | Prepared: October 18, 2026
Official episode and introduction

What does putting forty agents into a group actually add?

RC runs his company on Slock, growing from one person to seven people and forty agents. That describes the contemporary team, not an experimentally optimal ratio. More useful are his responses to duplicated tasks, misplaced context, drifting identity and limited human review capacity.

An agent here means a model system that uses tools and continues executing tasks. Adding bots to a group creates an entry point; collaboration also needs responsibility, shared results and correction. RC calls his observations “agent dynamics.” This is a working concept in product exploration, not an established scientific theory demonstrated by the episode.

1. Interfaces for agents differ from interfaces for people using agents

Episode reference: 00:41–08:10. A CLI, or command-line interface, operates software through text commands. RC distinguishes tools an agent calls from the human entry point to a local agent, such as Kimi CLI.

Agent-facing tools need clear inputs, examples in help and outputs specifying success, failure and returned data. A message list needs fields such as sender and time more than animation. Human-facing software can add web or editor interfaces around a stable execution core. Nontechnical users need not learn a terminal because one exists underneath.

RC recalls starting with a short execution loop and Bash, adding specialized tools and system instructions when tasks failed. Editorial interpretation: Observing the missing capability before adding mechanisms explains value better than accumulating tool lists. Strong command execution also creates permission boundaries: being able to operate a computer does not authorize every action.

Speculation about security competition, captchas and models leaking information is not presented here as established technical fact or operating instruction.

2. A shared environment reduces context transfer without eliminating communication

Episode reference: 17:31–24:03 and 24:31–31:59. RC begins with a concrete frustration. Many local sessions become difficult to track; overlapping tasks require copying conclusions and repeating background. Preferences developed through personal interaction are also difficult to share with colleagues or their agents.

Slock aims to place people and agents in one environment for discussion followed by execution. A single general assistant and several specialized assistants each impose costs. RC argues that contemporary models often need correction, and direct access to a subordinate executor can avoid errors from intermediaries. Unrelated tasks need not share one context—the messages and material currently available to a model.

The host asks whether this merely accommodates a human desire to micromanage. RC’s answer depends on current capability: a desired result above the initial output requires adjustment. Seventy- and ninety-point examples are illustrative, without measured quality results. Productivity figures such as 1, 1.1 or 1.5 are likewise hypothetical, not measured multi-agent gains.

Editorial interpretation: Assess communication alongside completed quality, total waiting and usage cost. Seven people and forty agents evolved through practice. More executors may expand parallel work while also increasing repeated background and review.

3. Task claims need exclusive state, and messages need topic context

Episode reference: 39:38–47:06. A flexible platform still contains common needs: communication, assignment, shared documents and threads. Several agents may interpret one group request as their own task. RC adds a claim tool: the first claimant receives exclusive state, and subsequent claims fail. A reminder to avoid duplication cannot provide the same coordination guarantee.

Context creates a subtler problem. People see channel lists, previous messages and the current thread. Agents receive a linear event stream. Before a message arrives, an agent may have completed many actions in another channel. A message ID alone may not identify a continuation of an older discussion.

RC proposes supplying earlier summaries, topics and relationships to restore orientation. This also shows why a needle-in-a-haystack test—finding a designated detail in long text—cannot independently establish collaboration across tasks.

Identity can drift too. Even when Alice is mentioned, a model may not consistently recognize itself as Alice. System instructions, reminders during execution and message routing become design choices. RC prefers limiting some restrictions in anticipation of model progress. Editorial interpretation: For real writes, duplication prevention and permissions still require inspectable mechanisms rather than expectations about future capability.

4. Shared correction can spread experience and spread error

Episode reference: 32:12–37:10 and 47:27–51:46. RC reports Alice being corrected, then later warning Bob about a similar mistake. Public interaction lets experience cross session boundaries. This is one observation, not proof of reliable collective intelligence among forty agents.

He also compares prompts asking agents to complement one another with prompts rewarding competition. The latter reportedly produced empty statements and criticism of others, which he calls “office politics.” No controlled experiment, sample or measurement is supplied. The transferable caution is that objective wording can change output; confidence and criticism are not evidence.

External memory provides continuity across runs. RC uses a memory file as an entry point indexing notes, lessons and tool instructions. Progressive disclosure means reading an overview first, then details when needed. Sharing an agent could resemble copying evolving experience rather than downloading a fixed application. A marketplace remains on the roadmap, not a completed market.

Editorial interpretation: Reuse requires checking applicability, tools, environment and verified results. RC’s dismissal of code while emphasizing conversation is rhetorical; executable code, dependencies and verification still belong to reproduction. Publishing a process also requires checking private material and permission.

5. People join to place review and responsibility with someone able to own them

Episode reference: 19:42–24:03 and 52:51–01:04:12. RC suggests that nonprogrammers can start building and learn deployment, databases and architecture as obstacles appear. However, technical understanding helps detect software defects. Even hiring an architect requires recognizing that one is needed.

Team growth follows similar reasoning. Agents initially handled development, growth and research. As work became more complex, RC could no longer review everything and brought in people with domain responsibility. The intended audience expanded from individual builders to teams of one to a hundred, an audience definition rather than a validated market size.

Model diversity forms another platform claim. RC found Opus proactive and Codex careful in review at the time. This usage observation needs retesting with versions rather than converting brands into permanent personalities. Supporting several models does not automatically establish a business defense.

The product then did not resell tokens; users brought subscriptions or keys. Pricing by human and agent seats was still under discussion. Asked whether stronger models make products meaningless, RC argues that people still express needs and judge fulfillment. Having agents implement every idea remains a vision, requiring separate evidence of completion and payment.

Check collaboration through one cross-thread handover

As an editorial exercise, assign two related tasks to two executors. Insert a new message in another channel, then return to the old thread with a revision. Retain evidence of:

  • Who claimed each task and whether others stopped duplicate execution.
  • Which earlier context accompanied a new message and whether it was assigned to the correct task.
  • Whether one executor’s correction cited actual results or its own guess.
  • Whether outputs and conclusions reached a shared location with inspectable completion evidence.
  • Human review time and whether another executor reduced total delivery time.

Use small tasks with readable results. Busy conversation, agreement among agents and greater numbers cannot independently establish better collaboration. A low-frequency fixed transformation may still be cheaper through a deterministic process.

Listening guide and related reading

  • 00:28: Two audiences for CLIs.
  • 17:32: Session management and transferring background.
  • 26:04: The evolving seven-to-forty team.
  • 39:27: Claims, documents and communication.
  • 42:02: Human screens versus model event streams.
  • 50:18: Cooperation and competitive prompts.
  • 59:42: Team size, review capacity and pricing.

Related themes: agent collaboration, shared memory and responsibility. Compare Pokee’s decisions and action chains and Dingding on evaluation to examine how coordination mechanisms affect completed tasks.

Source boundary: The complete supplied transcript, earlier note and official introduction were read. Audio was not replayed sentence by sentence, and Slock was not tested. Team counts, behavior, model comparisons, pricing and roadmaps retain their April 2026 context. Closing music is not treated as interview argument; security and industry-endgame speculation is not asserted as fact.