DEV Community: Mininglamp

We Automated the Entire Build-Test-Deploy Loop on Apple Silicon. Here's What We Learned.

Mininglamp — Wed, 23 Sep 2026 04:04:42 +0000

We've been building developer tools at Mininglamp for a while now, and one thing kept bugging us. The gap between writing a prompt and actually shipping something is still massive. You can get an LLM to spit out code all day long. Getting that code tested, deployed, and running without a human babysitting every step? Different story entirely.

So we built Mano-AFK, an autonomous execution framework that takes a natural language description and tries to go all the way to a working, deployed application. PRD generation, code, deployment, multi-level testing, automatic bug fixing. The full loop. We open-sourced it under Apache 2.0, and it lives under the Mano-P organization on GitHub.

This post is about what actually happened when we let it run on real tasks.

What the Pipeline Actually Does

Mano-AFK takes your prompt and runs through a chain of stages. Natural language in, and it generates a product requirements doc first. Then code. Then it deploys locally. Then it tests in three layers: lint checks, API tests, and full end-to-end browser-based testing. If something breaks, it loops back, reads the error, fixes the code, and tries again. There's also an adversarial review step at the end where a separate agent tries to poke holes in what was built.

You install it with brew:

brew install Mininglamp-AI/tap/mano-afk

The E2E testing part is where it gets interesting. Mano-AFK can use either our local Mano-P model or Claude CUA in the cloud for the browser testing. The local model is a 4B parameter VLA model that runs on Apple Silicon. We've benchmarked it across 100 test cases on 5 different web applications.

With W8A16 quantization: 58.0% accuracy on the CUA benchmark.
With W8A8 via our Cider SDK: 54.0% accuracy, but faster prefill at roughly 1,453 tokens per second.

That 4 percentage point drop for W8A8 might matter or might not, depends on whether speed or accuracy is more critical for your use case.

The Part That Worked Surprisingly Well

PRD generation was legitimately good. We gave it something like "build a project time tracker with team dashboards" and the PRD it produced was... actually usable? It broke things into features, defined API endpoints, thought about data models. Not perfect, but a solid starting point that would have taken a junior dev a couple hours to write.

The lint and API test stages ran smooth. When the generated code had syntax issues or basic logic bugs, the fix loop caught maybe 70% of them without any human input. Simple stuff like missing imports, wrong variable names, incorrect route definitions. It would read the traceback, understand what went wrong, and patch it.

The adversarial review step also caught things we didn't expect. On one run it flagged that the generated app had no input validation on a form field that accepted numbers. Tiny thing, but it ships to production all the time.

Where It Fell Apart

E2E testing with the local 4B model was hit or miss. 58% accuracy means it fails on nearly half the test cases. When it works, it genuinely navigates the browser, clicks buttons, fills forms, validates output. When it fails, it fails in weird ways. Clicking slightly off target. Getting confused by dropdown menus. Losing track of multi-step flows.

We noticed it struggled most with dynamic UIs. Anything with animations, loading spinners, or elements that shift position after render. The model is vision-based so it literally looks at the screen. If the screen changes between the screenshot and the action, things go sideways.

Complex multi-page flows also tripped it up. A simple "create account, log in, see dashboard" flow worked fine. But "create account, log in, create a project, add three tasks, assign one to a team member, export the report" was too many sequential steps. It would get 80% of the way there and then do something nonsensical on step 7.

One thing worth noting. The parent project Mano-P has a 72B model that scored 58.2% on OSWorld, ranking first among specialized models. But that 72B model is not open source. What you actually get to run locally is the 4B model. Make sure you internalize that distinction before setting expectations.

The Fix Loop: Clever but Not Magic

The automatic bug fixing deserves its own section because it's where most of the "autonomy" lives. When a test fails, AFK captures the error output and feeds it back in with context about what the code was supposed to do. It then generates a fix and reruns.

For straightforward bugs this is great. Missing dependency? It adds it. Wrong port configuration? Fixed. 404 on an API route because of a typo? Caught and patched.

But for architectural problems? Not so much. If the original code design was flawed, like choosing the wrong data structure or building a race condition into the async flow, the fix loop would just keep patching symptoms. We watched one run attempt 6 fix iterations on what was fundamentally a design issue before we killed it.

This maps to something obvious in retrospect. The fix loop is good at local fixes. Bad at structural rethinking.

The Adversarial Review

After all tests pass, a separate agent reviews the application from scratch. It gets the original prompt and the built application and tries to find problems.

In our testing it caught legitimate issues maybe 40% of the time that the test suite missed. Things like edge cases in form validation, missing error states, accessibility problems. The other 60% it either found nothing or raised false positives.

Still, having any automated adversarial step is more than most frameworks do. Most stop at "tests pass, ship it."

Cross-Project Learning

Mano-AFK maintains rules.md and preferences.md files that persist across projects. So if it learns that your team always uses Tailwind, or always structures API responses a certain way, it carries that forward. We found this actually made a noticeable difference after about 5 projects. The generated code started matching our conventions more closely without us explicitly specifying them each time.

Where the Boundary Actually Is

After running 30+ projects through this pipeline, simple CRUD apps and landing pages and internal tools worked most of the time without us touching anything. The sweet spot is stuff where the happy path is most of what matters.

Once you add complex state management, real-time features, or third-party auth flows, the success rate drops and you end up spending real time on fixes. Production systems with adversarial input or distributed architectures are a no-go for now.

Basically: describe what you want, walk away for 10 minutes, come back to something that works 60% of the time. For the other 40% you have a solid starting point with tests already written.

Trying It

Everything is Apache 2.0 on GitHub under the Mano-P org. Runs on Apple M4 with 32GB RAM.

If you're building anything in the autonomous coding space and want to compare notes, the repo issues are open.

From meeting speech to task dispatch: wiring on-device ASR into an AI collaboration workflow

Mininglamp — Mon, 21 Sep 2026 09:38:24 +0000

From meeting speech to task dispatch: wiring on-device ASR into an AI collaboration workflow

We recently shipped an integration between Octic, our on-device AI recorder, and Octo, the open-source collaboration platform we use for agent-orchestrated work. The goal was straightforward: someone says something actionable in a meeting, and a Loop gets created and assigned without anyone lifting a finger.

This post walks through the pipeline end to end: audio capture, speech recognition, intent extraction, task creation, and agent execution.

The Problem

Our team runs 6+ meetings a day. Decisions get made, action items get called out, and then... they die in someone's notebook. We tracked it for two weeks. Roughly 40% of verbally agreed tasks never made it into any tracking system. People just forgot to write them down, or wrote them down and forgot to transfer them.

We wanted to close that gap automatically.

Architecture Overview

The pipeline has five stages:

Mic → ASR (on-device) → NLU / intent extraction → Octo Loop creation → Agent execution

Each stage hands off a structured artifact to the next. No monolith, no single model doing everything.

Stage 1: On-Device ASR with Octic

Octic is a hardware recorder built by the same team behind the Lingting device, which was designed for noisy-environment speech capture. The key specs that matter for this pipeline:

ASR runs locally on the device. Audio never leaves the room.
Speaker diarization is built in, so you get per-speaker transcripts, not a single blob.
Real-time transcription with 7 built-in skills for in-meeting assistance.
Personalized ASR error correction, which actually matters when your codebase has project-specific jargon.

The output is a timestamped, speaker-attributed transcript in JSON. Each segment looks roughly like:

{
  "speaker": "fanrong",
  "start_ms": 124500,
  "end_ms": 131200,
  "text": "Let's have the agent handle the weekly report generation, assign it to Elva's agent by Friday"
}

Privacy note: because ASR is on-device, we can use this in client meetings without worrying about data exfiltration. That was a hard requirement for us.

Stage 2: NLU and Intent Extraction

Raw transcripts are noisy. People repeat themselves, correct themselves mid-sentence, go on tangents. You can't just regex for "assign X to Y."

We run a lightweight NLU pass over the full transcript. The model extracts:

Action items: things someone committed to doing or asked someone else to do
Decisions: conclusions the group reached
Open questions: things raised but not resolved

For action items specifically, we extract:

What needs to be done (the task description)
Who is responsible (mapped to Workspace members)
Deadline if mentioned
Any acceptance criteria mentioned verbally

This runs as a post-meeting batch job. We experimented with real-time extraction during the meeting but found that waiting until the end produces much better results, because context from later in the conversation often clarifies earlier ambiguous statements.

Stage 3: Mapping to Octo Loops

This is where Octo comes in. Octo is an IM-native collaboration platform designed for human-agent work. The core abstraction is a Loop: a work unit that goes from conversation to delivery, with an owner, deliverables, and acceptance criteria.

For each extracted action item, we create a Loop via the Octo API:

Title: the extracted task description, cleaned up
Owner: mapped to the responsible person's Agent (every team member has a digital Agent in Octo that inherits their authorizations and preferences)
Acceptance criteria: pulled from the transcript or inferred from context
Source context: link back to the meeting transcript segment, so anyone can trace why this Loop exists

The two-way link matters. When someone asks "why is my agent working on this?", the Loop shows the exact meeting moment where it was assigned.

Loops in Octo can be created two ways: manually through the UI, or via natural language. Our pipeline uses the API directly, but the natural language path is interesting for ad-hoc meeting follow-ups: you can literally type "create a loop for the quarterly review deck, assign to my agent" in the Workspace chat.

Stage 4: Agent Execution

Here's where it gets interesting. In Octo, a Loop owner can be an Agent, not just a person. Agents are digital workforce clones: they inherit your authorizations, carry your preferences, and can autonomously pick up and execute assigned work.

When a Loop is created with an Agent as the owner:

The Agent gets notified through the IM channel (Octo uses a three-tier escalation system to make sure notifications land)
The Agent reads the Loop brief, including the acceptance criteria and any attached context
The Agent executes the work. For a weekly report, that might mean pulling data, writing the doc, formatting it, and attaching the output to the Loop.
The human who spawned the agent reviews and accepts or rejects the deliverable.

Every acceptance or rejection gets stored as a Preference: a behavioral rule that the Agent references on future tasks. Over time, the Agent learns things like "this person prefers bullet points over paragraphs" or "always include the raw data table alongside the summary."

Stage 5: The Feedback Loop

Rejected deliverables go back to the agent with specific feedback. The agent revises and resubmits. This creates an iterative cycle that's fully tracked in the Loop's timeline: brief, discussion, output, feedback, revision, acceptance.

A year from now, someone can open any Loop and see the full chain: what was said in the meeting, what task was created, what the agent produced, what got sent back, and what was finally accepted.

What We Learned

Speaker diarization quality is critical. Without reliable speaker attribution, you can't map "I'll handle this" to a specific person. Octic's diarization works well in rooms with 3-6 people, which covers most of our meetings.

Post-meeting batching beats real-time. Real-time intent extraction sounds cool in a demo but produces too many false positives in practice. People say things like "we should probably..." without meaning it as a commitment.

Acceptance criteria extraction is the hardest part. People rarely state explicit acceptance criteria in meetings. We default to a summary of the task context and let the Loop owner refine it before the agent starts work.

Preference accumulation is surprisingly useful. After about two weeks of active use, agents started producing first drafts that needed fewer revisions. The Preference system in Octo compounds over time.

Orchestration Modes

Octo supports six orchestration modes for multi-agent collaboration: Solo, Roundtable, Critic, Pipeline, Split, and Swarm. For meeting-generated tasks, we mostly use Solo (single agent, simple task) and Pipeline (multi-step, ordered handoffs). The orchestration mode is selected based on task complexity at creation time.

Stack

Audio capture: Octic hardware recorder
ASR: On-device (Octic built-in)
NLU: Post-meeting batch extraction
Task management: Octo Loops
Agent runtime: OpenClaw, connected to Octo via the Agent framework
Feedback loop: Octo Preference system

Open Questions

We're still working on a few things:

How to handle ambiguous assignments ("someone should look into this") without creating garbage Loops
Cross-meeting context: when a task from Meeting A gets updated in Meeting B, should the Loop be updated or should a new one be created?
Latency optimization for the NLU stage, since people want their tasks created within minutes of the meeting ending, not hours

If you're building something similar or have experience wiring ASR into structured workflows, I'd be interested in hearing what worked for you.

The Octo repo is at github.com/Mininglamp-OSS. The Loop and Agent systems are the most relevant parts for this use case.

14 agents filtered 120,000 influencers down to 30 and improved CTR by 2.7% — multi-agent in production

Mininglamp — Mon, 21 Sep 2026 09:35:50 +0000

14 agents filtered 120,000 influencers down to 30 and improved CTR by 2.7% — multi-agent in production

Most multi-agent demos stop at chatbots arguing with each other in a terminal. This one ran a real marketing campaign. 14 AI agents handled the entire pipeline from influencer discovery to ad settlement, with zero manual execution steps in between.

I want to break down how this actually works, because the architecture is more interesting than the headline.

The problem: influencer marketing is a manual grind

A client needed a new product launch campaign. The traditional workflow looks like this: a human planner logs into multiple ad platforms, manually browses influencer profiles, builds spreadsheets, writes briefs, negotiates, tracks performance, adjusts spend. Each step involves a different tool, a different login, a different person.

The bottleneck isn't creativity. It's coordination overhead.

What the agent pipeline actually does

The system uses 14 specialized agents organized in a hierarchy. Not one mega-agent trying to do everything. Each agent owns a narrow task and passes structured output to the next.

Here's the rough breakdown:

Layer 1: Data Collection

A footfall insight agent connects to the Lingxi and Juguang backends via API. It pulls audience demographics, engagement patterns, content performance history across platforms. This isn't scraping. These are authorized platform integrations feeding structured data into the pipeline.

The data ingestion is continuous. The agent doesn't just pull a snapshot. It monitors trends over time so that by the time the selection phase kicks in, the system has temporal context on each influencer's trajectory. An influencer whose engagement is trending down over 90 days gets treated differently from one on an upswing, even if their current numbers look identical.

Layer 2: Influencer Selection

This is where it gets interesting. The system scanned approximately 120,000 influencer profiles and narrowed them down to 30. The selection criteria aren't just follower count. The agents evaluate content style alignment, audience overlap with the target demographic, historical conversion rates, and pricing efficiency.

120,000 to 30. That's a 99.975% reduction. A human team doing this manually might review a few hundred profiles in a day if they're fast. And even then, they're mostly eyeballing it. The agent applies consistent multi-dimensional scoring across every single profile.

Think about what this means in practice. A junior marketer assigned to influencer research will open a platform, scroll through profiles, check a few metrics, maybe drop promising ones into a spreadsheet. After three hours they've got 40 candidates and their eyes are glazing over. The agent evaluates all 120k with the same rigor it applied to the first one.

Layer 3: Strategy Generation

Once the 30 influencers are selected, the system produces 60-point strategy drafts. Not one generic brief. Each influencer gets a customized content deck based on their individual style and audience. If an influencer does comedic short-form video, they get a brief designed for that format. If another does long-form product reviews, different brief entirely.

This personalization goes deeper than format. The strategy agent analyzes what topics resonate with each influencer's specific audience segment, what posting times correlate with their best engagement, what call-to-action styles have historically converted for similar creators. The output is a genuine per-person playbook.

This alone resulted in a 30% efficiency improvement over the manual process.

Layer 4: Content Production

The content layer handles text-to-text generation, text-to-image creation, and video editing. All integrated into the same pipeline. The agents generate draft content that matches each influencer's voice and format preferences.

This is where the multi-modal capability matters. A single agent doing text generation is table stakes in 2026. But having text, image, and video agents coordinated through the same pipeline means the visual assets actually match the copy. The hero image for a post was designed with the same brief context as the caption text. That consistency is hard to achieve even with human teams where the copywriter and designer work from the same brief but interpret it differently.

Content analysis that used to take a full session now saves 3 hours per round.

Layer 5: Media Buying and Optimization

Here's the part that surprised me. The agents connect directly to the Juguang API and auto-purchase traffic. They optimize ad placement in real-time based on performance data flowing back through the pipeline. No human sitting there adjusting bids at 2 AM because a post went viral at midnight.

The feedback loop is tight. Performance data from live campaigns feeds back into the optimization agent, which adjusts spend allocation across the 30 influencers based on real conversion data, not projections. Underperforming placements get throttled. High-performers get more budget. This happens continuously, not in morning review meetings.

Layer 6: Settlement

The system charges by sales leads. Performance-based pricing with automated tracking through to settlement. The attribution chain from impression to click to lead to payment is tracked end-to-end within the agent pipeline.

The numbers after one month

After a 1-month trial run:

Natural click-through rate improved by 2.7% compared to comparable campaigns
30% efficiency gain across the workflow
3 hours saved per content analysis session
14 agents from influencer selection to settlement
Zero manual execution steps

2.7% CTR improvement might sound small if you're not in marketing. In influencer campaigns, where natural CTR benchmarks hover in the low single digits, that's a meaningful lift. And it came from better influencer-content matching, not from spending more.

Why multi-agent beats single-agent for this

You could theoretically build one giant agent that handles everything. But the coordination problem is real. Each stage has different data sources, different APIs, different optimization criteria. A monolithic agent would need to hold all of that context simultaneously.

The 14-agent approach lets each agent specialize. The influencer selection agent doesn't need to know anything about media buying. The content generation agent doesn't care about settlement logic. They communicate through structured handoffs.

This maps well to how human marketing teams actually work. You have a strategist, a media buyer, a creative director, a data analyst. They don't all do each other's jobs. They pass work products between roles.

The platform underneath: OCTO

This pipeline runs on OCTO, an open-source workplace designed for humans and AI agents to collaborate. Apache 2.0 licensed, self-hosted.

OCTO has four core concepts worth understanding:

Agents are digital workforce doubles. They inherit your authorization and taste preferences. Not generic chatbots. They're configured to act within your specific context and permissions.

Workspaces are where collaboration happens.

Loops are work units. Each loop has an assignee, deliverables, and acceptance criteria. Think of them as the atomic unit of work that flows from conversation to delivery.

Preferences accumulate over time. Every review, every rejection, every approval becomes experience data. The agents get better the more you work with them.

The name OCTO itself encodes the design philosophy: Open, Context, Taste, Orchestration.

For the orchestration piece, OCTO supports 6 collaboration modes:

Solo: one agent, one task
Roundtable: multiple agents discuss and converge
Critic: one agent proposes, another critiques
Pipeline: sequential handoff, like the marketing case above
Split: parallel execution on independent subtasks
Swarm: dynamic task allocation across an agent pool

The marketing pipeline primarily uses Pipeline mode with some Split for parallel content generation.

Running it yourself

The repos are on GitHub:

octo-web — 1,178 stars
octo-server — 1,059 stars
octo-cli — 918 stars

Self-hosted means your data stays on your infrastructure. For marketing campaigns involving client data and influencer analytics, that matters more than most people realize.

What I actually think about this

The marketing use case is compelling because it's boring. Not boring in a bad way. Boring in the sense that it's a real business workflow with real money attached to it. Nobody built this to win a hackathon. They built it because the manual version of this process is slow and expensive.

The 14-agent architecture is also interesting because it's not trying to be AGI. Each agent is narrow and good at one thing. The intelligence comes from the orchestration layer connecting them, not from any single agent being superhuman.

Multi-agent systems that actually run in production, on real campaigns, with measurable business outcomes. That's the part worth paying attention to.

The real lesson: orchestration > intelligence

After watching this pipeline run for a month, the takeaway that stuck with me is simple. The gains didn't come from having a smarter model. They came from having a smarter way to decompose work.

Every time we tried to make a single agent handle more stages, performance degraded. Context windows filled up with irrelevant information from other stages. The influencer selection agent made worse choices when it also had to think about media buying constraints. Splitting responsibilities and connecting them through clean interfaces worked better every time.

There's a parallel to microservices architecture here. Monoliths work until they don't. The moment your problem has enough independent dimensions, decomposition wins. Marketing campaigns have at least six independent dimensions: data, selection, strategy, content, distribution, and settlement.

The 14-agent count isn't magic. Some stages use multiple agents internally. The selection stage alone has agents for audience analysis, style matching, and pricing optimization that feed into a ranking aggregator. The point is that granularity at the agent level mapped naturally to granularity at the task level.

If you've deployed multi-agent systems in production, what coordination patterns worked for you? Pipeline seems natural for linear workflows, but I'd be interested in hearing about cases where Swarm or Roundtable modes proved more effective.

A specialized web agent scored 41.7 on WebRetriever while GPT and Claude failed the same form-filling task

Mininglamp — Thu, 17 Sep 2026 10:53:20 +0000

General-purpose LLMs are bad at browser automation. I spent the last few months working with various computer-use agents, and the performance gap between specialized models and general ones is way bigger than most people expect.

Heres a concrete example. On WebRetriever Protocol I, a benchmark that tests real browser navigation and form-filling, Mano-CUA 1.1 scored 41.7 NavEval. Gemini 2.5 Pro Computer Use got 40.9. Claude 4.5 Computer Use landed at 31.3. The full project is at github.com/Mininglamp-AI/Mano-P if you want to look at the model and benchmark setup.

That 10-point gap between Mano-CUA and Claude isnt noise. It shows up consistently across tasks that require multi-step form interaction, dropdown selection, and navigating through paginated results.

Why general models struggle with browser tasks

GPT-4o and Claude are incredibly good at reasoning over text. But browser automation is a different kind of problem. You need to understand spatial layout, click targets that change after each interaction, and UI elements that look different across every website.

Most general models handle this by parsing the DOM or relying on accessibility APIs. That works for simple pages. It breaks down fast on complex web apps with dynamic rendering, custom components, or heavy JavaScript.

Mano-P takes a different approach. Its pure vision-driven. The model looks at screenshots the same way a human user would, identifies clickable elements from pixels, and plans the next action based on visual context alone. No DOM parsing, no API hooks, no accessibility tree dependency.

This matters because real-world web pages are messy. A DOM parser sees a div with an onclick handler. A vision model sees a blue button that says Submit. When the page structure changes but the visual layout stays the same, the vision approach keeps working while the DOM parser breaks.

The form-filling problem

Form-filling is where most general models completely fall apart. A typical form has text inputs, dropdowns, radio buttons, date pickers, and sometimes nested sections that appear conditionally. Each interaction changes the page state.

General models tend to lose track of where they are in the form after 4 or 5 steps. They click the wrong field, skip required inputs, or get stuck in loops where they keep trying the same failed action.

On WebRetriever Protocol I, the tasks include real web forms from actual websites. Not simplified test pages. Real sites with captchas, multi-page flows, and validation errors that redirect you back to fix something.

Mano-CUA handles these because the think-act-verify loop in its architecture forces it to check whether each action actually worked before moving to the next step. If it clicks a dropdown and nothing opens, it tries again. If a form field rejects the input, it reads the error message from the screenshot and adjusts.

Running it locally

One thing that sets Mano-P apart from cloud-based solutions is that it runs entirely on your machine. The 4B quantized model runs on Apple M5 Pro hardware at about 80 tokens per second decode speed. All your data stays local. No screenshots get sent to any server.

The setup is straightforward if you have a Mac with Apple silicon and 32GB RAM:

brew tap Mininglamp-AI/tap && brew install mano-cua
mano-cua check
mano-cua install-sdk
mano-cua install-model
mano-cua run "fill out the application form on example.com" --local

The --local flag ensures everything stays on-device. Without it, inference goes through their cloud endpoint, which is faster but sends screenshots to their server.

The specialization argument

Theres a broader trend here. General models keep getting better at everything, but specialized models are pulling ahead on specific verticals. Browser automation is one of them. Code generation is another. Medical imaging is a third.

The reason is training data composition. A general model trains on everything and learns a bit about GUIs from the fraction of its data that includes UI screenshots. A specialized model like Mano-CUA trains specifically on GUI interaction sequences, with reinforcement learning that optimizes for task completion, not just next-token prediction.

Mano-P uses a three-stage training pipeline. First supervised fine-tuning on GUI interaction data. Then offline reinforcement learning with logged trajectories. Then online RL where the model actually interacts with live interfaces and learns from success and failure.

That last stage is the key differentiator. The model doesnt just learn what a correct click looks like from labeled data. It learns what happens when it clicks wrong and how to recover.

Benchmark context

Some context on the numbers. On OSWorld, which tests desktop-level tasks across multiple operating systems, Mano-CUAs 72B evaluation model hit 58.2% success rate. Thats the top score among specialized models, 13.2 points above the second place. Important note: the 72B model is an evaluation model, not what you actually run locally. The local 4B thinking model scored 56% on a 100-task macOS GUI test, still well above Qwen3-VL-Plus at 39% on the same test set.

WebRetriever Protocol I is more focused. It tests specifically web navigation and retrieval tasks. The 41.7 score there puts Mano-CUA ahead of both Gemini 2.5 Pro and Claude 4.5 on their computer use modes.

What this means for developers

If youre building browser automation workflows, the practical takeaway is simple. General models give you flexibility but mediocre results on complex web tasks. Specialized models give you significantly better completion rates on the specific things they were trained for.

For anything involving form submission, data extraction from web UIs, or multi-step navigation through complex sites, a vision-based specialized agent will save you a lot of failed runs compared to throwing GPT or Claude at the same task.

The project is Apache 2.0 licensed. The code, the CLI tool, and the 4B model weights are all open source. Check the repo at github.com/Mininglamp-AI/Mano-P for benchmarks, model downloads, and the full technical report.

We Connected Digital Agents to Physical Robots via a Multi-Agent Network at WRC 2026

Mininglamp — Tue, 15 Sep 2026 07:19:42 +0000

At this year's World Robot Conference in Beijing, a robot walked up to the podium on closing day and helped run the award ceremony. It came from a joint booth between Mininglamp and HIKROBOT.

The robot mattered less than the reason it was there. Four days earlier, at the main forum, Mininglamp's founder laid out a claim: for robots to actually enter commercial production, they need two brains. The three scenarios on the booth — restaurant cleaning, warehouse logistics, patrol — were all built around that claim. This post is about the claim.

The First Brain: Vision In, Action Out
The hottest battlefield in embodied AI has been the pipeline from visual input to physical action. OpenVLA, the π0 series, VLA-JEPA — all of them are trying to let a robot see, understand, and act the way a person would. Progress here is fast.

Push those models into an actual restaurant or warehouse and a different layer of problems shows up:

One robot clears tables, another collects trays. How do they coordinate?
The front-of-house system fires a new order. How does the kitchen robot know to start prep?
A patrol robot flags an anomaly. How does that event reach security and the person on duty?
None of these live inside a VLA model. They live above it. That upper layer is the second brain — the organizational brain.

The Second Brain: Orchestration Above the Model
The organizational brain does three things: coordinate multiple machines, dispatch across systems, connect to existing IT. Making the VLA model bigger doesn't solve any of these — they're orchestration problems, not perception problems.

This isn't a new idea for us. In 2018 Mininglamp put out a framework called HAO — Human, a broad notion of AI (digital agents and physical robots both count), and Organizational Intelligence. The point was to put people, agents, and robots on one network and let division of labor produce organization-level output.

Octo, Mininglamp's open-source human-agent collaboration platform, is the first step of that idea in the digital world — agents dividing tasks, sharing context, accumulating experience. The WRC scenarios were the first public demo of that orchestration extending into the physical world.

Same Road, Two Bodies
Line up the technical evolution of agents against robots and you see the same road.

Tool use: the digital world went rule engines → expert systems → RPA → workflows → general agents. The embodied world went PLC → behavior trees → end-to-end VLA. Both swing between hard-coded and fully autonomous, and both are landing on structured skills in the middle (Claude Skills on the digital side, atomic skill libraries on the robot side).

Memory is even more parallel. Digital agents use working, episodic, semantic, and procedural memory — the CoALA four layers. Embodied robots need spatial memory, task trajectory memory, semantic memory, skill memory. Same architecture, different bodies.

One gap worth naming: "ontology" in embodied contexts usually means physical structure, while ontology in semantic memory is an abstraction of concepts and relationships. Those two eventually need to share one semantic layer, or a robot can't really understand what a human or an agent is saying.

A Protocol Shaped Like Email
For the organizational brain to actually run, robots, agents, and legacy systems need a shared communication protocol.

The shape we'd argue for looks like email — open, simple, not locked to a single vendor. Every company should be able to run its own orchestration platform, and those platforms should still talk to each other.

The digital side has been moving. MCP addresses model-to-tool. A2A addresses agent-to-agent. Once robots join, participant types expand and latency and safety tighten — but the open, vendor-neutral principle should carry across both worlds.

Where We Actually Are
We treat the WRC collaboration as a validation of direction, not a finished answer. How far the organizational-brain layer can actually go still needs more time and more real-world scenes.

Two things worth being honest about. Physical actions are often irreversible, and latency budgets are tighter than anything the digital-agent world has had to deal with — the orchestration layer has to account for both. And the L1-to-L5 organizational path we've watched play out in the digital world (usable model access, daily agent use, shared semantic memory, evaluation networks, base-model-decoupled capability) — whether it repeats in the embodied world is a hypothesis, not a conclusion.

That's also why Octo is open source. A genuinely open orchestration protocol has to be tested by enough scenarios and enough developers, not settled behind closed doors.

If you're working on multi-agent orchestration, embodied AI deployment, or robot-agent communication protocols, the repo is open:

GitHub

We Connected Digital Agents to a Physical Robot at WRC 2026 — Why Robots Need Two Brains

Mininglamp — Fri, 28 Aug 2026 10:46:06 +0000

A Robot at the Award Ceremony, and the Judgment Behind It

At this year's World Robot Conference (WRC) in August, a robot stood beside the podium on the closing day, helping staff carry out the award ceremony. It was a joint creation from Mininglamp and HIKROBOT's shared booth, and one of the few images from the event that stuck with both trade visitors and camera lenses.

The robot's significance wasn't in the ceremony itself. It appeared on that stage because of a keynote given earlier, where Mininglamp founder Minghui Wu laid out a judgment at the WRC main forum: for robots to actually enter commercial production systems, they need two brains. The three scenarios shown at the booth — restaurant cleaning, warehouse logistics, and patrol — were all built around that judgment.

This piece isn't really about the keynote, or the robot. It's about the judgment itself, and what "the second brain" actually means when we say a robot needs one.

The First Brain: Vision In, Action Out

The hottest battlefield in embodied AI for the past two years has been the pipeline from visual input to physical action.

The names everyone in the field recognizes sit on this line: OpenVLA, the π0 series, VLA-JEPA. What they're all doing, at core, is letting a robot see, understand, and act, the way a person would. Progress here has been fast — new data scales, new architectures, new training strategies every few months.

But put these models into an actual restaurant, an actual warehouse, an actual patrol route, and a different layer of problems shows up immediately:

If one robot clears tables and another collects trays, how do they coordinate?
When a front-of-house ordering system fires a new order, how does the kitchen robot know to start prepping?
When a patrol robot flags an anomaly, how does that event get routed to security and the person on duty?

None of these questions belong to any single VLA model's job description. They live above the model, not inside it.

That's what we mean by the second brain — the organizational brain.

The Second Brain: The Orchestration Layer Above the Model

The organizational brain handles three things: coordinating multiple machines, dispatching across systems, and connecting with a company's existing IT stack.

Multi-machine coordination means multiple robots know what each other is doing, avoid conflicts, and share context.
Cross-system dispatch means digital agents and physical robots can hand tasks to each other and exchange state.
Connecting with existing IT means a robot stops being a standalone showpiece and becomes one link in a scheduling system, an inventory system, a ticketing system.

Making the VLA model bigger and stronger doesn't solve any of these. They're orchestration problems, not perception or control problems.

This isn't a new judgment for us. Mininglamp put forward a framework back in 2018 called HAO — H for Human, A for a broad notion of artificial intelligence covering both digital agents and physical robots, O for Organizational Intelligence. The core idea was to connect people, agents, and robots onto one network, generating organization-level productivity through division of labor rather than expecting any single entity to be fully capable on its own.

Octo, Mininglamp's open-source human-agent collaboration platform, is the first step of that idea being built in the digital world — letting digital agents collaborate with each other, share context, and accumulate experience. The three scenarios shown at the joint WRC booth were the first public demonstration of that orchestration capability extending from the digital world into the physical one.

Two Technical Paths, One Evolution

Line up the technical evolution of agents against the technical evolution of robots, and something interesting shows up: they're following the same road.

On tool use: the digital world moved from rule engines, to expert systems, to RPA, to workflows, and eventually to general-purpose agents. The embodied world moved from PLC programming, to behavior trees, to end-to-end VLA models today.

Both lines swing between "hard-coded" and "fully autonomous." The digital world eventually landed on something in between — structured skills, with Anthropic's Claude Skills as a recent example. The embodied world has started producing something similar, structured "atomic skill libraries" as a complement to pure end-to-end approaches.

The memory line is even more clearly parallel. Digital agents use working memory, episodic memory, semantic memory, and procedural memory — the CoALA four-layer framework. Embodied robots need something equivalent: spatial memory, task trajectory memory, semantic memory, skill memory.

It's the same memory architecture, sitting on two different bodies. There's one place that still needs bridging: "ontology" in embodied contexts usually means physical structure, while ontology in semantic memory means an abstraction of concepts and relationships. Eventually these two need to share one semantic layer for a robot to actually understand what a human or an agent is saying.

This is also why we think a team that has spent years building digital agent orchestration isn't crossing into a new field by working on embodied intelligence — it's a natural extension of the same work.

Communication Protocol: An Open Layer Like Email

For the organizational brain to actually function, it needs a communication protocol connecting robots, digital agents, and legacy systems.

The ideal shape of that protocol looks a lot like email — open, simple, not locked to a single vendor. Every company should be able to run its own orchestration platform, and those platforms should still be able to talk to each other.

The digital world has made progress on this front over the past year or two: MCP addresses the protocol between models and tools; A2A addresses the protocol between agents. Once robots join the picture, the protocol has to cover more types of participants, and the requirements on latency and security get stricter — but the principle of staying open and vendor-neutral should hold across both worlds.

L1 to L5: A Path of Organizational Evolution

The digital world has broadly gone through five stages: L1, everyone has access to usable model inference; L2, everyone works with agents day-to-day, and legacy tools become callable by agents; L3, humans and agents share structured semantic memory; L4, a complex collaboration network forms across the workforce, continuously improved through evaluation and benchmarking; L5, a company accumulates its own data and capability, decoupled from any specific base model.

Whether this path repeats itself in the embodied world isn't something we have an answer for yet. Embodied AI as a field is still young, and the infrastructure layer is still being figured out. We're putting this out as a hypothesis worth discussing, not a conclusion we've already validated.

A Role: The Forward Deployed Engineer

Buying an AI tool doesn't automatically mean a business process starts running. Someone usually has to be on-site, fitting the model's capabilities and skills into a company's actual workflow.

The digital world already has a name for this role: the Forward Deployed Engineer (FDE). Palantir built its early success on this role in complex, real-world deployments, and it's since become an industry-recognized position.

Robots entering commercial settings need the same kind of role — someone who connects motion control capability with the actual operating procedure of a specific scene, so the robot becomes a working part of the process rather than a demo on a show floor. This layer of capability comes from engineering practice, not from the model itself.

Back to Octo

The "organizational brain" discussed at WRC is, in engineering terms, exactly what Octo has been building as its orchestration layer.

Up to now, Octo has mainly connected digital-world agents — letting different agents divide up complex tasks, share context, and accumulate experience. Looking ahead, there's no reason for this orchestration capability to stay confined to the digital world. Robots and embodied devices are, in principle, participants that can be brought into the same collaboration network; the difference lies in how they connect and what constraints apply — physical actions are often irreversible, and latency requirements are stricter, both of which the orchestration layer needs to account for.

We currently see this WRC collaboration as a validation of direction, not a finished answer. Restaurant cleaning, warehouse logistics, and patrol are concrete business collaborations between Mininglamp and HIKROBOT; how far the organizational brain layer can actually go still needs more time and more real-world scenarios to work out.

That's also why we keep Octo open source, and why we're putting this judgment out for discussion — a genuinely open orchestration protocol should be tested by enough scenarios and enough developers, not settled behind closed doors.

If you're working on multi-agent orchestration, embodied AI deployment, or robot-agent communication protocols, feel free to check out the Octo repo and open an issue:

https://github.com/Mininglamp-OSS

Mininglamp and HIKROBOT Showcase Embodied AI at World Robot Conference 2026

Mininglamp — Wed, 26 Aug 2026 10:42:41 +0000

On August 19, the 2026 World Robot Conference (WRC) opened in Beijing. Mininglamp (HKEX: 2718), together with HIKROBOT, showcased embodied intelligence progress in commercial service scenarios — marking Mininglamp's formal entry into the embodied AI track.

Commercial service robots are currently one of the most closely watched deployment directions in the robotics industry, and 2026 is widely seen as the key commercialization window, with cleaning robots being the fastest-growing sub-category. But on the ground, getting hardware and software to work together — and getting a robot to independently complete long-horizon tasks in real, unstructured environments — is still an open problem.

Mininglamp's answer is to give robots an "AI brain" that can observe, reason, and collaborate, so commercial service robots can autonomously complete full task chains in open, unstructured environments.

On the show floor: a closed loop for commercial service scenarios

At this year's WRC, the joint Mininglamp/HIKROBOT booth focused on commercial service scenarios, demonstrating three use cases live: restaurant cleaning, industrial logistics, and smart patrol.

In the restaurant scenario, a wheeled humanoid robot and a wheeled dual-arm robot worked together to autonomously clear tables, collect dishes, and clean floors — a full closed loop from autonomous task planning to end-to-end execution in an unstructured environment. One detail worth noting: after large-scale training, the robots can distinguish objects on a table, telling food waste apart from items like phones, keys, or documents, and only removing the trash without disturbing anything a customer left behind.

In the industrial logistics and smart patrol scenarios, robots demonstrated a full flexible piece-picking pipeline — high-shelf retrieval, flat-surface transport, case handling, and fine-grained sorting — while the patrol robot showed autonomous patrolling, real-time perception, and anomaly detection in a complex environment.

On the division of labor: Mininglamp focused on VLM/VLA (vision-language models / vision-language-action models), building the core intelligence stack — multimodal perception, task reasoning and planning, and multi-agent coordination — to address the pain points of commercial service robots operating in unstructured settings. Mininglamp's Mingsheng Pinzhi unit has spent years in offline restaurant operations, accumulating data and domain know-how. HIKROBOT brought deep expertise in mobile robot hardware, motion control, multi-sensor fusion, systems software, integration, and mass production engineering. Together, the two sides are exploring how AI-driven commercial service robots can scale.

Why Mininglamp is getting into embodied AI: the organizational intelligence thread

This year's WRC theme was "human-machine symbiosis, supply-demand convergence" — and how humans, digital agents, and other agents collaborate efficiently is something Mininglamp has been working on for a long time.

Back in 2018, Mininglamp proposed the HAO framework (Human + AI + Organization): H stands for Human; A stands for Artificial Intelligence, covering both digital-world agents and physical-world robots; O stands for Organizational Intelligence. Mininglamp's open-source human-AI collaboration platform, Octo, is how HAO intelligence is being put into practice — bringing humans, digital agents, and robots onto the same collaborative network, sharing context, tasks, and preferences.

In Mininglamp's view, intelligent labor inside an organization is now showing up in two forms at once: agents in the digital world, and robots in the physical world. Though they belong to different worlds, the underlying technical paths are structurally similar — multimodal perception, task reasoning and planning, and action execution are, at their core, the same capability stack applied to two different "bodies." Mininglamp previously taught software-world agents to see, think, and act; this time, the same capability is extending to physical-world robots, letting them participate in collaboration as members of the organization.

The second half of robotics is about the "brain"

Mininglamp founder, CEO and CTO Wu Minghui gave a keynote at the WRC main forum, titled "Agent + Embodiment: How Application Demand Drives the Evolution of Robot Intelligence," laying out Mininglamp's thesis on the embodied AI track.

"The key to the second half of robotics is the brain," Wu said. He described two dimensions of "brain": the first is the traditional robot brain — reasoning, task decision-making, and motion planning capability, powered by models like VLM and VLA. The second is the organization's brain. Once a robot is actually deployed into a production system, into offline service industries and commercial scenarios, how it gets embedded into the broader organizational system — eventually forming an organization-level brain — matters just as much. No single robot's own model can solve that by itself.

That's exactly where Octo, Mininglamp's open-source human-AI collaboration platform, comes in. As Wu put it, what Octo is ultimately building toward is "an organization-level human-machine collaborative brain, not just the individual brain of each robot." He also spoke about future connectivity: "We believe Octo will eventually connect not just agents in the digital world, but agents in the physical world too — embodied devices, self-driving cars. Robots to robots, robots to agents, legacy IT systems to next-generation AI systems — in the future, all of this might be connected through open protocols."

From the digital world to the physical world

From unmanned restaurant cleaning to flexible warehouse picking, embodied AI is moving fast from technical validation to industrial deployment. For Mininglamp, this isn't just about entering a new track — it's a validation of a transferable capability. The multimodal understanding, reasoning, and multi-agent coordination refined in the digital world are now being reused and extended into physical-world robots; in turn, the data and experience robots accumulate in real scenarios will feed back into model iteration, forming a positive flywheel of scenario, data, and capability.

That's how "organizational intelligence" moves from blueprint to reality: get an agent's perception, decision-making, and collaboration working in the digital world first, then extend the same intelligence to every robot in the physical world. Octo is open source on GitHub — if you're interested in how humans and AI agents (and eventually physical-world agents) can collaborate, take a look at the code, and a star is always appreciated: https://github.com/Mininglamp-OSS/octo-server

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.