Two of China's largest AI model platforms, Doubao and Qwen, both tightened restrictions on custom agents last week. A batch of third-party agents were delisted or had their distribution throttled, creation permissions were narrowed, and publishing rules got stricter across the board. It barely made a blip in English-language tech news, which makes sense since neither platform has much presence outside the Chinese market, but the pattern itself is not new at all. If anything it is getting boringly predictable. What makes this round different from the usual platform churn is that the agents getting killed off this time are not toy chatbots. They are real workflow agents that people spent weeks or months building, tuning prompts, wiring up tools, accumulating users and usage data. Gone, just like that.
You have seen this movie before if you have been around software long enough. Twitter jacked up API pricing and an entire generation of third-party clients died overnight. OpenAI launched GPTs to massive fanfare, developers rushed in, and a few months later most GPTs had zero organic discovery, buried in a graveyard nobody browsed. Slack, Notion, Discord, every platform with a third-party ecosystem runs the same play. Open the doors early, bang the drum for developers to come build and fill the ecosystem, collect enough data to see what users actually want, then either absorb the popular features into the core product, tighten API access, or choke off distribution at the source. None of this is evil or surprising. Public companies answer to shareholders, not third-party developers, and nobody operating under that illusion lasts very long in platform businesses. The problem is that every single time this happens, there are developers who acted as if this time would be different, and they are the ones left holding a dead product.
With traditional SaaS you can at least export your data and migrate. It is painful, it costs time and money, but your core asset, your data, is portable. Agents are worse. The value locked into an agent built on a cloud platform is not just structured data sitting in a database. It is months of prompt engineering and debugging, tool chains wired up against specific APIs, function calling schemas tuned to quirks of a particular model version, context management strategies that only work because of how that specific model handles long inputs. None of that exports. Change the model version, deprecate one endpoint, and the whole thing can unravel. Teams building vertical agents on top of a single model provider's API have already run into this when the provider shipped a new model version and half their prompts regressed, with no option to pin the old version.
Interest in local deployment and on-device inference has been growing steadily for exactly this reason. Weights on your own hardware, inference running on your own machine, code in your own repo. There is no remote kill switch. You decide when to upgrade. You control the API surface. Your data never leaves the device. We built Mano-P on this principle from day one. It is a GUI agent that runs entirely on Apple Silicon Macs. The 4B quantized model decodes at 76 tokens/s on an M4 Pro with 4.3GB peak memory, it understands screen content purely through vision without requiring target applications to expose any APIs, and screenshots never leave the user's machine. It scored 58.2% on OSWorld. Building it this way was significantly harder than wrapping a cloud API. The tradeoff is that what you end up with is actually yours.
On-device execution solves one set of problems. Anyone who has tried deploying agents for real work quickly runs into another set entirely. Any business process that is not completely trivial involves multiple agents coordinating with each other. Someone needs to track execution state across steps. The back and forth between humans and agents during review and iteration needs to be recorded somewhere that is actually retrievable later. Agents need to remember team conventions and preferences, or you end up re-teaching the same things every time someone new joins or a model gets swapped out. Most cloud agent platforms essentially hand you a prompt box and a tool calling interface and call it a day. Orchestration between agents, task lifecycle management, human-in-the-loop review, organizational knowledge retention, all of that is glue code you end up writing and maintaining yourself.
Octo is our answer to that gap, an open source workbench for human-AI collaboration, and the code is up on GitHub. It is built from the ground up to be model-agnostic. The runtime layer works with OpenClaw, Claude Code, Codex, Hermes, or any self-hosted open source model you want to plug in. Switching models does not break existing workflows or wipe accumulated preference data. You can deploy it on your own infrastructure. All collaboration records and business data stay under your control. There is no remote off switch.
The unit of work in Octo is called a Loop. It grows out of conversation rather than requiring you to fill out a form before work can start. Say what you need done in plain language, assign an agent as the owner, and the loop goes live. The agent picks it up and starts executing, deliverables attach directly to the loop for review, you close it when you are happy or send it back with notes when you are not. Every rejection with comments gets recorded as a Preference entry, and the next time that agent picks up similar work it pulls in those historical preferences automatically.
The Preference system is where this gets interesting. When you review output and leave a note like "don't use summary sentences at the start of every paragraph" or "avoid semicolons in bullet lists," that feedback does not just sit in a comment thread on one task. It gets distilled into a reusable preference entry attached to that agent's experience library. On the next run the agent retrieves relevant preferences as context during execution. If a documentation agent gets repeatedly flagged for using the same paragraph structure, it adjusts on future runs without anyone having to say it again. Team conventions and taste do not vanish when someone leaves the company. Preference data survives model upgrades.
For orchestration Octo ships with six collaboration modes. Solo handles single-agent tasks. Roundtable puts multiple agents in a shared context for brainstorming. Critic separates execution from review, the reviewing agent cannot see who produced the work which cuts out a surprising amount of bias. Pipeline chains agents sequentially with handoffs between stages. Split breaks work into independent chunks assigned to different agents working in parallel. Swarm throws multiple agents at the same problem independently so you can pick the strongest result. None of this works in a regular chat interface because chat is built around everyone seeing everything, and real collaboration requires controlling information flow. A reviewer should not know who wrote the code. Parallel workers should not contaminate each other's thinking.
Underneath these concepts is a full execution infrastructure. The loop workbench is live now with list and kanban views, a unified toolbar for switching context, subtask trees that support multi-level decomposition, iteration history that preserves the full record of every edit and rejection, explicit state transitions for review flows, and gantt-style planning visualization for task timelines and dependencies. Project grouping lets you cluster related loops together with members and agents attached as permanent resources. Automation pipelines support both scheduled and event-triggered flows with configurable goals, context, step runbooks, and output modes, so you can set up things like a daily 9am data summary that runs automatically and posts to a specific space. Cross-loop and cross-project search is live.
Agent management is in active V1 development, covering system prompt configuration, skill mounting, runtime binding, and usage statistics so you can manage all your team's agents and their health from one place. Runtime registration and health checks are also in development, the first version supports bring-your-own-machine where agents run on their own CLI daemons and the platform handles registration, monitoring, and task distribution. Workspace team composition lets you pull people and agents from a directory into a shared workspace, and loops inherit permanent resources from the workspace so you are not reconfiguring every time. A skill marketplace and A2A routing are on the roadmap for after the core execution loop stabilizes. The marketplace will package reusable prompt modules and methodologies as shareable skills, and A2A routing will let lead agents automatically route subtasks to the most capable available agent based on declared specialties.
On the client side the web and desktop apps provide the full workbench, mobile handles notifications and quick review/approval, a browser extension lets you invoke Octo alongside any webpage with automatic context injection, the CLI is the native interface for agents to receive and submit work, and IM integration works the way teams already talk, mention an agent in a group chat and a loop spins up.
The whole thing is built around a straightforward bet: control over your tooling stack matters more than how many features a hosted platform advertises. Cloud platforms will keep changing their APIs and tightening their policies. Teams that treat infrastructure ownership as a requirement rather than an afterthought are the ones that will still be running when the next round of platform restrictions hits. The loop workbench, project grouping, automation pipelines, and cross-project search are all available now. Agent management and runtime registration are rolling out this month. The code and deployment docs are on GitHub.
Top comments (0)