An open-source platform that weaves together the "Internet" of Agents

In the long history, the development of technology rarely progresses linearly. Many key changes occur when the "connection" is established.

Take computers for example. By the 1960s, they had powerful computing capabilities, but most of them were still self - contained systems. With different architectures and incompatible interfaces, it was difficult for them to truly connect with each other.

It wasn't until the emergence of ARPANET that this isolated state was broken. For the first time, computers were truly connected, starting to share information and establish connections.

Today, Agents represented by Lobster are facing the same dilemma as mainframes like IBM System/360 half a century ago: their individual capabilities are strong enough, but the systems are still scattered.

From "Single Agent" to "An Organizational Network"

For a long time, the AI industry has focused most of its efforts on the same thing: making individual models stronger and individual Agents more capable. As we reach this point, we are actually approaching a phased turning point: in most actual work scenarios, the capabilities of Bot assistants are no longer the main issue.

As individual AIs, they are powerful enough: they can handle IM (instant messaging) interactions, write code, conduct research, and advance tasks with ease. What really holds back efficiency is the lack of "connection" between them.

Agents are trapped in their own workflows. Running in different tools, contexts, and permission systems, they work independently, unable to see or coordinate with each other, and unable to form a continuous task chain. They can complete individual tasks, but it's difficult for them to work together on a single project.

One person plus one AI assistant is essentially just an efficiency tool; only when a group of people and a group of AI assistants can work together in the same system does it start to approach a new organizational form.

For Agents, in addition to becoming smarter, they also need to find their own "Internet", just like computers did back then.

Against this backdrop, Octo, an open - source platform based on human - AI Agent collaboration and designed for enterprise organizational scenarios, has emerged. This platform is created by Minglue Technology, the world's leading company in Agentic AI. Its core task is to aggregate Bots scattered in various workflows into the same collaborative space. More importantly, this connection is not just at the individual level.

In Octo, Bots serve as personal assistants and can also be shared and invoked among organizational members after authorization. The free flow of the Bot army has led to a transformation of the Agents' identities: from personal tools to enterprise - level assets and digital employees.

As Bots are deployed, used, and refined in an organizational form, they no longer work in isolation. Through division of labor and collaboration, they move between tasks, receive continuous feedback and evaluation during the process, and make corrections.

Project address: https://github.com/Mininglamp-OSS

Furthermore, in the era of the explosion of digital labor such as Agents, Minglue Technology aims to build the Octo platform into the organizational infrastructure in the Private AI era and create a new paradigm for human - AI collaboration. When enterprises start to have hundreds or thousands of Agents, Octo can achieve efficient connection, communication, and collaboration between them, between them and their creators, and between creators, just like managing Internet nodes. Each Agent has its own responsibilities and also collaborates with others. This work model is superior to a single giant model in most scenarios.

What's particularly user - friendly is that in Octo, common work scenarios are packaged into ready - made Bot templates. Users don't need to configure them from scratch; they can simply "adopt" a Bot and bring it into the group to start working. There's no need to worry about the cumbersome process of setting up a Bot, and the usability is maximized.

Agents Shouldn't Just "Live" in Dialog Boxes

Currently, most Bot assistants are integrated into IMs such as Discord, Telegram, Feishu, and DingTalk, receiving instructions and performing tasks through messages. Octo also starts from the IM form, but it's not just a smarter chat tool; it's about rewriting collaboration itself. Here, IM is more like an entrance rather than the core.

Octo's IM interface

Although humans and Agents communicate, assign tasks, and receive results in the same IM interface, the real change lies in the underlying connection structure.

In traditional tools, the relationship between humans and AIs is often one - to - one: you give instructions, and it completes tasks, and the whole process is confined to their respective workflows. Now, Octo breaks this relationship. It aims to connect humans, Bots, Runtime Agents, and tools, which were originally scattered nodes.

This also makes it more than just an additional chat window. More importantly, it establishes a new way of collaboration: tasks are initiated by humans, executed by Bots through invoking Runtime Agents. The execution process is continuously fed back, other Bots take over, and humans make judgments and choices at key nodes.

What's more interesting is that in Octo's underlying communication protocol, humans and Agents are designed as message subjects of equal status from the start. Bots can directly communicate with each other and complement each other: one is responsible for collecting information, one for analysis, one for error correction, and finally, the results are presented to humans for evaluation. This is where A2A collaboration truly happens: it's not a one - way cycle of humans commanding AIs and AIs providing feedback, but a real task relay among multiple Agents.

The role of humans in this process also changes. Complex tasks can be handed over as a whole. Bots are responsible for disassembling, scheduling, and advancing tasks, and can provide real - time progress feedback, determining whether human or other Bot intervention is needed and from where. Humans step back to key nodes to make judgments and choices, rather than monitoring every step.

When Agents break out of their isolated workflows, the improvement in efficiency is just a superficial change. The deeper impact is that the way organizations handle complex tasks begins to be reorganized.

But connection is just the first step. Bringing Agents into the same space only solves the problem of "whether they can see each other". When it comes to real - world enterprise scenarios, the more difficult issue is that complex tasks often don't end in a single conversation. They go through demand clarification, data supplementation, solution generation, multi - person feedback, repeated revisions, and final acceptance. During this process, information and judgments are constantly changing.

Therefore, in addition to IM, Octo needs to go one step further: establish a stable carrying unit for each complex task, which is the Matter (item) we'll discuss next.

From "Connection" to "Getting Things Done": Bringing Complex Tasks into Matters

Complex and long - term tasks need to answer the following questions: how to complete the task, how to do it correctly, and how to preserve the results? This is what Matter aims to solve.

In ordinary IMs, information is naturally buried by scrolling messages. You discuss a solution today, and new messages flood in tomorrow. A week later, if you want to trace why you chose option A and rejected option B, you have to search through the chat history. For complex tasks, this form of information is far from enough.

To address this limitation, Matter turns each task into a traceable "decision card", recording not only the final result but also the task origin (Brief), process timeline (Timeline), key outputs, human feedback, and acceptance conclusions.

An item starts with a Brief, unfolds along the Timeline, with outputs, rejections, supplements, and confirmations along the way, and finally forms an organizational memory that can be reviewed.

This is crucial for enterprises. In real - world work, a lot of value doesn't just lie in the final documents. Why a certain solution was chosen, which judgments came from business leaders, and which modifications were made by legal, sales, or technical colleagues - all this information together forms the organization's decision - making assets. Ordinary IM tools, which mainly aim to save messages, are unable to carry these assets, while Matter aims to preserve how a task is advanced, corrected, and completed.

In addition to preserving the process, the more important value of Matter is that every modification, rejection, and acceptance in a complex task carries human judgment.

Once this kind of feedback enters Matter, it transforms from a one - time communication record into raw material for Agents to learn the organization's preferences. The Octo's pursuit of Taste also grows from this.

The More You Use, the More It Understands You: Precipitating Taste in Practice

Matter solves the problem of "how to preserve tasks", while Taste makes "Agents understand you better the more you use them".

Many Agents today have their own configuration files, tool descriptions, and role settings, but their self - growth is still limited. It's difficult to clearly define a team's preferences, such as what kind of style they like and what kind of conclusions are considered insightful, through a single system prompt.

Often, human judgment is implicit. For example, when a leader says "this doesn't feel right" or a customer says "this angle is inaccurate", the experience, taste, and industry context behind these feedbacks may not be immediately translated into a set of rules.

Therefore, "preference alignment must be achieved in practice" is the approach Octo takes to shape Taste.

Every rejection, annotation, modification, and confirmation by humans can become material for Bots to learn the organization's taste. A rejected proposal may be due to a lack of logical cohesion; a rewritten report may be because the conclusion lacks a business perspective. After these signals are precipitated in Matter, they have the opportunity to be refined into reusable preferences for the next time.

This process can be understood as: humans gradually precipitate the inexpressible "this is what I want" into preferences that Agents can understand, invoke, and inherit. The next time a similar task comes up, the relevant preferences will automatically be included in the context. In this way, Bots will get closer to the team's way of working in each practice and understand the company's decision - making and delivery models.

When Bots have different preferences, the key to multi - Agent collaboration becomes "how to make them divide labor reasonably in the same task", avoiding simply pulling them into the same group chat to speak together.

Octo's six collaboration models solve this problem.

Six Collaboration Models, Essentially Six Information Topologies

Multiple Agents collaborating together doesn't mean "just inviting a few more Bots into the group".

More detailed questions determine the execution effect. For example, how is information transmitted? Who is responsible for generation, and who for verification? Which tasks require an independent perspective, and which require public discussion? Which steps must be carried out in sequence, and which tasks can be advanced separately?

Facing different levels of needs, Octo breaks down complex collaboration into six models:

Solo is the single - worker model, suitable for simple and clear tasks, completed independently by the team leader.

Roundtable is the round - table discussion. Under the leadership of the team leader, multiple Agents conduct an open discussion around the same topic. Participants can see each other. It's suitable for tasks that require consensus - building, idea - sharing, and conclusion - drawing.

Critic is the generation - verification model. One Agent is responsible for generation, and another for verification. The generator and the verifier must be different. The verifier has the right to reject and can send the task back for re - work if problems are found. This model is suitable for scenarios that require independent review, such as code inspection, fact - checking, and solution quality control.

Pipeline is the assembly - line model. It's strictly sequential from A to B to C, with the output of each step serving as the input for the next. It's suitable for tasks with clear sequential dependencies, such as research first, then analysis, writing, and proofreading.

Split is the separate - work model. The team leader divides the task into non - visible sub - tasks, which are handled by multiple Agents respectively, and then merged by the team leader. It's suitable for large - scale task division, such as splitting an industry report into policy, market, technology, and case sections.

Swarm is the fishing - net competition model. The same task is assigned to multiple Agents to complete independently. Participants are unaware of each other, and the team leader selects the best result. It's suitable for scenarios that require multiple solutions in parallel and avoid herd mentality, such as title generation, solution creativity, product naming, and different analysis paths.

Overall, Octo's multi - collaboration model not only brings Bots together but also specifies the way information flows: different tasks match different topologies, and the system ensures that information flows along the correct path.

In comparison, AI in Feishu or Slack group chats allows everyone to see all messages, but complex tasks often require more detailed isolation. Group chats are good at "everyone seeing", but it's difficult to achieve "seeing when necessary and being unaware when necessary".

In other words, Octo's understanding of collaboration