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.
Top comments (1)
Long-running task systems need better state than chat can hold. The hard parts are wakeups, resumable context, idempotent retries, and showing the human what changed since the last checkpoint.