DEV Community: Mininglamp

Octo Loop Launches: Taking Long-Running Tasks Beyond the Chat Window

Mininglamp — Thu, 06 Aug 2026 03:15:50 +0000

A single Agent, a single conversation, a task that wraps up in a few minutes — that experience works fine inside a chat window. But once a task stretches to hours, requires several executors to collaborate, or expects a human to step away and come back later, problems start to show: context gets scattered across hundreds of messages, and it becomes hard to tell at a glance which task is running, which is waiting on someone, and which has been delivered. The instructions, skills, and external system connections someone has carefully tuned also tend to live only on that one person's terminal or account, and are hard to reuse.

These problems aren't determined by model capability alone.

As Agents move from lightweight tools that "write a snippet of copy" toward hours-long research, development, and data analysis, the limits of the chat window as the sole carrier become apparent. Chat is well suited to communication, discussion, and exploration — but not as the only execution vehicle for long-running work.

Tracking a long-running task through chat logs is like managing a project through a group chat: you can talk, but it's hard to keep answering "Who owns this? Where are we now? What's blocking us? Where is the deliverable?"

What really determines whether an Agent can get things done isn't a single prompt turn — it's how you design the loop from task creation to delivery. Tasks need to become the center of collaboration, instead of having task state ride on top of a message stream.

Mininglamp recently launched the Loop feature in Octo — an Agent collaboration space centered on tasks. It turns a piece of work into an independent task with a goal, an owner, a status, an execution trace, and a deliverable: conversation is for discussion and decision-making, and Loop is for driving, tracking, and accepting the work.

Octo：https://github.com/Mininglamp-OSS

What Is Loop

Loop is a task-centered Agent collaboration space.

Inside Loop, a piece of work is no longer just a message buried in chat history — it becomes an independent task with a goal, an owner, a status, an execution process, and a deliverable, and it can be assigned to a member, an expert, or an expert team. Experts and expert teams run inside a designated runtime, and their state, logs, and results all stay with the task.

A task typically moves along the following path:

· Creation and assignment: Write out the goal, background, constraints, and acceptance criteria, then set the owner, project, priority, and deadline.
· Execution and logging: The expert executes the task using its own instructions, skills, and tool connections; execution state, key logs, and results are all saved together with the task.

· Help and confirmation: When information, permission, or human judgment is missing, the task moves into "needs assistance"; once results are submitted, it moves into "pending confirmation", to be reviewed by a person or by an assistant connected to the Octo CLI.

· Feedback and continuation: If the result doesn't meet the requirement, the person can provide clear feedback so the executor can continue; once the result meets the requirement, the task is marked complete.

What Loop provides today is a task path that is trackable, feedback-capable, and continuable. It lets people see whether a task has already started, is running, is waiting for confirmation, or needs assistance, while also giving the team structured raw material for maintaining expert configurations, accumulating skills, and reusing working methods.

The difference between Loop and a one-off conversation: conversation carries the discussion; Loop carries the full task process from delegation to acceptance.

Conversations Stay Conversations, Tasks Stay Tasks

Loop can pick up work that converges out of an IM discussion, and it can also be created directly by a person or triggered by automation.
In a conversation, everyone can first talk the goal through and hash out any disagreements. Once the discussion converges, it can be turned into a task: write out the goal, background, constraints, and acceptance criteria in the task description, then choose an owner, project, priority, and deadline. If an assistant is already connected to the Octo CLI and has the appropriate workspace permissions, it can also organize the conversation context, create the task, and assign it to an expert or expert team.

Once created, a task can be driven forward independently inside Loop. The task detail view stores state, execution logs, comments, results, and attachments. After completion receipts or group message pushes are configured up front, key transitions such as pending confirmation, needs assistance, and failure can be pushed back to IM, so people can make judgment calls in their original business context without having to stay parked on the Loop page.

There are three types of roles that participate in Loop collaboration:

01 Assistant: A long-running intelligent agent connected in IM

In the Octo context, "assistant" usually refers to an Agent that is connected to IM, can run over long periods, and preserves user context.

It can be built on top of intelligent agent frameworks such as OpenClaw or Hermes Agent. Compared with a Runtime that mainly executes single tasks, this kind of Agent puts more emphasis on long-term memory: it continuously understands the history of the user, the team, and the conversation, knows what is being discussed, and gradually builds an understanding of how the user works.
Assistants typically live inside IM and serve as the entry point through which users interact with the Agent system. An assistant can join the discussion, understand context, and — once the discussion converges — use the Octo CLI to create tasks in Loop, assign executors, query progress, read results, and add feedback.

It's more like a delegator and orchestrator that sits outside Loop: it understands the user in IM, issues instructions through the CLI in Loop, and then brings task results back into the original conversational context.

02 Expert: A task executor connected in the Loop runtime

An expert is the task-execution role an Agent takes on after being connected to Loop.

Once an Agent is connected to a runtime and configured as an expert in a workspace, it can receive specific tasks. It executes work based on task context, its own instructions, skills, and external tool connections, and leaves its state, logs, and results with the task. Execution engines such as Codex and Claude Code are typically connected to Loop this way.

The differences between an expert and an assistant come down to:
· Where it is connected
· What context it receives
· Whether it takes on specific tasks
· Whether long-term context or single-task work is the center of gravity

We believe experts are better suited to executing tasks focused on the context of the task at hand, while assistants are better suited to understanding users, organizing requirements, and coordinating work. But this isn't a hard rule in the system — users can also connect the same Agent body to a runtime and have it take on specific tasks.

03 Expert Team: The task-organization mechanism inside Loop

An expert team is not a new kind of Agent, nor is it a broadcast mechanism that automatically runs multiple Agents at the same time. It's an organizational and routing object inside a Loop workspace.

When a task is assigned to an expert team, the current mechanism first routes it to the team leader. The leader can look at the roles and skills of the team members, and then, as needed, explicitly create subtasks, pull in other experts by name, and ultimately take responsibility for wrapping things up and delivering the result.

Overall: assistants address the problem of who understands the user in IM over the long term and orchestrates tasks from the outside; experts address the problem of who executes specific tasks inside Loop; expert teams address the problem of how to organize and coordinate multiple task executors.

Under this division of labor, long-running tasks finally have their own dedicated carrier. Loop peels tasks out of the conversation and gives them a stable owner, real-time state, complete logs, and deliverables. Where the blockers are, whose input is being waited on, what the next step is — all of it can be looked up, and driving a task forward no longer depends on someone manually scrolling through chat history.

Expert capabilities now also have a foundation for maintenance and reuse. A department can continuously maintain an expert's instructions, skills, and external system connections based on its domain knowledge, and once a method is updated, every project that calls this expert benefits at the same time. A clever usage someone tuned by themselves becomes a reusable capability for the whole team.

A Few Design Considerations

While building Loop, we had a few things on our minds:

01 Define the goal, not the path

The idea behind traditional drag-and-drop workflows is to draw every step out before you start. It assumes that a person can figure out, in advance, every path a task might take — but real-world work often deviates from the preset flow.

Loop puts more emphasis on defining the goal, the constraints, and the acceptance criteria first.

Within the boundaries of its instructions and permissions, the expert plans the execution path, calls tools, and submits results. When something genuinely requires a human judgment call, it enters "needs assistance" or "pending confirmation", and the person fills in the missing conditions before it continues.

But this does not mean the execution path is completely unconstrained. High-risk actions, external writes, production operations, and irreversible decisions still need explicit permission boundaries and human confirmation. Loop provides a more flexible execution space, not the absence of constraints.

02 People are tasters, not overseers

"If a person isn't watching every step, how do we know the task isn't quietly going off the rails?" That's the question we get asked the most.

Our answer is not "AI is reliable enough, so you can relax." Quite the opposite — Loop assumes that an Agent will get stuck, make mistakes, and hit situations it can't handle. What the system needs to do is surface these situations as early as possible, rather than let them get quietly buried in chat history. Every task has a clear owner, a task state, and a deliverable, and Webhooks can proactively push state changes into IM.

Behind this is our view of where people belong in collaboration: people are tasters, not overseers. Chasing an Agent for progress updates shouldn't be a person's job — Loop wants to direct human attention to the places where judgment is actually needed.

03 Tasks are a baton, not a to-do list

Another common misunderstanding is treating Loop as a project management tool with AI bolted on. On the surface, both have tasks, states, and owners — but their essence is completely different.

Traditional project management software records "who should do what." It's a to-do list: once a task is created, a person goes and executes it, and the software itself doesn't produce a result. What Loop manages is a collaborative system made up of people and Agents. Once a task is dispatched, the expert takes it on as the executor, calls tools, produces results, comes back with questions when it hits problems, and — after the person makes a call — keeps running, ultimately handing the result over to a person for acceptance.

Loop is now officially available in Octo. Enterprise users can start using it by taking the following steps:

Under "Me", add a computer → register a runtime → connect the execution engine you're already using → configure the expert's instructions and skills — and you're ready to go.

More product features will be rolled out gradually in future releases.

Octo：https://github.com/Mininglamp-OSS

Beyond Single-Agent Loops: How We Built Multi-Agent Orchestration in Octo

Mininglamp — Mon, 03 Aug 2026 06:23:46 +0000

A few weeks ago Boris Cherny, who leads development on Claude Code, mentioned during a talk at Acquired Unplugged that he doesn't really write prompts for Claude anymore. Instead he writes loops that keep prompting Claude until the work is actually done. The clip went viral on X, racked up nearly 700k views in under 24 hours, and Loop Engineering became the latest term making the rounds in AI development circles.

The core idea is straightforward enough. Rather than obsessively tuning a single prompt to get a perfect output on the first try, you build an iterative system around the model: give it a clear goal, feed it the right context, give it tools to work with, evaluate what it produces, and define conditions for when it can stop. Wire those pieces together and the agent stops being a one-shot call and becomes something that iterates, self-corrects, and keeps working until the output actually meets your bar. The efficiency gains over prompt-tuning are real, and that is why the concept resonated so quickly.

What struck us as we built and shipped the loop system for our own platform Octo is that almost all of the current conversation around Loop Engineering stays at the single-agent level. You have one model, one cleverly designed loop, one sandbox, and the agent grinds away iteratively until its output passes whatever checks you have set up. That solves a real problem: how one person works faster with AI. But real work, especially inside an organization, rarely fits cleanly inside a single agent loop. A product feature going from idea to shipped code needs someone defining requirements, someone designing the approach, someone writing the implementation, someone verifying quality, someone feeding back results. Those are not different iterations of the same loop. They are interconnected loops that need to pass context and outputs between each other. When loops need to share state, trigger each other, and respect organizational boundaries, single-agent loop design stops being sufficient. You need orchestration at the network level.

This post is about what we learned extending loop engineering beyond single-agent iteration into multi-agent collaboration and organizational-scale coordination.

IM is great for conversation. It is terrible for tracking long-running work.

Octo started as an AI-native instant messaging platform. You @ an agent in a thread, it picks up the task, and posts results back into the conversation. That model works cleanly for short Q&A and quick tasks. It falls apart quickly when you start using agents for real, production-grade work.

Context window limits hit first. Every thread in a chat interface is an isolated session with a fixed context budget. Once a task involves multiple rounds of tool calls, code edits, error logs, and feedback cycles, the context fills up within a dozen or so exchanges and the model's adherence to early instructions degrades noticeably in later rounds. We tried isolating topics into threads to help agents focus their attention, which helped at the margins, but it does not solve the fundamental problem that long-running tasks should not live inside a chat stream at all.

When a task takes thirty minutes or several hours to complete, waiting for a reply in a chat window produces real anxiety. If the agent has not responded in five minutes, you cannot tell whether it is still working, lost the connection, misunderstood the direction, or hit an infinite loop on some edge case. Sending another message in the same thread to check on progress risks interrupting whatever it is doing. That uncertainty makes it genuinely hard to let agents run on long tasks unattended, and the work that actually matters, processing a 90-minute podcast transcript into a structured research brief or implementing a feature across frontend and backend, takes sustained execution time.

Running multiple agents in parallel creates a different problem. People on our team routinely have several coding agents running in separate terminals alongside agents working inside Octo itself, and with multiple log streams scrolling simultaneously your ability to track which task needs attention, which one is blocked, and which one is actually done waiting for review drops off sharply. The now-familiar screenshot of Peter Steinberger's desktop covered in terminal windows is not an anomaly; it is evidence that the terminal itself is not a good enough task management surface when you are running multiple agents concurrently.

We also kept hearing a consistent request from teams across the company: people wanted shared, department-level agents. A domain expert configures an agent with the right system prompt and skill set for a particular workflow, and everyone on the team can invoke it without each person having to build and maintain their own version. There are compute allocation implications too; nobody wants their personal agent quota consumed by cross-team work.

The solution we landed on was to build a dedicated task execution layer on top of the messaging interface. We call this layer the Loop. Messaging stays where conversations happen and intent gets clarified; Loops are where tasks get dispatched, executed, tracked, and reviewed. An async notification layer connects the two, rather than trying to mash execution into the chat stream itself.

Assistants and Specialists are fundamentally different roles.

One of the design decisions that took us the longest to settle was how to classify the different kinds of agents running on the platform. We converged on a hard distinction between two roles: Assistants and Specialists.

An Assistant belongs to an individual. It carries long-term memory about how you work, what you prefer, how you make judgments, and what context matters across your projects. It lives in the messaging interface, and its job is managerial: it understands your intent, creates tasks with the right context, monitors progress, and surfaces results to you at the right decision points. You train your Assistant; your Assistant manages the agents doing the actual work.

A Specialist is a worker. It has no long-term memory. Each task starts with a clean context. It runs on a designated runtime with an explicit system prompt, a bounded set of skills, and a working directory. That clean context is not a limitation; it is the point. One of the most common failure modes we observed was teams putting a coding agent in a shared group chat and finding that after weeks of multi-person use the agent outputs got noticeably worse. The memory files had accumulated conflicting preferences and fragmented context from different people, the system prompt lost its force, and the agent became muddled. Specialists avoid this entirely because their behavior is fully determined by prompt, skill configuration, and runtime, making it predictable and reproducible. Multiple Specialists can be composed into a Squad for cross-domain work where different capabilities need to coordinate under a lead agent.

In terms of ownership, Assistants are private to their user; Specialists and Squads can be scoped with visibility ranges, private to an individual, shared across a workspace, or restricted to specific groups, which directly supports the shared department-level agent use case.

How a task flows through the Loop

The execution flow works like this. You talk to your Assistant in the messaging interface and clarify what you need. The Assistant generates a structured task brief from the conversation context, covering background, objectives, and acceptance criteria. It creates a task in the Loop and assigns it to the appropriate Specialist or Squad. The Specialist picks up the task and starts executing, with multi-agent collaboration happening inside the Loop as needed. Results come back to the messaging interface via webhook; the Assistant does an initial pass to extract the key points, then pushes the summary to you. You review at key decision points and choose to accept, send back with feedback, or add requirements. Every acceptance and rejection is logged as material for preference learning.

A few engineering choices in this flow are worth calling out explicitly.

The task brief is generated by the Assistant, not hand-written by a person. People describe requirements conversationally and omit acceptance criteria and edge cases; the Assistant, having been party to the whole conversation, produces a more complete and structured brief. In practice brief quality is the single strongest predictor of execution success rate. Vague briefs cause Specialists to burn time and tokens heading in wrong directions.

Specialists follow a narrow-expertise principle. Cap the number of skills attached to a single Specialist at fewer than ten; give it a tightly scoped system prompt that clearly defines its role. Trying to make one Specialist good at product thinking, code implementation, and design review produces mediocre output across the board because conflicting role definitions pull the model in different directions during execution. Cross-domain work gets handled by composing Squads, not by overloading a single agent.

Workflows are defined in prompts, not drag-and-drop node editors. A lot of AI workflow products over the past year use visual node graphs, but fixed graphs are brittle; if a node produces unexpected output the whole flow breaks with no ability to self-correct. We define workflows inside Specialist system prompts: specify phases, phase objectives, transition conditions, and rules for when to loop back or request human intervention. This gives the workflow elasticity so a Specialist can adapt to actual execution state while still maintaining disciplined stage gates for standard procedures.

Our own engineering team has been using this flow for feature development for a while now. The Assistant writes a brief from the requirement conversation, assigns the implementing Specialist; the Specialist clarifies requirements and produces an architecture proposal, which triggers review either by another Specialist or a person; once the approach is approved, the Specialist creates a branch, writes code, runs tests, commits, and opens a PR; if CI review flags issues the Specialist automatically pulls the review comments, fixes, and resubmits until it passes. The human only intervenes at the proposal review and final acceptance points. For a mid-sized feature touching frontend and backend, the human investment is roughly ten minutes of direction-checking.

Async notifications bridge the gap between execution and conversation

Long tasks run in the Loop without blocking the messaging interface. Webhooks listen for state transitions, queued to in-progress, in-progress to awaiting-review, awaiting-review to done or sent-back, and push notifications into the associated thread, @-mentioning the relevant person or Assistant. You configure webhooks at the project level so all tasks under a project report status back consistently.

Each chat thread has a GROUP.md configuration file that tells the Assistant how to handle notifications for different states: progress updates during execution get suppressed, review-ready and completed states trigger a pushed summary, blocked states generate an alert with the blocking reason. After configuration the Assistant acts as a noise filter between you and the Loop, surfacing information at decision points rather than streaming raw logs at you.

In practice this works well for scheduled or long-running work. We have a recurring content analysis task configured to trigger at a set time; the Squad runs for several hours pulling source material, processing transcripts, and generating a structured report; the next morning the Assistant has already posted the key findings and a link to the full deliverable in the thread. If something fails mid-execution the Assistant picks up the blocked notification and flags it.

Runtimes and Skills give Specialists real execution capability

Specialists need to run on actual compute. The runtime management layer supports connecting personal machines via a terminal command, internal cloud VMs, or third-party servers, with Specialists bound to specific runtimes. macOS and Linux are currently supported; Windows is still being tested.

Skills are portable capability packages, structured prompt files and companion scripts that define how to call tools in a given domain. A CLI skill package for a document system, for example, includes invocation instructions and scripts for document creation, spreadsheet manipulation, calendar access, and meeting notes. You import skills from external URLs or pull them in one click from local runtime environments. Beyond native skills, the platform supports MCP and CLI integration for external systems, so anything exposing a CLI interface or MCP server can in principle be invoked by a Specialist.

The relationship between hardware, runtime, and Specialist is three-layered: hardware at the bottom provides compute resources including CPU, GPU, memory, network, and system access; a runtime in the middle hosts the agent execution environment on a machine running Codex, Claude Code, or similar; a Specialist at the top is a runtime plus system prompt plus working directory plus skill set, forming a unit capable of accepting and executing tasks.

Preference accumulation is what makes loops compound

Loop Engineering gets agents iterating on tasks, but if every execution starts from scratch and repeats the same mistakes, the efficiency ceiling is low. A core design belief behind Octo is that the feedback people give when accepting or rejecting agent output carries a lot of implicit judgment and preference information that was previously getting lost in chat history.

The Preference system automatically extracts judgment standards and working preferences from task execution and review behavior, then feeds them back to the Assistant so future task briefs automatically incorporate the validated standards. If code reviews consistently flag a particular class of security check as non-negotiable, that preference gets captured and the Assistant writes it into future briefs without you having to restate it. At organizational scale, every team member's professional judgment can, through this mechanism, accumulate into shared team knowledge.

This maps directly to two of the four letters in OCTO: Orchestration handles how multiple agents coordinate to complete work; Taste ensures outputs increasingly match team standards over time. Open keeps the platform vendor-neutral, working with OpenClaw, Codex, Claude Code, and other coding agents as runtimes; Context ensures project knowledge, historical decisions, and team conventions flow between all participants so a new team member or agent does not start cold.

Three layers of Loop Engineering

If you draw a rough layering of where Loop Engineering is today, there are three distinguishable levels. Layer one is the single-agent iterative loop, what most of the current community conversation describes, where one agent iterates inside a sandbox until its output passes. Layer two is multi-agent collaborative loops, where one agent's output feeds another agent's context and feedback triggers revision or downstream work, requiring orchestration and context management. Layer three is the organizational loop where humans and agent networks operate together, with people making directional calls at critical decision points and the whole network continuously adjusting through goal-setting, execution, evaluation, and preference accumulation.

Most current practice sits at layer one. Some teams are starting to explore layer two. What we have built Octo to support is layer three infrastructure. Across Mininglamp's internal deployment today more than 1,400 employees work alongside over 2,900 agents on the platform daily; at that scale with thousands of concurrent agents exchanging context and triggering each other's work, single-agent loop design simply does not address the core problems, which are orchestration, context flow, preference accumulation, and permission management at network scale.

As a concept Loop Engineering correctly identifies the directional shift in AI development from hand-tuning prompts to designing systems. But getting from single-agent iteration to organizational multi-agent coordination requires solving a different set of engineering problems: cross-agent context efficiency, preference signal quality and recall accuracy, resource scheduling at scale, and the permission and safety boundaries that make deployment inside a real organization viable.

Octo is our working answer to those problems. The full codebase is open source on GitHub under the Mininglamp-OSS organization, where you can find the web client, backend server, CLI tool, and deployment configurations.

Octo supports private deployment and works with major coding agents including Codex, Claude Code, and OpenClaw. The project lives at github.com/Mininglamp-OSS. If you are working through these same problems of multi-agent collaboration at scale, give it a look.

Multi-Agent Collaboration Hits the Engineering Wall

Mininglamp — Mon, 03 Aug 2026 06:23:08 +0000

Single agent capabilities have expanded pretty dramatically over the last year. Tool calling went from flaky function selection to reliable multi-step planning. Code generation moved from snippet completion to full module implementations. Desktop GUI control crossed from demo territory into OSWorld benchmark numbers that actually mean something, Mano CUA 1.1 hitting 58.2 percent on the specialized model track, about 13 points ahead of opencua 72b in second place, and WebRetriever NavEval at 41.7, edging past Gemini 2.5 Pro Computer Use at 40.9 and Claude 4.5 Computer Use at 31.3. Those numbers would have been hard to believe a year ago.

But the ceiling on single agent systems is getting easier to see. Once a task needs more than one role operating in the same loop, problems stack up fast. A competitor analysis that needs parallel research across three sources before cross-referencing. Code that goes through independent security review after being written. Creative work where you want two independent drafts before picking one. People have tried shoving multiple role descriptions into a single system prompt and having the model switch hats, but in practice the attention bleed between roles is hard to contain. The agent doing the writing naturally overestimates its own output quality. The reviewer sharing the same context chain goes soft on issues it watched get created. We saw this repeatedly in early Mano AFK testing where coding and testing lived in the same agent context. Tests became ceremonial, obvious logic errors slipped through, and things only got better once we split the agents apart.

Splitting work across multiple agents is not a new idea. It has been in papers for years.

What changed is the cost structure. A year ago running three GPT 4 level instances on a multi-step task meant token bills that added up fast, especially on iterative dev work where the meter kept running across rounds of fixes. That equation looks different now. Small and on device models have closed the gap on specific tasks faster than most people expected. Mano CUA 4B Thinking runs at about 7.9 seconds per step on an M5 Pro and hit 56 percent on 100 real macOS GUI tasks, 17 points above Qwen3 VL Plus running in the cloud at 39 percent. For GUI automation and similar vertical tasks a local 4B model can genuinely replace some cloud calls, and running several agent instances simultaneously on an M5 Pro or M4 Mac mini is no longer a stretch. The Cider SDK pushes that further with W8A8 and W4A8 activation quantization, W8A8 per channel on M5 Pro running prefill around 1.8x faster than the MLX W8A16 baseline. MCP adoption is also bringing down integration friction, standardizing tool interfaces so new agents do not need a custom adapter stack every time.

We ran into this pretty directly while building Mano AFK, the autonomous software dev pipeline. It takes natural language in, generates a PRD, writes code, deploys, runs multiple layers of testing, fixes issues based on results, and delivers a working app. Tests cover lint, API checks, E2E GUI runs, and a separate adversarial reviewer agent that can drive either Mano P locally or Claude CUA in the cloud. The first version had coding and testing in a single agent context. The result was consistent confirmation bias. Test coverage was thin, edge cases got overlooked, and the agent basically graded its own homework. Once we split things so the coder and tester held separate contexts, and the tester only saw code plus the PRD with no access to the coder thought process, review quality picked up immediately. The adversarial reviewer had to be fully isolated too. If it knew which parts the coder had compromised on or struggled with, the critiques got softer. On the CUA Benchmark of 100 test cases across 5 web apps, W8A16 hit 58 percent overall accuracy, W8A8 with Cider hit 54 percent with prefill around 1453 tok s. The quantization speedup matters more in multi agent settings because prefill queuing becomes noticeable when several instances run in parallel.

The hard part of multi agent systems is not spinning up multiple instances. It is controlling what each agent can see.

A lot of early frameworks gloss over this, dumping everything into a shared message stream or blackboard context and effectively recreating a chat room where every agent hears everything. Real teams do not work that way. Information asymmetry is not a bug in human collaboration, it is how work actually gets done. Brainstorming sessions work with full visibility because the whole point is cross pollination. Code review works the opposite way, a reviewer who hears the author walk through every design decision before looking at the diff will give weaker notes, which is why mature teams use pull requests instead of standing over each other at the desk. Pipeline stages only need output from the previous step, excess context from upstream discussions just adds noise. Research tasks split across people run better when each track stays isolated during execution so approaches do not converge prematurely and kill diversity. Each of these scenarios wants a different visibility topology, and forcing them all into a shared context model is like using one data structure for everything. It works but it leaves a lot on the table.

Octo breaks this down into six orchestration modes, selectable at the Loop level. Solo is single agent execution for straightforward tasks. Roundtable gives all participants full visibility for discussion and ideation. Critic fully isolates the executor and reviewer, the reviewing agent only sees the final deliverable with no access to intermediate reasoning. Pipeline chains stages so each agent only sees output from the step before it. Split divides a task into mutually exclusive chunks and runs them in isolated parallel, merging results in the main loop when everything finishes. Swarm launches multiple independent agents on the same task and selects the strongest result. Once a mode is picked the system handles context boundaries, message routing, and result merging, so teams do not have to build message queues and context trimming from scratch each time. That orchestration layer is the difference between a multi bot chat and actual collaborative structure.

Group chat is the wrong primitive for agent collaboration.

The chat model assumes every participant sees every message. That works for humans because we filter aggressively, tuning out the noise in a busy channel. Agents do not have that luxury. Either you burn prompt tokens instructing them to ignore certain messages which is brittle and unreliable, or you stuff the entire history into context windows and pay for the waste. More fundamentally some collaboration patterns simply cannot be expressed in a flat chat model. True independent drafts require message isolation that a shared channel cannot provide. Critic mode review independence collapses when all intermediate outputs are visible. These are not prompt engineering problems, they are information model constraints.

Orchestration is only one layer. For multi agent systems to hold together a few other pieces need to exist. Agents need identity metadata describing what they are good at. Octo uses AgentCard to mark capability boundaries so future A2A routing can assign subtasks to the right agent instead of round robin. Feedback from execution needs a place to accumulate, reasons a task got sent back, common issues caught in review, taste preferences expressed during acceptance, all of that is wasted if it stays buried in conversation logs. The Preference system attaches that feedback to agents and projects so it gets loaded for similar tasks down the line. That compounds over time. An agent with three months of real project feedback behind it behaves very differently from a freshly deployed one. Runtime management is at V1 right now covering local process registration, health checks, and basic resource allocation, with multi machine scheduling coming later. Skill packs support reusable prompt bundles and MCP marketplace imports. A2A routing where a lead agent decomposes work and delegates based on known strengths is on the roadmap.

Last week the octo marketplace added Docker Compose one click deployment and full text search landed in octo cli. octo cli is the fastest growing repo in the Octo ecosystem at 332 stars. The whole project lives under the Mininglamp OSS org on GitHub under Apache 2.0. The runtime layer is model agnostic, you can plug in OpenClaw, Codex, Claude Code, Hermes or other backends. Private deployment is supported so task data and accumulated preferences stay in your environment. Octo ships across web desktop, mobile, a browser extension, and CLI, with native IM integration so users can spin up a loop by mentioning an agent directly in a group chat without switching to a separate task system.

Multi agent orchestration is still early. Nobody has nailed the right granularity for information isolation, or the frequency at which preference feedback turns from useful signal into noise, or how A2A routing decisions should weigh past performance against other signals. We shipped the six modes first because they cover the patterns that came up repeatedly in real use rather than deriving categories from theory. Those six are not the complete set, more will surface as usage deepens. Single agent tool calling and execution took roughly two years to go from demo grade to genuinely useful. Multi agent orchestration will probably need the same kind of iteration.

https://github.com/Mininglamp-OSS

Mininglamp Opens Registration for WebRetriever Global Challenge — $15,000 Prize Pool

Mininglamp — Tue, 28 Jul 2026 07:40:56 +0000

Registration for the WebRetriever Global Challenge is now open. Hosted by Mininglamp Technology, the competition is co-organized with Peking University, the Institute of Automation at the Chinese Academy of Sciences, the AI and Robotics Innovation Center at the CAS Hong Kong Institute for Advanced Study, and Synced (机器之心).

The total prize pool is $15,000 USD. Both individuals and teams are welcome, with no restrictions on nationality or institutional affiliation.

Why this benchmark exists

When an AI agent steps into a real browser, can it actually complete a task on its own, the way a human would, across the messy and ever-changing open web?

This remains the central bottleneck holding Web Agents back from real-world deployment. Existing benchmarks mostly rely on a small number of simulated or self-hosted sites that fall far short of the complexity of the live internet. On the evaluation side, current methods focus heavily on whether individual actions were executed correctly, but lack a systematic way to measure whether the agent actually delivered the end result the task demanded.

WebRetriever is our attempt at building a more honest measuring stick. The paper has been accepted at ECCV 2026.

Scale: 800 real live websites, 1,550 cross-domain tasks spanning eight verticals including tech, finance, healthcare, education, and government, all running against the actual public internet.
Evaluation accuracy: Our NavEval framework achieves 91.2% agreement with human expert judgments, compared to roughly 81% from prior best methods, making automated large-scale evaluation reliable for the first time at this scale.
What the numbers say: Even the best single model achieves under 50% on basic navigation success, and end-to-end task completion hovers around 20%. Getting there is not the same as getting it done.
How to register

Competition platform (Octo): https://im.deepminer.com.cn/
Invite code: 0f351ca01bb4c4dd

Step 1 — Sign up for an Octo account (skip if you already have one). You can register via browser (email recommended for timely updates), or if you use Claude Code, ChatGPT Codex, Cursor, or similar AI coding tools, register directly from your terminal via https://mininglamp-ai.github.io/WebRetriever_Challenge/join/ — no browser required.

Step 2 — Join the competition space using the invite code above.

Step 3 — Submit your team information (team name, members, etc.) following the in-space instructions.

Resources

Paper: https://arxiv.org/abs/2607.06118
Dataset: https://huggingface.co/datasets/Mininglamp-2718/WebRetriever
Code & leaderboard: https://mininglamp-ai.github.io/WebRetriever
Challenge page: https://mininglamp-ai.github.io/WebRetriever_Challenge/

AI Coding Isn't Scary, But a Dozen AIs in One Group Chat Is

Mininglamp — Tue, 28 Jul 2026 02:59:58 +0000

Back in July 2026, Hugging Face got hit by an autonomous intrusion launched from an AI model. Tens of thousands of attack logs flooded their security dashboards. According to reports from OSChina, the team initially tried feeding those logs through commercial AI analysis tools and hit a wall almost immediately—permission issues, model access restrictions, data they couldn't move across boundaries. They ended up sorting through the attack chain with open-source tooling.

Most of the conversation after that fixated on who did it, but the more interesting question is what happens when AI agents can act on their own and you don't have a way to govern them.

This isn't some distant hypothetical. If you're a developer in 2026, you've probably got Claude Code in your terminal, Codex wired into your IDE, a local model running something, and maybe a handful of browser-based AI tools all in your daily workflow. One AI is manageable. You watch what it does, you Ctrl+Z when it messes up, you're in the loop.

Scale that to a team. Three engineers, each running two or three AI agents. One agent writes code, another reviews PRs, a third handles documentation, a fourth deploys. Suddenly you've got a dozen AIs doing work in parallel, and nobody has a clear answer for how information should flow between them, who can see what, or how you trace a bad decision back to its source.

We learned this the hard way building Octo. The first thing we tried was the obvious thing: dump all the AIs into a group chat. People chat in groups, so why not agents? Just @ them when you need something. We ran that for two weeks and it fell apart immediately.

Group chats are built for humans. Everyone sees every message, all context is shared, and that works because humans have judgment. A developer knows not to look at HR comp docs. A security reviewer knows not to share their findings with the person whose code they're auditing. Humans navigate information boundaries with common sense. AIs don't. Put a code-writing agent and a security-audit agent in the same room, and the code agent will "notice" the vulnerabilities the audit agent flags and quietly route around them in its next commit. Run a competitive design sprint where three agents draft proposals independently and you want to pick the best one—except they can all see each other's work because it's a group chat, so what you get back are three versions of the same idea.

And the practical problem is worse. After a week of AI-generated messages flying around in chat threads, you can't find anything. Who made that change? When was it reviewed? What was the reasoning? It's all buried in hundreds of chat messages, impossible to audit.

That's why we built Loops.

A Loop in Octo is a unit of work that grows naturally out of conversation, but it's structured. It has an owner, deliverables, acceptance criteria, and a full timeline. The difference between a Loop and a Jira ticket is that Loops assume the executor might be an AI from the start. You can create one manually with clear objectives and acceptance criteria, or just describe what you need in natural language and assign it directly to an agent. The agent picks it up and starts working. Every output, discussion, and revision gets attached to the Loop's timeline. When work is delivered, the person who opened the Loop reviews it. Accept it and it's done. Send it back with feedback and that feedback doesn't vanish—it gets distilled into what we call a Preference, basically a taste profile that the agent carries into future tasks.

The thing that makes this actually work is information control. We've got six collaboration modes in Octo, and they're really just different topologies for who can see what. Roundtable is the all-hands room—everyone, humans and agents alike, sees everything. Good for brainstorming. Critic is where the executor can't see the reviewer. Work gets done, handed off, and reviewed blind, so you don't get that "oh I totally agree with your suggestion" pandering. Pipeline is sequential—each step only sees the deliverable from the previous step. Split breaks a task into pieces assigned to different agents who work in complete isolation before results get merged. Swarm is competitive: multiple agents tackle the same problem independently, and you pick the best result.

A standard group chat can't do any of this because it has one topology: broadcast to everyone. But real collaboration never works that way. When you're writing code you don't need to see the hiring plan. When you're doing a security audit you shouldn't see the implementation notes ahead of time—it biases your review. Humans manage this with process and convention. With AI agents in the mix, those boundaries have to be enforced by the system. You can't rely on good behavior.

Identity and permissions took a lot of iteration. Every agent in Octo has an identity, an AgentCard (its capability profile), and an activity log. Agents inherit the permissions of whoever created them. An intern's agent can't access financial data no matter what it's asked to do. We're runtime-agnostic—agents can run on OpenClaw, Codex, Claude Code, Hermes, whatever. You can run them on your local machine or in the cloud. Octo handles identity, capability registration, and activity tracking. The runtime handles execution. Keep those layers separate and you get clean data sovereignty: teams can self-host and keep all their task history, preferences, and context on their own infrastructure.

Preferences are where Octo diverges most from other AI tools I've seen. Every time you accept or reject an agent's output, your feedback gets recorded and distilled into preference cards. When an agent first writes documentation for your team and hands you back passive-voiced corporate fluff, you send it back: "Stop opening paragraphs with 'It is worth noting that.' Just state the conclusion." Next time that agent writes something, that preference is loaded automatically. Different people's agents develop different tastes. Your code agent might be fast but skimp on comments. Your tech lead's agent writes thorough docs but moves slower. You pick the right agent for the job based on what you need. And these preferences persist across model swaps, machine changes, even team turnover—they're stored server-side, tied to the agent identity.

Back to the Hugging Face incident. The real bottleneck for their security team wasn't that their models weren't smart enough. It was that they didn't have a framework for humans and AIs to work together in a structured way. When you've got tens of thousands of logs to triage, you need to split analysis across specialized agents—pattern recognition, attack chain tracing, remediation drafting. But those agents can't all share a Slack channel. The tracer shouldn't see the remediation agent's work before the trace is complete, or the remediation will be biased toward confirming the trace. Every step needs an auditable record so you can later answer: which agent made this call, when, based on what data? And the final remediation decision has to come back to a human. You don't let an AI autonomously decide to block IP ranges or shut down services without a person signing off.

AI capabilities will keep improving. Kimi K3 dropped 3 trillion open-weight parameters last week. Jensen Huang's first-ever tweet was an open letter rallying support for open-weight models. The model side of this equation isn't going to be the bottleneck. The bottleneck is coordination: how do you get multiple AIs working on the same project without them stepping on each other, leaking information across boundaries, or producing work that nobody can trace back to a decision? Loops, collaboration modes, and preference learning are our answer to that.

Octo's Loop workspace, project management, automation pipelines, and search are live now. Agent management and runtime registration are shipping this month in the V1 release. The project is at https://github.com/Mininglamp-AI/Octo — issues and PRs welcome.

We Gave Our AI Agents Employee IDs. Here's Why

Mininglamp — Mon, 27 Jul 2026 09:25:58 +0000

After you deploy half a dozen AI agents across a team, something weird happens. Friday afternoon, release day. The PM says their AI summarized the change impact. The dev says their AI reviewed the code and found nothing. QA says their AI ran the test suite and everything passed. Then production breaks. You dig through the logs and all you see is "system call." No way to tell which agent made which call, when, on what context, acting on whose behalf. Three agents sharing one service account, one API key, zero accountability. The humans end up taking the fall, and you can't even figure out which human to talk to.

This isn't a thought experiment. It's what happens when you bolt AI assistants onto existing infrastructure without thinking about identity. Buy a batch of API credits, create a service account, share it across the team, done. That works fine when one person uses one assistant for their own work. It falls apart the moment multiple agents run in parallel across different roles.

Permissions break first. A competitive research agent needs access to all project channel discussions. A code review agent should only see PRs and repository messages. That distinction doesn't exist in the service account model, which has a single binary switch: can access or cannot access. Teams work around it by manually creating groups, forwarding messages, and setting permission boundaries by hand. Add more agents and this manual isolation starts to crack. Some teams we've talked to ended up with over a dozen separate groups just to control agent visibility, with humans acting as message routers between them. At that point the AI is making things slower.

The work history problem is more concrete. An engineer who's been on the team for three months, you know what they're good at, what they're sloppy at, which module they crushed last sprint. Next time you assign work, you use that information. An agent that's run a hundred tasks? Completion rate, rejection count, which task types it handles well, all of that is scattered across chat logs with no aggregation. Assigning a code review task to an agent is essentially a coin flip. Three agents running in parallel on a project, one doing research, one drafting proposals, one running tests, and the lead has no data on who delivered quality last time or who got sent back twice. They all have the same default avatar.

Octo handles this with what we call an AgentCard. Each agent gets one at creation, and it tracks creator, owner, mounted skills, runtime type, historical task count, rejection count, and task type strengths. These fields aren't set once and frozen. They update as the agent does work. An agent that gets sent back three times for missing edge cases carries that record on its card. Another that nails data analysis tasks five times in a row naturally surfaces as the top candidate for similar work. Assignment goes from guessing to reading the data. It's a simple idea, but very few collaboration platforms are doing it.

Permissions flow from ownership rather than a separate agent IAM layer. An agent's effective permissions are the intersection of its owner's permissions and its role in the current workspace. An intern's agent can't touch production configs because the intern can't either. Every operation traces back to a specific person, so audit requirements are met without extra design work. When an agent gets assigned to a specific Loop (our term for a structured task unit), it only sees information within that Loop, not other tasks in the workspace. The boundary is enforced at the task level.

We deliberately did not build a KPI scoring system. The feedback mechanism in Octo is intentionally lightweight: when you review a deliverable you either accept it or send it back, and sending back requires a reason. "Edge cases not covered" or "conclusions lack data support" gets attached to the Loop, and the agent reads that feedback on its next similar task. It mirrors how people actually learn on the job, not through formal training sessions but through doing work and getting corrections. The longer the system runs, the better agents understand team code conventions, output format preferences, and acceptance standards. You can't get this by writing a longer system prompt. Prompts are static. Feedback accumulates.

Building identity and work history for agents can sound like applying corporate HR bureaucracy to AI, and there's a natural skepticism about adding unnecessary structure. In practice the opposite is true. Identity isn't about control for its own sake. Without it, permission boundaries stay vague and security risk stays high. Without work history, every agent assignment is a gamble and historical performance data goes to waste. Without feedback accumulation, you're re-teaching the same preferences every single time. None of these problems show up when you're chatting with a single assistant. They show up the moment agents start working across roles, owning deliverables, and executing operations in production. At that point identity isn't a nice-to-have, it's infrastructure.

Octo is open source on GitHub under Apache 2.0 with support for private deployment. The platform is built around agent identity, Loop task units, preference accumulation from feedback, and six collaboration modes (Pipeline, Critic, Split, Roundtable, Solo, Swarm). Available on web, desktop, mobile, browser extension, and CLI.

Repo: https://github.com/Mininglamp-OSS/octo-server

Octo: When AI Coding Gets 10x Faster, How We Designed for the Collaboration Gap

Mininglamp — Mon, 27 Jul 2026 09:00:48 +0000

AI coding tools have crossed a real threshold in the past year. Cursor and Windsurf count millions of active users. VS Code and JetBrains ship with built-in completion. Tencent Cloud demoed CodeBuddy NPC last month, where an agent takes a task spec, writes the code, opens a PR, runs CI, and fixes failures autonomously until everything goes green. You type a function signature and the model fills in a dozen lines before you finish thinking. Drop a comment saying "add unit tests" and a test skeleton appears in seconds. Individual coding speed is up somewhere between 3x and 5x by most team accounts.

Pull the lens back from the editor to the team level and the picture changes. More code ships faster, but review queues grow longer, test environments get locked more often, and wait times between handoffs actually stretch out. A developer spends 20 minutes writing a feature, waits two hours for review, fixes comments, pushes again, and the staging environment is busy. QA posts failures in the group chat and the developer misses the message while on something else. Hours pass. Actual coding time might account for a tenth of the total delivery cycle. The rest is coordination, waiting, messaging, and context switching. The faster code gets written, the more congestion piles up behind it.

The single-agent loop that products like CodeBuddy NPC demonstrate works cleanly for isolated work: one agent plans, codes, tests, and fixes until it passes. But any non-trivial feature in a real team crosses multiple roles. PMs confirm requirements. Tech leads do architecture reviews. QA runs regression in staging. Ops checks resource configs before deploy. Between each handoff today, someone pings Slack saying "PR up for review," drags a ticket from In Dev to Ready for QA in Jira, or scrolls through doc history trying to remember what came up in the last review. The agent can write the code, but it has no idea who to ping for review, how to provision a test environment, or why the last version got sent back.

Feedback loss is the less visible but more damaging problem. QA runs regression, finds three failures, posts stack traces and repro steps in the project channel, and forty minutes later those messages are buried under new discussion. When the dev agent goes to fix the bug, it has no visibility into that earlier test run. It reruns tests from scratch and rediscovers what QA already found, wasting another CI cycle plus the diagnostic detail from the first run. Human developers scroll back through chat history, remember that a certain module got dinged last time for edge-case handling, and know which QA engineer is strict about error codes. Agents don't have that memory. Teams that dump full chat history into the context window quickly hit a noise problem: group chats overflow with requirement discussions, lunch plans, off-topic mentions, and actual delivery feedback all mixed together. The more noise you stuff into context, the more likely the agent acts on the wrong signal.

The cost compounds over time. The same class of bug recurs because last fix's lessons were never recorded. Code style oscillates between reviewers because nobody captured individual preferences. Test coverage gaps persist because knowledge about which modules are historically flaky lives only in senior engineers' heads. When people leave, that experience walks out the door. Swap models or reconfigure an agent and the behavior patterns you spent weeks tuning disappear. These frictions are tolerable when code moves slowly; once AI accelerates output, the information loss in collaboration gets amplified fast.

We built Octo to address the delivery loop directly rather than building yet another coding assistant. The core unit of work in Octo is called a Loop. Loops grow naturally out of conversation rather than requiring anyone to fill out a ticket with a dozen fields. A developer states the goal and acceptance criteria in a workspace, assigns an agent as the owner, and a Loop is created. When the agent pushes code, the PR link, commit SHA, and test results attach to the Loop directly instead of scattering across chat windows, Jira, and the CI dashboard. When QA rejects a build, the rejection binds to the Loop with failure reasons and repro steps, permanently tied to that unit of work rather than floating off in a chat stream. The next time the same agent picks up a similar task, it reads historical Loops and their feedback: why this module was rejected last time, what the reviewer flagged on exception handling, which scenarios QA wants covered. This isn't a rulebook someone has to maintain; it accumulates automatically from every accept or reject cycle, and gets sharper the more the team uses the platform.

Information flow between roles is handled through collaboration modes rather than ad-hoc manual coordination. When work moves sequentially from dev to test to deploy, Pipeline mode gives each stage's agent only the deliverables and acceptance criteria from the previous step, without exposing upstream deliberation. Code review uses Critic mode, where the reviewing agent sees only the final submitted code, not the discussion that produced it, so it forms an independent judgment. When you want multiple implementations to compare, Split mode has agents work in isolation and a human picks which one lands. Roundtable handles brainstorming where everyone builds on each other's ideas. Solo covers individual tasks. Swarm runs multiple agents on the same problem independently and surfaces the best result. Six modes cover the patterns teams actually use, replacing manual add-this-person-to-the-thread coordination with system-level rules for who sees what and when.

Every agent in Octo belongs to a specific team member. Whoever creates an agent works on their behalf, inheriting their permissions and work preferences. A developer's agent picks up its owner's code review standards through accumulated feedback on past Loops. A QA's agent gets better at targeting high-risk modules as bug history builds. Permission management falls out cleanly: an agent's effective permissions are the intersection of its owner's access and its role in the given workspace. An intern's agent can't reach production configs because the intern can't either.

Octo currently supports Loop boards in list and kanban views, project grouping, Autopilot for scheduled and event-triggered automation like daily error log summaries or automatic first-pass PR review, and cross-Loop search. Everything is traceable end to end. The platform ships as a full web and desktop app for workspace management, mobile for notifications and quick approvals, a browser plugin that sends page context to agents via Cmd+K on any website, and a CLI for agents to receive tasks and submit deliverables from the terminal. You can plug in OpenClaw, Codex, Claude Code, Hermes, or any other agent runtime; Octo doesn't lock you into a single model vendor.

Octo is Apache 2.0 licensed and supports private deployment so all data stays on your own infrastructure. The repo is at https://github.com/Mininglamp-OSS/octo-server

Mininglamp Opens Registration for WebRetriever Global Challenge — $15,000 Prize Pool

Mininglamp — Mon, 27 Jul 2026 02:52:27 +0000

The total prize pool is $15,000 USD. Both individuals and teams are welcome, with no restrictions on nationality or institutional affiliation.

Why this benchmark exists

When an AI agent steps into a real browser, can it actually complete a task on its own, the way a human would, across the messy and ever-changing open web?

WebRetriever is our attempt at building a more honest measuring stick. The paper has been accepted at ECCV 2026.

Competition platform (Octo): https://im.deepminer.com.cn/
Invite code: 0f351ca01bb4c4dd

Step 2 — Join the competition space using the invite code above.

Step 3 — Submit your team information (team name, members, etc.) following the in-space instructions.

Resources

Why Multi-Agent Architectures Beat Single-Agent Setups in Enterprise Deployments

Mininglamp — Mon, 13 Jul 2026 07:29:26 +0000

When companies start deploying AI agents, the playbook is usually the same. Buy whatever model tops the benchmark leaderboard, roll out one company-wide assistant, and point everyone at the same chat window. During the demo phase it looks great — writes emails, pulls data, summarizes docs, no problem. Run it on actual business for a couple of months and the cracks start showing. Contract review accuracy swings all over the place. Customer support hands out wrong policy answers. The coding agent can't write documentation and the documentation agent doesn't understand code. You spend hours tuning a prompt, someone else uses it, and it falls apart. Then the team starts wondering if they just need to wait for the next model upgrade and everything will fix itself.

You could be waiting a while. The trouble with running everything through a single agent in an enterprise setting has very little to do with parameter count. It's an architecture problem.

No matter how smart a single agent is, its context window is finite. Shove the entire company knowledge base, every business process, every department's compliance rules into one prompt and the token count explodes. Actually relevant information gets buried under hundreds of thousands of tokens of noise, and the clause that matters gets missed. Asking one agent to master contract review, code generation, financial analysis, and customer support is like hiring a generalist to cover every role. Fine for firefighting, useless when you need real professional quality. Teams that have gone down this road know the feeling — simple Q&A works fine, anything slightly specialized and output quality becomes a coin flip, with a human checking every single result as a safety net.

The multi-agent approach breaks specialization apart. Contract review goes to an agent trained on legal work. Code generation goes to an agent wired into the codebase context. Customer support goes to an agent that's learned the latest product policies. Each agent only needs to be good at its own narrow domain. Context stays clean, expertise goes deep, accuracy stabilizes. Sounds obvious, and a lot of teams try exactly this — then hit the next wall. Once you've split the work across specialized agents, how do they actually cooperate?

Chaining agents in a simple linear pipeline, where one agent's output feeds into the next, works okay for rigid workflows like "ingest email → classify → generate draft reply." Real business workflows inside companies are messier than that. A market analysis report might need three agents pulling competitor data, compiling user feedback, and analyzing industry trends in parallel, then merging results, then sending everything to a review agent that picks holes in it, then sending it back for revisions, then submitting again. That's parallel work, independent review, and iterative rework all in one task. Forcing it into a straight line kills efficiency and breaks at every step where something doesn't go as planned.

Information flow turns out to be a surprisingly thorny problem. If every agent sees all context all the time, the coding agent can access financial data and the legal agent can read product source code — your IT security team will shut the whole thing down before lunch. If each agent only sees its own slice, you end up with blind men and an elephant situations. The agent writing a report doesn't know about budget constraints from the finance side and recommends something completely unimplementable. Working on Octo, the approach was to model information visibility through six orchestration patterns for different scenarios — open roundtable discussion, independent critic review, sequential pipeline, split-and-merge parallel work, competitive swarm selection, and simple solo execution. Each pattern defines different rules for how information flows, who can see whose output, when they see it, and how much they see, based on what the task actually requires. It's not all agents seeing everything all the time.

This trips people up more than you'd expect. A lot of folks assume multi-agent just means splitting work across multiple AIs and letting them go at it, like adding headcount to a project. In practice, information topology is the thing that determines whether a multi-agent system can actually run business reliably. During code review, the reviewer and the author can't see each other's process, or the reviewer gets anchored to the author's approach and stops catching real issues — same reason you don't stand over someone's shoulder while they write code and then expect to give a genuinely fresh review. Brainstorming is the opposite; everyone needs to see everyone else's ideas for the chemistry to work. Different work demands completely different information flows. Single-agent systems don't have this problem. Multi-agent systems that don't solve it have collaboration theater, not actual collaboration.

Task tracking is another thing that doesn't get enough attention. With a single agent, chat history is the work record. Ask today, scroll back tomorrow, and as long as the context window is large enough you'll find it. When multiple agents are working in parallel, who picked up which task, how far along they are, where the deliverables live, and who signs off on them — none of that survives if you're hunting through chat logs. Octo handles this with loops, work units that grow naturally out of conversation, each carrying an owner, deliverables, and review records. The owner can be a person or an agent. Deliverables, whether documents or code, attach to the loop so anyone looking a year later can see who did what and why. The review step isn't optional. When an agent delivers, a person or another agent has to accept it. Rejections don't just say "try again" — they get captured as experience that the agent automatically references the next time it picks up similar work.

On the subject of experience capture, single agents can technically do this too, but in an enterprise setting knowledge belongs to the organization, not to an individual chat session. The legal department's accumulated contract review standards, the support team's refined response guidelines, the engineering group's code style conventions — if all that lives buried in one agent's conversation history, swap out the model or move to a different department and you're teaching everything from scratch again. Hand stops, mouth stops, same problem as when an employee leaves and takes institutional knowledge with them. In a multi-agent architecture, experience gets shared across the organization. New agents inherit existing preference and skill cards directly instead of being trained from zero. The gap between a freshly deployed agent and one that's been running real work for three months is hard to miss.

Runtime heterogeneity is a practical reality in enterprise deployments. Some tasks touch local files and internal systems and agents have to run on local machines. Some tasks need the strongest long-context understanding available and have to call a cloud model. High-frequency simple tasks are better served by small fast models that respond quickly and cost pennies. Binding one agent to one model and one runtime means either everything runs locally and capability is limited, or everything goes to the cloud and sensitive data leaves the building and security signs off on nothing. A multi-agent architecture naturally supports agents running on different runtimes. Local agents handle local work, cloud agents handle heavy lifting, and the orchestration layer only cares who each agent is, what it can do, and what it did — not which machine it runs on or which model it uses.

This all sounds like building a fairly complex system. You don't have to do it all at once. When companies first experiment with AI agents, starting with a single agent for the simplest scenarios makes sense — hand it high-volume, low-risk work like meeting notes, internal document search, FAQ responses. Once the team has a feel for how AI collaboration actually works in their context, start splitting out specialized agents and layering in orchestration and task management. Rolling out a dozen agents on day one creates more management overhead than the manual work it replaces, and the team will bounce off the whole thing.

But there's a timing issue worth watching for. Single-agent setups work for demos. They don't hold up under real production workloads for long. Once business volume picks up, specialization, permissions, parallelism, and review problems surface one after another, and retrofitting multi-agent architecture at that point carries real migration cost. Prompts and workflows that were built for one agent have to be reworked. Thinking through which tasks genuinely benefit from multi-agent collaboration early, and laying the execution and orchestration foundation from the first production deployment, makes the path forward much smoother.

Octo has open-sourced the core modules for this — six orchestration patterns, loop-based work management, agent registration and routing. The repo is at , https://github.com/Mininglamp-OSS/octo-server , with code and docs available for teams building their own systems or just looking at how the architecture works.

For companies evaluating agent architectures, take one real business process and walk it end to end. From request to final delivery, count how many specialized roles are involved, whether there's parallel work happening, whether independent review is needed, and what the acceptance criteria are. If one agent and a chat window can honestly handle the whole thing, use one agent and don't over-engineer it. If the workflow involves clear role separation, parallel steps, and quality review gates, multi-agent architecture should be there from day one. Retrofitting it later costs more than building it in at the start.

Why Chat Alone Won't Cut It for Multi-Agent Orchestration

Mininglamp — Mon, 13 Jul 2026 07:05:55 +0000

Everybody's talking about multi-agent systems these days. Open any demo and you'll see a chat window with multiple bots going back and forth, and that's supposed to pass for collaboration. It's not. Chat is fine for communication, but confusing a chat interface with a collaboration layer is like thinking a group chat replaces your entire project management stack. People message each other all day long, but when work has steps, owners, deliverables, and acceptance criteria, nobody runs a whole project out of a group chat. Agents aren't any different.

Drop two LLMs into the same conversation thread and tell them to work something out together. What happens is basically the AI equivalent of @everyone in a company chat channel and saying "y'all figure it out." Every agent sees every message. Nobody knows who's doing what. Nobody tracks progress. Nobody signs off on the result. Everything gets flattened into one channel. For humans that's called noise. For agents it's worse, because every extra token of irrelevant context is money burned and signal diluted across dozens of turns.

When Octo first started, the early prototypes did exactly this — throw multiple agents into a shared room and let them chat. It fell apart fast on real tasks. Take writing a technical report. If the research agent and the writing agent share the same conversation, the writer starts making up facts before the researcher is done pulling data, and their outputs interfere with each other. Code review was even worse. When the reviewer can see every keystroke of the developer's thought process, they get anchored to the developer's approach and stop seeing problems. That's the same reason you don't sit right next to someone while they're writing code and then ask you to review it with fresh eyes. You can't.

Visibility control is something almost no multi-agent framework treats as a first-class design problem. Group chat assumes everyone sees everything — that model comes from social communication, not collaborative work. Real work needs precise control over who sees what, and when.

Octo models this with six orchestration patterns, each with a different information topology. Roundtable is the open discussion mode where everyone sees everyone, good for brainstorming and exploring angles before converging. Critic is the review pattern where the doer and the reviewer can't see each other's process, only the handed-off output, so the reviewer gives independent feedback without being anchored — code review, design critique, any scenario where you need a fresh pair of eyes. Pipeline chains agents sequentially where each one only sees the previous step's output, like a build pipeline, good for tasks with clear dependencies. Split breaks a larger task into pieces handed to different agents working in isolation, then merges results — like having three people write different sections of a report. Swarm hands the same prompt to multiple agents independently and picks the best output, which works surprisingly well for creative tasks like naming or writing multiple versions of copy. Solo is just one agent on a job that doesn't need coordination.

This probably sounds like overengineering if you haven't run into the wall yet. But think about how teams actually work. Brainstorms, assembly lines, independent reviews, parallel workstreams, shootouts between competing proposals — these patterns already exist in every organization. Collaboration tools just never modeled them explicitly for agents. Before AI, people knew which pattern to use instinctively, and a chat window plus documents was enough. When agents enter the workflow without explicit structure, they just ramble in the chat box and burn tokens.

Chat handles communication. After communication you need an execution layer to actually get work done. Where do tasks get created? How do they get routed to the right agent? Where do deliverables live? Who reviews them? What happens when work gets rejected, and how does that feedback stick so the agent doesn't make the same mistake next time? None of this exists in a bare chat interface. You could, in theory, have agents manage all of this themselves through conversation, but that's like asking every engineer to hand-roll their own project management system. It technically works, it's ugly, and every agent reinvents the wheel.

This is what Octo's loop system is built for. A loop is a unit of work that grows naturally out of conversation. Mention a task in a channel and the system can turn it into a tracked loop with an owner, deliverables, and acceptance criteria, instead of letting that request vanish into scroll history. The owner can be a person or an agent. Deliverables — code, documents, reports — attach to the loop so anyone looking a year later can see what was done and why. The review step carries particular weight. AI output doesn't get marked done just because it was delivered; a person or another agent has to accept it. Rejections don't just say "do better" — they get captured as experience the agent automatically references next time it picks up similar work.

On that experience point, almost no agent framework does this seriously. Tell an agent today "don't use exclamation marks in presentation titles" and tomorrow in a fresh conversation it has no idea. Every conversation starts from zero. You're basically onboarding a new intern who has no memory, every single time. Octo's preference system captures acceptance decisions, rejections, and "I prefer it this way" feedback as preference cards that agents retrieve on future tasks. The effect isn't dramatic on day one. After a few months of real use, agents that have been through review cycles on your team's actual work produce output that matches your taste and standards in a way prompt tuning alone never will.

Orchestration patterns control information flow. Loops make sure work actually gets done. Preference capture makes agents better over time. Those three layers stacked together start to look like a multi-agent system that can handle production work. A chat box by itself is like giving people messaging apps but no office, no project tracker, no docs, no review process. They can "communicate." They can't ship.

Something that doesn't get talked about much is agent identity and routing. Once you have more than a handful of agents, you can't manually assign every subtask to the right one. Agents need a card that says what they're good at, what runtime they live on, what they've worked on, and how well they've done. A lead agent needs to be able to read those cards and route subtasks automatically. AgentCard and A2A routing in Octo handle exactly this. It's early, but it's obvious that at any reasonable scale, manual assignment doesn't scale.

A quick note on runtimes. A lot of multi-agent frameworks assume every agent runs in the same cloud environment on the same model provider. That falls apart in practice. Some agents need to run locally because they operate on files on your machine. Some tasks genuinely need a strong long-context model. Simple tasks should run on small fast models. Some teams run fine-tuned models. Octo doesn't care where an agent runs — local CLI daemon, cloud runtime, whatever. Register it and it's available for orchestration. The platform tracks identity, capability, and audit trail. How it executes is the runtime's problem.

Fair question at this point: do you really need all of this if you've got one agent writing emails and replying to messages? You don't. That's what Solo mode is for, and it's the right answer for single-agent workflows. But if you're seriously thinking about teams of agents — one doing research, one writing code, one testing, one writing docs, with dependencies between them, quality bars to hit, and knowledge that needs to accumulate — a pure chat approach falls apart within a few iterations. Multi-agent work has a lot in common with distributed systems. You can start simple, but message routing, state management, failure handling, and load balancing are problems you will hit eventually.

Plenty of open source multi-agent frameworks exist. Most of them stop at "let agents chat with each other." The demos look impressive. Running real work through them is a different story. Octo is already in daily use internally — the loop workbench, project management, automation pipelines, and search are live. Agent management and runtime registration are shipping this month. Preference learning and A2A routing are under active iteration. The project is open source on GitHub at , https://github.com/Mininglamp-OSS/octo-server, and issues and PRs are welcome.

If you're building multi-agent products or evaluating frameworks, start by asking a basic question: are your agents chatting, or are they working? If it's just chat, a dialog box is enough. If it's work, you need task tracking, deliverable management, review workflows, preference capture, visibility control, and routing — none of which come from a chat window. You can absolutely start with a simple chat prototype to get something running. Just don't wait too long to build the execution and orchestration layers on top, or your demo will stay a demo.

Mininglamp Technology Officially Open-Sources Octo: A New-Generation Platform for Human-AI Agent Collaboration

Mininglamp — Mon, 13 Jul 2026 07:05:18 +0000

Today, Mininglamp Technology officially releases Octo — the first open-source, trustworthy Agent collaboration network that pioneers a new paradigm for human-AI teamwork. Octo supports private deployment, returning data and knowledge sovereignty to enterprises and users. By transforming isolated AI Agents into coordinated, orchestrable, and tasteable organizational digital workforce, Octo turns every human-machine collaboration into a node for compounding organizational assets, driving continuous evolution of Agents and systems under human judgment calibration.

As more intelligent agents emerge in personal devices and organizational workflows, new challenges arise: When everyone has their own AI assistant, when digital workforce proliferates within organizations, how should they connect, collaborate, and share critical context? How should they accept human judgment and calibration at key decision points?

Mininglamp believes the core challenge for AI Agents in the next phase is not endlessly scaling model parameters or building a single super-agent, but enabling different Agents to work together in the same network. What Octo aims to build is precisely "the internet between Agents."

Octo repository: https://github.com/Mininglamp-OSS

From Personal Assistant to Organizational Collaboration Network

In traditional AI tool usage, Agents typically exist as isolated silos. They maintain separate memories, execute independently, and lack unified collaboration interfaces and task flow mechanisms, making it difficult to accumulate capabilities, reuse experience, or truly scale AI adoption across organizations.

Octo breaks this deadlock. Through collaboration architectures like Channels and Threads, Octo builds a foundational network for humans and AI — as well as AI and AI — to work together. A Channel is essentially a project workgroup where humans and Bots can align intentions and dispatch tasks in real-time.

When a Channel contains multiple discussion topics, both humans and Agents can create multiple Threads within it to focus on specific subjects, ensuring concrete work threads don't get washed away by information noise, guiding discussions toward natural convergence.

In Octo, AI Agents join teams as Bots. Users can conveniently integrate mainstream tools like OpenClaw, Hermes, Codex, and Claude Code into Octo, creating dedicated digital twin Bots while enabling deep Agent-to-Agent (A2A) collaboration. Each Bot has its own AgentCard and work history, with clear ownership and accountability.

To transform fragmented discussions into traceable, measurable work outcomes, when actionable work emerges from discussions, Agents automatically summarize key points and create Matters upon human confirmation. Matters specify task owners and concrete deliverables, with detailed records from Brief through process discussions, outputs, feedback, to acceptance conclusions — all preserved for future review and decision traceability.

For complex tasks, Octo provides six collaboration modes: Solo (individual completion), Roundtable (group discussion), Critic (independent review), Pipeline (sequential workflow), Split (parallel division), and Swarm (competitive selection). By precisely controlling how Context information flows between Bots and what's visible to each participant, Octo enables multiple specialized Bots to conduct distributed collaboration under human guidance, allowing collective intelligence to emerge through network effects that surpass any single model.

"I Taste Therefore I Am": A New Division of Labor in Human-Machine Collaboration

What's truly being restructured in the AI era isn't just tools, but collaboration itself. In the future, collaboration will frequently occur between humans and humans, humans and Agents, and Agents and Agents. Under this new paradigm, the human-machine division of labor reaches a turning point: AI excels at "thinking" and "doing" — handling logical reasoning, analysis, generation, and execution; while human irreplaceability focuses on "tasting" — making holistic judgments based on experience, aesthetics, trade-offs, and values.

Octo is designed around this principle: Let Agents execute, let humans return to the core position of judgment and taste. At key nodes, humans provide direction, standards, and feedback — judging what's right and what's good; AI drives tasks to completion.

With every human-machine collaboration, human taste drives the accumulation of organizational assets, making Bots smarter over time.

During collaboration, project background knowledge, historical decisions, and discussion records are structurally preserved in Matters, allowing new members to onboard without starting from zero alignment. Every rejection, annotation, and style choice humans make when reviewing Bot outputs gets recorded as preference cards, enabling Bots to automatically reference them in future tasks. The standards and methods Bots learn can also be preserved as reusable Skill assets within the organization.

Through the asset accumulation flywheel of "dispatch tasks → review feedback → accumulate preferences and skills → greater efficiency next time," Octo builds a unique positive cycle, naturally enriching organizational productivity infrastructure with every collaborative interaction, achieving true capability accumulation and intelligent upgrades.

Open Source and Open: Not Replacing Tools, But Connecting Them

Octo is open-sourced under Apache License 2.0 and supports private deployment. Mininglamp believes that in an era of rapid AI development, enterprises' true long-term competitiveness stems from their unique work context, business knowledge accumulation, and organizational judgment.

Octo is precisely positioned as the "collaboration layer" between an enterprise's existing documentation, spreadsheets, code repositories, and project management platforms. Through cross-platform capabilities like browser extensions, Octo can seamlessly bring current webpage content, selected fragments, and task information into the collaboration network, helping digital twins fully understand the current work environment, standing by beside existing tools for efficient coordination.

In terms of product form, Octo comprehensively covers Web App, desktop client, mobile (iOS/Android), browser extension, and CLI — four endpoints meeting different work scenario needs. Whether pushing forward complex projects on desktop, quickly handling notifications and taste feedback on mobile, or providing native operations for Agents through CLI, seamless multi-device interoperability is achieved.

Moving Toward Private AI Through Trustworthy Mechanisms

Octo's open-source release is also Mininglamp's further practice in Private AI and Trustworthy AI.

Mininglamp firmly believes that truly sustainable AI collaboration must guarantee users' absolute control over data, context, judgment signals, and deployment methods. Through open-source architecture, private deployment, and clear data ownership design, Octo ensures enterprises can embrace AI within security boundaries while protecting individuals' tacit knowledge.

In Octo's product philosophy, the four letters "O.C.T.O." represent four inseparable dimensions: Open (open access), Context (context sharing), Taste (preference evolution), and Orchestration (multi-Bot coordination).

Context is the soil for AI to understand tasks; Taste is the compass for AI to continuously calibrate direction. Octo doesn't simply distill human tacit capabilities into platform assets, but rather amplifies, records, and传承 these capabilities while respecting personal and organizational data boundaries.

Mininglamp is continuously improving its new-generation AI infrastructure oriented toward edge intelligence, private deployment, and human-machine collaboration. By fully preserving teams' background knowledge, work preferences, and methodologies in the network, Octo ensures organizational wisdom doesn't drain with personnel turnover, and business style doesn't change with foundation model iterations. Every human-machine hybrid collaboration is compound interest accumulation on organizational private assets. Over time, this unique business perception naturally transforms into enterprises' most competitive technical and scenario barriers.

In the future, Octo will continue with an open-source, open attitude, co-creating new collaboration paradigms for AI-Native organizations with developers, enterprise customers, and ecosystem partners, making trustworthy, controllable, and sustainable private Agentic AI truly land in every real work scenario.

Why Your Team's AI Assistant Acts Like It's the First Day on the Job, Every Single Time

Mininglamp — Mon, 13 Jul 2026 03:48:29 +0000

Anyone who has used AI tools for a while has probably run into this annoyance. You ask it to write a weekly report in the morning and it doesn't know your KPI framework was overhauled last week. You ask for a technical proposal in the afternoon and it has no idea you spent three months locking down your tech stack. Every new conversation means re-explaining the project background, which decisions were made and why.

In multi-person collaboration the problem scales up fast. Five people each interacting with AI separately; the AI's understanding of each person is isolated. A discusses an architecture decision with the AI, B has no idea that conversation happened. Five people are repeating the same explanations and none of them know the others already did.

Context Fragmentation Has Nothing to Do with Model Capability

Current mainstream AI tools store memory as conversation history stuffed into a context window. When the window fills up, older messages get truncated. That works fine for a single conversation but falls apart in cross-day, cross-week team collaboration. Even with 128K token support, cramming all project history in there causes information density to collapse and the model loses the ability to focus on what matters.

Team collaboration needs memory across several layers. Project background, tech stack choices, the reasons behind past pivots; this long-term context doesn't appear in any single conversation but affects every task. One team member prefers concise communication while another wants detailed reasoning; the AI should remember these differences instead of outputting the same format for everyone. Last week's design decision and why it went that way, how that choice affects this week's sprint planning; if the AI can't see these connections, its suggestions will clash with earlier direction.

Some products use vector retrieval to extend memory, storing past conversations as embeddings and recalling relevant snippets by semantic similarity when needed. This eases the length constraint but semantic similarity and causality are two different things. "This design decision was made because of a performance incident last quarter"; that kind of causal logic doesn't survive embedding encoding. What you need is a context system that understands event sequence, decision background, and technical evolution, not simple keyword matching.

This is a problem that needs architectural-level thinking. Octo takes an interesting approach: extracting context from individual conversations and turning it into shared team assets. Project background, historical decisions, discussion records stop being someone's private memory and become a shared resource accessible to everyone collaborating, both humans and agents. New team members or newly configured agents don't start from scratch; the system's built-in context already contains the key information about how the project evolved. This turns context from a burden you re-enter every conversation into infrastructure the system provides out of the box.

Tacit Knowledge Is the Hard Part

Explicit knowledge is straightforward; write it into documentation and feed it to the system. But the information that actually affects output quality in team collaboration usually isn't in any document. The specific reason a technical approach was rejected, the writing style your boss prefers for certain documents, a particular client's communication taboos. This information only lives in people's heads and current AI tools have no mechanism to capture it.

When you tell the AI in a conversation that something is too verbose or the conclusion should come first, you're transmitting preferences. But that feedback vanishes when the conversation ends. Next time it still generates verbose output with conclusions at the end.

When multiple people collaborate with the same AI system simultaneously, preferences can contradict each other. The product manager wants output leaning toward business analysis, the engineer wants a technical implementation perspective. If the system can't distinguish between different people's preferences, it produces a compromised version that satisfies nobody.

Octo has a clever design for this: automatically distilling user feedback like acceptances, rejections, and annotations into persistent preferences that agents reference when taking on new tasks. Tacit knowledge capture shifts from manual documentation to automatic system learning. You don't need to write a document explaining your preferred style; the system learns from your feedback behavior. The longer you use it, the more preferences accumulate, and the deeper the agent's understanding of your work becomes. This kind of accumulation doesn't come from model capability but from real feedback during actual use.

Adding Memory to AI Is Harder Than It Looks

Adding memory isn't just plugging in a database. You need a persistent storage layer for long-term context and preference material. You need a retrieval and injection mechanism to manage context budget, deciding which memories to recall before each conversation and in what priority order. You need a feedback loop that automatically converts user acceptances and rejections into preference material. As memory volume grows, retrieval latency increases and noise information leaks into context, actually degrading output quality.

The difficulty lies in retrieval precision and automatic preference distillation, not in storage.

Cross-Task Dependencies Are Easy to Overlook

Last week's architecture review conclusions, this month's technical debt cleanup plan, next quarter's product roadmap; these seemingly unrelated pieces of information actually influence each other. If the AI can only see the current conversation and not these cross-task dependencies, its suggestions tend to be isolated and short-sighted.

Octo's Loop design attempts to address this: each task isn't a standalone ticket but an execution unit with upstream and downstream dependencies. The system tracks relationships between tasks so agents automatically reference relevant historical decisions and context when picking up new work.

This field is still early but the direction is clear. Memory isn't a bolt-on feature; it should grow inside the workflow itself. Every collaboration, every acceptance, every piece of feedback naturally becomes a system asset. Octo is building along this line of thinking, designing human-AI collaboration as a complete workspace where agents participate with identity and accumulated preferences, project context is shared across the team, preferences are automatically distilled through feedback, and tasks are linked through Loops into causal execution chains.

Octo is now fully open source on GitHub, with server, web/desktop client, iOS, Android, and CLI codebases, under Apache 2.0. If you're dealing with the same problems; AI tools that need fresh context every conversation, feedback that disappears, preferences that don't persist; pull the code and try it out. Deployment docs are in the octo-deployment repo with K8s manifests ready to go. The community is just getting started; if this direction seems valuable, drop a star and your early feedback will directly shape where the product goes.