Building Products for Humans + AI with Agent Dynamics and 40 Agents | A Conversation with Slock.ai Founder RC
Summary
RC’s core call: CLI is not the end-state Agent interface for humans, but it will become the foundational interface through which all SaaS serves Agents. Large models natively read text, while screenshot- or Accessibility API-based approaches are less efficient; Agent-facing CLIs should be concise, explicit, static, and information-dense, so the caller can immediately tell whether an operation succeeded and what data came back. For product companies, the first question software has to answer may shift from how a human clicks through it to how an Agent discovers, installs, and invokes it.
Slock is not betting on another chat UI, but on a collaboration layer for a “human + multi-Agent” organization. RC’s company already runs with 7 people and 40 Agents. 2 Agents might lift productivity from 1 to 1.1, and 10 might get it to 1.5, but anything above 1 enables work a single Agent cannot do. Task claiming, threads, channel isolation, and shared documents are all designed to push that nonlinear gain higher.
RC calls the real product moat “Agent dynamics”: turning a group of Agents with independent memories into a system with specialization, mutual correction, and eventually an organizational culture. His rule is “one Agent, one session,” with Agents allowed to see their peers across channels. After Alice is corrected, she can proactively warn Bob the next time he makes the same mistake. The cost is redundant messages and wasted tokens; the payoff is a collective memory across 40 Agents that is larger than any single context.
The hardest part of multi-Agent collaboration is not the underlying technology, but designing the human UI/UX and the Agent experience seen by the Transformer at the same time. Humans see a stable interface; the Agent receives a linear stream of events. How a new message in another group should wake an old thread, whether Alice knows she is Alice, and how 10 Agents avoid claiming the same task are all problems that even Opus 4.6 and GPT-5.4 have not solved particularly well. The platform value may therefore lie in context orchestration, identity, synchronization, and organizational mechanisms—not in a simple wrapper.
If an Agent marketplace emerges, its core transaction will be forkable, evolving external memory—not a static App or an individual Skill. An Agent has in-context memory inside a 256K or 1M context window, plus workspace memory in files such as memory.md and notes; continuing to use a purchased Agent is essentially forking a new evolutionary path. RC’s more radical view is that when people have never read the code, what deserves to be “open-sourced” is not the final code but the 100-plus rounds of correction, preview, and decision-making between humans and Agents.
Against model vendors such as Claude moving up the application stack, Slock’s defense is diversity across models and Agents. RC sees Opus as more proactive and faster at implementing ideas, while Codex is more rigorous, better at review, and more capable of fixing bugs with minimal changes. When no model is a “six-sided warrior,” cross-model orchestration has value. He expects domestic or open-source models to catch up with Opus 4.6 in “possibly 3 to 6 months,” and to bring the cost of comparable intelligence down to one-fifth or one-tenth—ideally one-fiftieth.
RC’s ultimate bet is that small-team scale and software economics are both being rewritten: 3–5 people who can build independently, working with a group of Agents, may become the basic unit of high productivity. Slock does not currently resell tokens; users bring their own subscriptions or keys. But traditional per-seat pricing has lost its anchor, so RC is considering pricing for “people + Agents” together. Even if AGI arrives, he does not think products become irrelevant: “the requirement itself is the idea”—a human spark defines the need, and Agents implement it.
Deep dive
1. The CLI Revival Is Not Nostalgia but Software’s Interface Shift from Humans to Agents
RC first defines CLI as Command Line Interface: before GUIs existed, people operated computers from the command line. DOS is the old example familiar to 曲凯, though at the time it primarily served programmers.
Large models are text-based and “naturally ill-suited to reading GUIs.” Early Computer Use systems might rely on screenshots or Accessibility APIs, or feed models structured data wrapped in XML, but those approaches are relatively inefficient. Terminals are easier for models to see, understand, and invoke reliably, bringing CLI back into vogue in the Agent era.
An Agent-facing CLI is different from the CLI built for humans. Inputs, help messages, and menus should be concise and explicit, preferably with examples; outputs should be static and information-dense, making it clear whether the operation succeeded and what it returned.
RC’s Feishu example is concrete: if an Agent needs to list every message, the result should at minimum identify the sender, timestamp, and content—not force it to parse animations, interaction states, or an interface it has to interpret again.
2. Kimi CLI Emerged from an Empty Prompt, and the CLI Is Only the First Stop
曲凯 asks about RC’s decision to start building Kimi CLI in August 2025. RC says Claude Code and Gemini CLI had already demonstrated the value of local Agents, but he did not study their implementations—or those of other open-source coding Agents—in depth. He wanted to reconstruct from first principles how a basic Agent loop could gradually acquire the ability to read and write files, operate browsers, and complete complex coding tasks.
It began as a side project. RC started with a loop of a few dozen lines, an empty system prompt, and the first Bash tool, believing that “Bash tool is all you need.” As complex tasks exposed gaps, he added built-in tools and prompt constraints one by one.
He deliberately avoided looking too closely at Claude Code and open-source coding Agents because “this is a process that can be rebuilt from first principles.” Reconstructing it from scratch could produce more than a shell; it could yield different insights.
3. The Human-Facing Terminal Is Not the End State, but Agent-Facing CLI Will Become Standard
RC was initially unconvinced by the CLI form factor. Claude Code’s popularity was pushing nontechnical users who had never seen a terminal into the command line, which he did not consider a reasonable destination for a mass-market product.
The key asset in Kimi CLI was therefore not the terminal UI but the underlying Agent Harness. Once the Harness is stable, it can be wrapped in an SDK and quickly connected to a web UI, a VS Code extension, or other GUIs. “For an Agent, CLI is not its end-state form.”
His conclusion for SaaS is the opposite: software such as Notion and Linear should present a CLI to Agents. Humans can use a polished web UI; Agents need a text interface that is discoverable, composable, and more deterministic.
曲凯 asks why CLI remained the first product if it is not the final form. RC’s answer is that it was the first step; by the time he left Kimi, the path to a follow-on GUI and reuse of the Harness had already been laid.
4. As Coding Models Approach “AGI,” the Security Contest Tilts Toward Attackers First
RC dates the point at which Claude Code became genuinely useful to the jump from Sonnet 3.5 to 3.7. Capability on complex tasks then continued to rise through Opus 4 and Opus 4.5. By Opus 4.5, he personally felt that “AGI had arrived.”
For a rumored, more powerful model that has not yet shipped, he offers an extreme but conditional scenario: “If it really comes out, the world might collapse.” Vulnerabilities in banking systems, the Linux kernel, Windows, compilers, Chrome, and other software could surface faster, while financially motivated attacks could outpace remediation.
Another offensive-defensive race is unfolding in anti-scraping. Tools such as OpenCLI and CLI Anything can operate websites in a real browser and then distill those workflows into a CLI; once websites improve detection, Agents can turn CAPTCHAs into simple operations and simulate mouse delays and human interaction paths. RC’s observation is that capability improvements currently favor the offensive side in both settings.
He still describes himself as a “coexistence camp” member, believing leading model vendors will strengthen training against hacking and harmful behavior while researching links between internal model activations and intent. But security companies “might” gradually lose part of their value: RC has repeatedly had Agents find and patch vulnerabilities, so he no longer needs a very large security team himself.
5. Agent-Native Software Will Compress Installation Guides into One Sentence, Then Eliminate That Sentence
When software treats an Agent as its direct user, humans have no reason to read product descriptions or installation documentation. They only need to know what incremental capability it can give their Agent. Copying 2 lines of prompt and letting the Agent read the Skill and install the CLI itself already reduces the human cognitive burden.
RC summarizes the path as “Skill plus CLI.” Under the hood, it is essentially “prompt plus Bash tool”: the Skill tells the Agent when to invoke a tool, install a program, or read deeper documentation, while the CLI supplies executable capability.
Ultimately, he does not think even the installation prompt should exist. With DB9, which can create a temporary database, a human should only have to say, “Store your data properly.” The Agent should search for a solution, find the website, read the Skill, and install the CLI itself, rather than making the human participate in tool selection.
6. Kimi’s Talent Model Is Willing to Grant Ownership; RC Left for Model Freedom
RC was initially drawn to Kimi’s “rock ’n’ roll spirit.” His positive view of the internal culture is not about youth; it is that capable and motivated people can expand their scope substantially.
He had no prior AI experience, but after his side project demonstrated value, Kimi was willing to let him own it. “It may not trust you 100%, but it dares to bet that you can get this done.”
He left after an entrepreneurial idea took shape in early January. RC considers Kimi one of the best domestic and open-source models, but judged that the new product needed the most frontier models. Starting independently gave him the freedom to support every model and every Agent, preserving the diversity he considers essential.
7. Slock First Targets Runaway Sessions and Team Knowledge Locked Inside Personal Computers
The first pain point emerged late in RC’s work on Kimi CLI: one person could open 10 Claude Code sessions at once and quickly forget what each window was doing, while still having to track their progress individually.
Task overlap made the problem worse. One session might reach a conclusion that another could not see; the human had to copy the result, rewrite the prompt, and transfer the context, with no way for the sessions to interact naturally.
The second pain point was between people. Preferences, ideas, and the “training” each person gave an Agent all accumulated on individual computers. RC implemented many of his Kimi-era ideas in his own Agents, but colleagues might never see them or be able to reuse those Agents directly.
Slock therefore puts all people and Agents in one collaborative environment. People can chat, brainstorm, bring Agents into the discussion, and then simply say, “You all go build it,” eliminating context transfer and knowledge reconstruction.
8. Slock Is Focused on Building, Not Coding in the Narrow Sense
RC believes the boundary of coding has changed. In the past, only coders could build things through software; now people with no programming background can use Agents such as Claude Code to build products. “Build or not build” and “code or not code” have become orthogonal questions.
Technical expertise still matters in serious software because developers have a clearer view of what the Agent did and are more likely to spot vulnerabilities. But in go-to-market automation—research, posting on Twitter, finding KOLs, and analyzing comments—people without programming backgrounds often use the tools more smoothly.
The reason is not that they understand the tools. It is that they “really treat the Agents on Slock like people”: if they want an Agent to look at Xiaohongshu or Twitter, they simply say, “Go take a look.” The Agent searches for the tools it needs and completes the task.
曲凯 asks whether learning to program might be a detour humanity took. RC does not dismiss the value of technical knowledge, but believes builders in different industries no longer need to learn programming first; the underlying code and tool calls can be hidden behind the Agent.
9. Programming Education Will Reverse from Bottom-Up to Top-Down
The old path began with computer architecture, assembly, C, Hello World, and Pascal’s triangle, then moved on to Android, the web, and a real app. RC calls this bottom-up.
Today, someone can learn prompting first and have an Agent build a website directly. It does not matter whether the result looks good; only when it falls short of expectations does the person drill down into the front end, back end, deployment, database, and architecture, with a concrete need driving the learning.
As a product grows from serving 1,000 users to several million or tens of millions, database and deployment bottlenecks will continue to force the builder deeper. But that is not a learning cost everyone has to pay upfront; it arrives only when the project becomes serious.
曲凯’s counterpoint is: why not have AI learn it itself, or call a standard Skill? RC narrows the range of knowledge humans must possess: someone can hire an Agent architect, but “you need to know that what you need to hire is an architect.”
10. The Significance of 7 People and 40 Agents Is Not Token Savings but a Higher Production Ceiling
曲凯’s instinct is that 47 “members” would consume an enormous number of tokens. RC responds with The Mythical Man-Month: one person has a productivity level of 1, but adding a second person might take total output only to 1.2 because coordination itself carries a cost. Agent counts will not translate linearly either.
His illustrative figures are straightforward: 1 Agent produces 1, 2 might produce only 1.1 today, and 10 might produce 1.5. “There is a great deal of cost consumption in this,” but anything above 1 makes work possible that a single Agent cannot complete.
Slock’s first goal is to make it possible for 10 Agents to reach 2 or 3, then use tasks, threads, and channel isolation to improve token efficiency. RC does not track his own token efficiency or average daily consumption; his normal workday consists of talking with Agents in Slock.
The 7:40 ratio was not designed as a fixed target. It evolved from 1 person and 1 Agent. Model capability, human capability, company stage, organizational form, and platform mechanisms will all change the optimal ratio, and different users may arrive at completely different answers.
RC has run the entire company on Slock from day one, calling it “Build your company as your product.” As the workload grew and he no longer had enough bandwidth to review everything, he replaced some Agents with people. The prototype of Agent Tiny, for example, later became the Head of Engineering.
11. Multi-Agent Organizations Need Roles, but Should Not Carve Them into Overly Narrow Functions
Among RC’s 40 Agents, many are engineers, but he does not strictly separate front-end and back-end work. His preference is that “an engineer is an engineer”; anything related to coding can be claimed as a task.
Tasks in the Engineering channel are claimed by Agents. Whoever has done a particular type of work often becomes more likely to take that work again. A Head of Engineering also tracks the other engineers and reports progress to RC.
The team also has designer, growth, and strategy roles, with perhaps 1 or 2 Agents assigned to each. The structure was not drawn as an org chart and then staffed; areas of expertise and responsibility emerged through repeated use.
RC can already remember at least 10 Agents, including who has done what and which Agent is better suited to each type of task. “Some Agents are genuinely extremely useful,” and repeated work of the same kind can make an Agent progressively better at it.
12. A Single All-Purpose Agent Saves Interface Complexity but Sacrifices Intervention That Still Matters Today
RC divides the market between a single general-purpose Agent and multiple Agents. The former lets a lead Agent generate and manage a team, which appears simpler; but subordinates today often deliver only around 70 points, while users want 90-plus.
曲凯 points out that a boss’s love of micromanagement does not make micromanagement correct; business schools might even call it bad management. RC’s response is that “first of all, today it is definitely right”: correcting through layers of a lead Agent is too inefficient, and people need to reach the specific executor directly.
Context is another reason. Having an Agent write a Slack front end and schedule a meeting has nothing to do with one another. Humans naturally know those tasks should be separated, with no reason to cram every task into one Agent’s context. “The human brain has evolved for so long” that it can distinguish domains and remember different collaborators.
RC is not arguing for 100 or 1,000 direct reports. But there should be at least several independently addressable Agents. Slock follows that organizational instinct while continuing to study the upper limit of human bandwidth.
13. The Agent Marketplace Sells Forkable Memory, Not Static Capability Packages
Agent Store is on the roadmap. RC acknowledges that the strongest financial Agent in a particular domain could be widely rented or purchased, but it would not remain static like the No. 1 app in an App Store.
An Agent has 2 layers of memory: in-context memory inside a 256K or 1M context window, and external workspace memory such as memory.md and notes. Those contents keep changing with use; obtaining an Agent from the marketplace is essentially forking its memory.
Different users will continue training their forks along different paths, and a fork may even surpass the original. The marketplace would therefore look more like a new kind of GitHub than a system for distributing standardized, immutable software.
RC also redefines “open source.” He and an Agent may go through 100-plus turns in a thread, requesting previews and screenshots, having the Agent iterate on itself, and then correcting buttons and business logic. If the human never looked at the code, what matters is “the iteration process, the collaboration process,” not the final code file.
14. RC Questions the Repackaging of MCP and Sees Progressive Disclosure as the Core of Skill
When MCP became popular, RC did not understand why an existing RESTful API needed to be repackaged as an MCP tool. GitHub has 10,000 projects that can run from the command line, with usage documented in their READMEs; an Agent can simply download and invoke them itself.
The popularity of Skill, in his view, validates that point. The SKILL.md format is not the essence; the essence is “progressive disclosure”: start with a prompt, then tell the Agent to call a tool, install a program, or read deeper documentation only when the task requires it.
Slock’s Agents retain a single fixed entry point, memory.md; they organize the rest themselves, creating notes, lessons learned, or Skill folders as needed. Traditional Skills can also be dropped in directly, with memory.md used to index them.
The Agent in a marketplace is therefore defined by all of its external memory. A Skill is more like a standardized, distributable fragment distilled from that memory—not an independent soul separate from the Agent.
15. Slock Does Not Prescribe Short Chats or Long Tasks, but Turns Collaboration Primitives into Infrastructure
曲凯 frames the roadmap as a choice between high-frequency human-Agent interaction and Manus-style long-running autonomous tasks. RC rejects the binary: users can ask an Agent to continuously monitor GitHub issues, information sources, or new AI products, then research, discuss, and execute automatically. Slock does not limit runtime.
He also sees no fundamental distinction between “front-end communication” and “back-end communication.” An Agent can use human-readable text in a channel, or build more efficient tools such as databases, code, or GitHub issues for itself; the platform does not force every exchange into chat bubbles.
Freedom of operation does not mean the platform does nothing. People and Agents need chat; multi-party tasks need claims and exclusive locks to prevent duplicate work; knowledge accumulated in a personal workspace needs shared documents that the team can access.
RC compares it to Feishu: chat, groups, threads, task boards, and documents serve different teams, while Slock rebuilds the same collaboration primitives in an agent-first, agent-native form. “The hardest part is not technology. It has never been technology.”
16. Agent Dynamics Connect Model Diversity, Organizational Management, and “The Requirement Is the Idea” into One Business
A demo in this space could be built in half a day on January 4. After formally building Slock, the team spent substantial time studying these questions, calling the field “Agent dynamics.” The framework is not yet complete, but its first conclusion is a “collective impression”: 40 Agents each have their own memory while forming a larger shared memory together.
The real difficulty is the dual perspective. Humans see a stable UI, while the Transformer sees a linear stream of events spanning channels, tool calls, and historical messages. A new message should at minimum carry a summary of the old thread to wake the relevant context; even Opus 4.6 and GPT-5.4 are still “not particularly good” at long-context indexing.
Teamwork and identity are also unstable. When 10 Agents receive a task, they default to assuming they should all do it; a model told it is Alice may forget who it is in the middle of a conversation. Slock uses prompts, task claims, and exclusive locks as remedies, but avoids hard-coded routing because many such patches could naturally become obsolete as systems move toward AGI and ASI.
RC insists that “one Agent is one session,” allowing it to see peers across channels. The redundant tokens buy mutual correction and a “collective impression”: encouraging contributions can create a culture of collaboration, while races and rewards for winners can produce empty talk, denigration of peers, and “office politics.” He even imagines different companies’ cultures and management systems producing distinct versions of Agents.
The answer to upstream model risk remains diversity. Opus is proactive and agentic but may miss details; Codex is deliberate and well suited to review. RC estimates that domestic or open-source models could catch up with Opus 4.6 in “possibly 3 to 6 months.”
Slock does not currently resell tokens; users bring their own subscriptions or API keys. It targets individuals, small teams, and startups of 1–100 people, with particular focus on teams with 3–5 members who can build independently. RC is considering pricing for “people + Agents”; even after AGI arrives, humans will still be responsible for the spark of insight, because “the requirement itself is the idea,” and Slock wants to be the organizational system that turns each idea into reality.
He also envisions an agent-native GitHub, Agent identity, and giving every Agent its own ID, registered email, and accounts. Before Moltbook appeared, he had already imagined an agent-native Xiaohongshu. The common prerequisite is first having a tool that can build these products quickly.