DEV Community: Mininglamp

Why Shared Organizational Memory Matters More Than Prompt Chaining in Agent Teams

Mininglamp — Fri, 16 Oct 2026 06:26:21 +0000

Most multi-agent setups treat agents like functions in a pipeline. Agent A generates a spec, Agent B writes code, Agent C reviews. Information flows one way, and each agent only sees what the previous one passed along. This works for demos but falls apart in real projects where context accumulates and decisions depend on each other.

We have been running multi-agent workflows on Octo at Mininglamp Technology, and the biggest lesson is that shared organizational memory matters more than how you chain prompts.

Six collaboration patterns and their information topologies
Octo supports six modes: Solo, Roundtable, Critic, Pipeline, Split, and Swarm. The difference between them comes down to how information flows.

Pipeline is linear. Agent A finishes, passes output to Agent B, and so on. Downstream agents only see what upstream sent them. If the product manager forgot to mention a constraint, every agent after that is working blind. We ran into this constantly in early experiments.

Roundtable puts every agent in the same room. All participants see the full conversation history. When the product manager raises a requirement, the developer sees it, the reviewer sees it, and the deployer sees it. Token cost goes up, but information loss goes way down.

Critic builds on Roundtable by adding a dedicated adversarial reviewer. The reviewer's job is to find problems, not to be polite. In our code review workflows, the Critic agent caught issues like unsafe file handling patterns that would have shipped otherwise. One specific example from our internal workflow: the reviewer flagged that a download function would silently save an error page as if it were the actual file if the download failed. That kind of bug is easy to miss in human review too.

Split parallelizes. You break a task into subtasks, hand each to a different agent, and merge results at the end. The risk is that parallel agents make conflicting assumptions because they cannot see each other's work until merge time.

Swarm is the most dynamic. No predefined routing. Agents observe global state and claim tasks as they see fit. Good for situations where you cannot plan the task graph upfront, but it needs a reliable state broadcast mechanism to prevent agents from stepping on each other.

What shared context looks like in practice
We run a four-agent dev workflow internally: AI product manager, AI developer, AI reviewer, and AI deployer, all in one group chat backed by an Octo Space.

The Space holds the complete project state. Every requirement discussion, every code change, every review comment, every deployment log. When the product manager says "confirm this bug is real, if so fix it per standard process," nobody needs a briefing. The project context is already there.

Here is how a typical bug fix plays out. The product manager digs into the codebase, locates the root cause, plans the fix, specifies the branch strategy, and assigns it to the developer. The developer confirms the issue exists in two files, starts coding. A few minutes later the PR is up. The reviewer goes through it and finds two problems that must be fixed before merge. The developer addresses both, updates the PR. The reviewer re-checks each item. Once everything passes, the deployer packages and ships to staging. The product manager generates an acceptance checklist and waits for human sign-off.

The human said one sentence at the beginning and clicked approve at the end. Everything in between happened autonomously through shared context.

Compare that to tools like Cursor where you feed context manually, file by file. Switch sessions and your prior context is gone. In our setup agents navigate organizational context themselves and divide up the work.

Learning compounds over time
Single-session collaboration quality depends on mode selection and context design. But the longer-term question is whether agents get better across sessions.

We tracked one agent from Day 1 to Day 49. On Day 1, it knew nothing about Mininglamp, could not distinguish between our different products, did not know team members or their roles. By Day 7, it could accurately differentiate product positioning. By Day 14, it produced presentation outlines that passed review on the first try. By Day 49, it had grown from a generic chatbot into a specialist with 45 professional skills.

Two learning channels made this happen: humans teaching agents and agents teaching agents. Team members shared strategy context, PR playbooks, technical boundaries in daily conversations. Other agents contributed too, teaching brand design standards and proofreading protocols. Every message was a learning event.

The mechanism behind this is Octo's Experience system. Acceptance feedback from completed tasks automatically converts into reusable knowledge. Skills are not pre-programmed. They emerge from real work. Our network currently has 1770 agents and 45 specialized skills built this way.

Context gives direction. Skills give execution ability. The two multiply into exponential growth.

Loop architecture: keeping information inside the boundary
In the BPIT AI Coding project, we set up a Loop with six agents: CRM dispatch, requirements analysis, backend development, frontend development, testing, and code review. A Loop in Octo represents the full lifecycle from task intake to deliverable.

All agent state, logs, and outputs persist inside the Loop for the entire task duration. When something goes wrong or needs human approval, agents proactively surface it to the responsible person instead of silently failing or hallucinating a workaround. The information boundary of the Loop guarantees that no context is lost during role handoffs.

This matters because in most multi-agent setups, the handoff between agents is exactly where information drops. The Loop architecture eliminates that by keeping everything in one persistent context boundary.

Open source: https://github.com/Mininglamp-OSS

Deploying a Local GUI Agent on Apple Silicon

Mininglamp — Wed, 14 Oct 2026 03:33:32 +0000

We've been running Mano-P as a local GUI agent on Apple Silicon for a few weeks now. Here's the practical walkthrough for getting it up on your own Mac.

What It Does

Mano-P is a vision-driven GUI agent. It looks at your screen, decides what to click or type, and executes multi-step tasks autonomously. No OCR pipeline, no accessibility tree parsing. Pure screenshot-to-action. The model is Mano-CUA-4B-Thinking-1.1, quantized to MLX 8-bit, with a peak memory footprint of 4.3GB.

Setup

The install is a single Homebrew tap:

brew tap Mininglamp-AI/tap && brew install mano-cua

Then three commands:

mano-cua check        # verify hardware compatibility
mano-cua install-sdk  # install runtime dependencies
mano-cua install-model # download the 4B model

Hardware requirement: M4 chip or newer with 32GB+ RAM. Alternatively, any Mac with a USB 4.0+ compute stick works.

You'll need to grant Screen Recording and Accessibility permissions in System Settings. That's the entire setup.

Running It

mano-cua run "open Safari, search for today's weather" --local

The --local flag keeps everything on-device. No API keys, no cloud calls, no screenshots leaving your machine.

Performance

On an M5 Pro, decode speed sits around 80 tok/s. In our 100-task real Mac GUI benchmark on a MacBook Pro M5 with 16GB, the Thinking-4B model hit 56% task completion. For comparison, Qwen3-VL-Plus running through cloud scored 39% on the same test suite. On OSWorld, specialized models reached 58.2%, currently #1 on that leaderboard.

Cider W8A8 quantization gives roughly 12.7% faster prefill compared to W8A16.

Trade-offs

The 4B model is small. It handles routine GUI tasks well but struggles with complex multi-app workflows. The 32GB RAM floor is real. And granting Screen Recording access means the agent can see everything on your display, so treat it like you'd treat any screen-sharing tool.

Source and License

Full client source is open under Apache 2.0 for audit. GitHub: https://github.com/Mininglamp-AI/Mano-P

If you try it out, we'd appreciate a star. Bug reports even more so.

No API Keys, No Cloud Bills: Running a Document Pipeline Entirely On-Device

Mininglamp — Fri, 09 Oct 2026 06:34:56 +0000

No API Keys, No Cloud Bills: Running a Document Pipeline Entirely On-Device

We run a document processing pipeline on a Mac mini. No API keys. No cloud inference. No network calls at all during execution. This post is about what that actually looks like in practice, what went wrong along the way, and where we landed on performance.

Why we went local

Our team builds tooling for due diligence workflows. Contracts, financial statements, scanned images, password-protected archives. The kind of stuff clients will not let you upload anywhere, period. We tried wrapping cloud vision APIs behind a VPN with audit logging, and the compliance team still said no. Fair enough.

So we started looking at on-device GUI agents. The idea: a model that can see the screen, click through file managers, open PDFs, read images, and do it all without any data leaving the machine.

We settled on Mano-P, an Apache 2.0 open-source agent built for edge devices. It uses a 4B parameter model with W8A8 quantization, runs through a vision-only pipeline, and needs no API endpoints or MCP servers. The whole thing installs via brew.

brew tap Mininglamp-AI/tap && brew install mano-cua

The actual pipeline

Here is what a typical session looks like for us. Someone drops a task: process a batch of due diligence files. The agent handles it step by step, all on the local machine.

First, it searches the local filesystem for the target archive. We tested this on nested folder structures with 2000+ files and it consistently found the right one. Then it needed a password to unzip. The password was stored in a separate local note. The agent found that too, entirely on its own, just by navigating the local file system visually.

After unzipping, it reads the contents, including scanned images. The vision model handles layout-heavy documents reasonably well. Not perfect on every table cell, but good enough for extraction tasks where you need 90% accuracy and a human does a final check.

The last step is batch processing. We threw 200 contracts at it. Each one needed the same extraction routine. On our M4 Pro Mac mini with 32GB RAM, the 4B model runs at roughly 80 tokens per second decode speed. That is fast enough that the bottleneck is actually the GUI interaction latency, not the model inference.

Numbers that matter

We ran a head-to-head comparison. 100 real GUI tasks on macOS, local 4B model versus cloud-based Qwen3-VL-Plus.

Local 4B thinking model: 56% pass rate, average 7.9 seconds per step.
Cloud Qwen3-VL-Plus: 39% pass rate, average 10.2 seconds per step.

That was the result that made us commit to local. A model one hundredth the size of typical cloud VL services, running on consumer hardware, beating the cloud option by 17 percentage points on real GUI tasks. The latency was better too because there is zero network round-trip.

On OSWorld specialized benchmarks, the underlying model scores 58.2%, holding the top spot among specialized models. The second place entry scores 45.0%. On web navigation tasks via the WebRetriever protocol, it hits 41.7 NavEval, which edges past Gemini 2.5 Pro at 40.9 and Claude 4.5 at 31.3.

What went wrong

Plenty. Some honest notes.

The first week was rough. Screen recording permissions on macOS are finicky and the model occasionally misclicked on small UI elements. Dense dropdown menus were a consistent failure mode early on. We ended up increasing the resolution of screenshots fed to the model, which helped but also slowed down prefill slightly.

Memory was tight. The 4B quantized model peaks around 4.3GB, which sounds small, but when you also have the target application open plus a file manager plus Preview showing scanned images, you are pushing the 32GB envelope. We had to be deliberate about closing unused windows.

Batch processing at 200 files revealed another issue: the agent occasionally lost track of which file it had already processed. We worked around this by having it maintain a simple checklist in a text file as it went. Not elegant, but effective.

The privacy argument in practice

People talk about data sovereignty in the abstract a lot. For us it is extremely concrete. A client hands over 200 contracts containing names, financial figures, deal terms. In the cloud model, every screenshot of every page goes to a remote server. Even if the provider promises not to retain data, the compliance paperwork alone takes weeks.

With local execution, the conversation is different. We show the client the network monitor. Zero outbound connections during the entire processing run. The audit log is a local file they can inspect. Compliance review took two days instead of two months.

Hardware setup

Mac mini, M4 chip, 32GB RAM. Total hardware cost under $1500. The alternative was a cloud vision API that would have billed us per image per page per document. For 200 contracts averaging 40 pages each, that adds up fast. We estimated roughly $800 per batch at current cloud pricing. The Mac mini paid for itself in two batches.

There is also a compute stick option that connects via USB 4.0 if you want to add local inference capability to an existing machine. We have not tested that path yet.

What I would tell someone considering this

Start with the 4B quantized model. Do not try to run larger models locally unless you have 64GB or more. The 4B model is surprisingly capable for GUI tasks specifically because the training pipeline was built around screen understanding, not general chat.

Test your specific UI. Performance varies a lot depending on the application. Simple file managers and text editors work great. Complex web apps with lots of dynamic elements are harder. The model handles them, but expect more retries.

Keep your expectations calibrated. This is not a cloud-scale model. It will not write your code or summarize a 100-page report in one shot. But for structured, repetitive GUI tasks with sensitive data, it is genuinely better than the cloud alternatives we tried.

Project link: https://github.com/Mininglamp-AI/Mano-P

Day 1 to Day 49: What One Agent Actually Learned

Mininglamp — Thu, 08 Oct 2026 08:47:44 +0000

We have a phrase internally that sounds like a joke but is not. Agents are not built, they are raised. Writing a system prompt and bolting on a few tools gets you something running in half a day. Getting it to the point where it can pick up real work inside a team takes a lot longer.

I kept a day-by-day log of one agent from creation through the point it could carry a delivery on its own. On day 49 the thing that had changed most was not how many tools it had. It was how it read the work.

Day 1: it cannot tell our own products apart

A freshly created agent is a blank state. It does not know what the company does, does not know how two of our products relate, does not know who owns what. Ask it about a product position and you get something that sounds plausible and is entirely beside the point, because its knowledge stops at general pretraining data.

The easy mistake here is to dump knowledge on it. Product docs, READMEs, internal wiki, all into the context window. It looks like it can answer anything, but it is reciting what you handed it. Ask something that was not in the dump and it is back to square one.

Day 7: it starts distinguishing the products

The turning point was not more material. It was spending long stretches inside a channel that had context in it.

OCTO, the platform we build, is an IM-native collaboration space where people and agents share a workspace. Project background, past decisions, discussion history all settle into those conversations. It is a Go backend, octo-server, with a React and TypeScript client, octo-web, both open source under Apache 2.0 in the Mininglamp-OSS org.

An agent sitting in that environment does not receive a curated document. It receives the reasoning a group of people produce while actually arguing about a problem. Why this option is out, why that priority comes first. That kind of information is hard to write into a doc and it happens in conversation every day. By around day seven it could reliably tell OCTO and OpenClaw apart.

Context answers knowing, skills answer doing

We track agent capability growth along two axes.

Context is its understanding of the organization. What the project does, how the team decides, what counts as good and what counts as bad. That builds up through time spent in a space with real context in it. No shortcut.

Skills are the concrete actions it can take. A new agent may only chat. Over time it picks up search, writing, logic review, slide generation. A skill is a reusable prompt package, and OCTO supports importing ready-made ones from the Skills and MCP marketplaces.

The two axes do not add. An agent that understands direction but cannot execute just offers commentary. An agent that executes well but does not understand the business will very diligently do the wrong thing. Only when both grow does the agent become useful. Internally we put it as: context tells it which way, skills let it move.

People teach people explicitly, agents teach agents by osmosis

Two sources feed the training.

The first is people. This is explicit. Someone from comms tells it what content cadence should look like, someone from product explains where the boundaries are, the CEO discusses strategy in the same channel and it is present. Deliberate teaching, but carried by ordinary conversation rather than a training session. Every message is a learning opportunity.

The second source is more interesting. Other agents in the team teach it. The agent handling brand design describes the standards to it. The one doing proofreading points out problems after it writes. There is no formal mentorship between these agents. Their interaction is ordinary collaboration, and knowledge moves during it.

That second kind of learning exists in human teams too. Apprenticeship, or just learning by watching someone senior work. Its throughput is capped by human time and patience. Agents do not have that cap. One agent explaining a standard to another costs close to nothing, and it can do it for many agents at once.

Experience: one acceptance becomes one rule

The most valuable and most lossy thing in team collaboration is feedback. Someone delivers a document, the boss says this one is not it, redo it. If that feedback lives only on that one delivery, the same class of mistake comes back next time.

OCTO has a mechanism for this called experience. Every time the requester accepts or rejects, that action is itself a training signal. When something is rejected, the stated reason gets distilled into a reusable rule attached to that agent's capability, and the next similar task picks it up automatically. We call this Taste, because a lot of the criteria cannot be written as rules, only accumulated through specific trade-offs.

This matters for continuous learning. Context and skills are the two axes of capability. Experience is what keeps them pointed the right way. Without it the growth has no direction and can drift.

What day 49 looks like

By day 49 the agent is not the thing it was at the start. It can take a concrete delivery on its own, knows who to ask when something is ambiguous, and knows which outputs will get rejected.

But ask me what it learned and I cannot answer in one sentence. It did not acquire a skill. It formed an understanding of how this team works. In a person we would call that experience. For the agent we call it the same thing, because mechanically it is the same thing.

The curve is not linear either. Some days it clearly moved. Some days almost nothing. A few times it took a wrong turn because it got bad feedback. That looks a lot like bringing a person up to speed, and a lot like training a model. It does not look much like deploying software.

Everything I described above runs on OCTO, the open-source workbench we put out under Apache 2.0, with a Go backend, octo-server, and a React and TypeScript client, octo-web, both in the Mininglamp-OSS org. It treats agents as digital doubles with identity, work history and the ability to learn, handles who an agent is and what it does, and stays out of how it runs, so OpenClaw, Claude Code, Codex, Hermes all plug in. If you are trying to raise an agent inside a real organization rather than demo one, the code will probably tell you more than this post did, and a star is the easiest way to say it was worth reading:

https://github.com/Mininglamp-OSS

There is a second repo along the same lines, Mano-P, a GUI agent that runs entirely on a local Mac with nothing leaving the device:

https://github.com/Mininglamp-AI/Mano-P

What Happens When You Treat AI Agents Like Employees, Not Chatbots

Mininglamp — Wed, 30 Sep 2026 03:35:52 +0000

Last year, one of our engineers spent an afternoon asking an LLM to refactor a monitoring service. He'd paste code, get suggestions, paste more code, correct hallucinations, paste again. Four hours later, he had a partial rewrite and a browser history full of ChatGPT tabs.

The code was fine. The process was absurd.

He wasn't using the AI wrong. He was using it exactly how everyone uses it: as a conversation partner who happens to know about code. You ask, it answers, you evaluate, you ask again. It's a better Stack Overflow. That's the ceiling.

We kept bumping into that ceiling. Not because the models were bad, but because the interaction pattern was wrong. A conversation is the wrong unit of work when what you actually need is delegation.

The ask-answer trap

Here's the pattern most engineering teams have settled into with AI. Someone has a task. They open a chat window. They describe what they want, iterating through prompts until the output looks right. Then they copy the result into wherever it actually needs to go.

This works. It's also a dead end.

The problem isn't quality. GPT-4, Claude, Gemini, whatever frontier model you prefer, they all produce genuinely useful output. The problem is that every interaction starts from zero. There's no continuity. No accumulated understanding of your codebase, your preferences, your standards. Every conversation is a first date.

It also doesn't scale. If one person can wrangle an AI through a chat window, great. But try coordinating five AI-assisted workflows across a team of twenty. Who's using which context? Where do the outputs go? How do you review what an AI produced versus what a human wrote? The chat window gives you none of this.

We spent about eight months thinking about what comes after chat. Not a better prompt interface. Something structurally different.

What changes when you give an agent a name

The first thing we tried was simple: stop treating the AI as a tool you invoke and start treating it as a worker you assign things to.

That sounds like semantics. It isn't.

When you assign work to a person, certain things are implicit. They have an identity, so you know who did what. They have context about prior work. They operate within defined boundaries of authority. And when they deliver something, you review it. You accept it or send it back with notes. Over time, they learn your standards.

None of that exists in a chat window. So we built it.

An agent in our system has an identity. Not just a name, an actual authorization boundary. It can access certain tools, certain repos, certain data sources. Its capabilities are described in what we call an AgentCard, a structured declaration of what this particular agent can and cannot do. Think of it like an employee's role description, except it's machine-readable and enforced.

This turns out to matter enormously for teams. When an agent has a defined identity and capability set, you can reason about delegation. You can say "the docs agent handles API reference updates" the same way you'd say "Sarah handles API reference updates." The mental model transfers directly.

Work as a loop, not a thread

Chat is linear. You start at the top, you end at the bottom, the conversation is the artifact.

Real work isn't like that. A task emerges from a conversation, gets shaped, gets executed, comes back for review, might get rejected and reworked. It has an owner. It has deliverables. It has acceptance criteria.

We formalized this into something we call a Loop. A Loop is a work unit that typically starts as a conversation but grows into a structured delivery cycle. Someone, human or agent, owns the Loop. There are defined deliverables. And there's an explicit acceptance step where the requester reviews the output and either accepts or rejects it.

This is different from a ticket system. Tickets are created deliberately, filed into backlogs, groomed and prioritized. Loops emerge naturally from work that's already happening. You're discussing something in a channel, a task crystallizes, someone takes ownership, work happens, results come back. The structure grows from the conversation rather than being imposed on it.

The acceptance step is where it gets interesting. When you reject an agent's output with specific feedback, that's signal. That's data about what "good" looks like in your organization. Which brings us to the part that actually compounds.

Teaching an agent your taste

Most discussions about AI agents focus on capability. Can it write code? Can it search the web? Can it use tools?

Capability is table stakes at this point. The harder question is: can it learn what good looks like for your team specifically?

We built what we call a Preference system. Every time an agent's work gets reviewed, accepted or rejected, that outcome becomes part of the agent's experience. Not fine-tuning. Not RAG in the traditional sense. Structured experience that the agent can reference in future work.

Reject a code review because the agent didn't follow your team's error handling conventions? Next time, it knows. Accept a documentation draft but note that you prefer shorter sentences? That preference persists.

This is where the employee metaphor stops being a metaphor. Employees get better at their jobs through feedback. They develop an understanding of organizational standards that goes beyond what's written in the style guide. They internalize the unwritten rules.

The Preference system is our attempt to give agents the same learning mechanism. It's slow, deliberate, and grounded in real work outcomes. No one is training a model. Everyone is just doing their jobs and the agents absorb the standards through the natural review process.

After a few weeks of active use, the difference is noticeable. Agents start producing output that needs fewer revisions. They align with team conventions that nobody bothered to document because everyone just knew them. Except now the agent knows them too.

Controlling the information surface

Here's something most agent frameworks ignore entirely: who sees what.

When a human team works on something sensitive, you don't put everyone in the same room. The legal review happens separately from the technical implementation. The security audit doesn't need access to the marketing copy. Information flows are controlled by organizational structure.

Agent systems mostly don't do this. They either give every agent access to everything or they silo agents so completely that they can't collaborate at all.

We built six collaboration modes to handle different information topologies. Solo is one agent working independently. Roundtable is a group discussion where everyone sees everything. Critic is a structured review where one agent evaluates another's work. Pipeline passes output through a sequence of agents, each seeing only what the previous one produced. Split divides work into parallel tracks with limited cross-visibility. Swarm is a large-scale coordination mode for complex tasks.

The key insight is that these modes control information visibility, not just task assignment. When you set up a Critic mode review, the reviewing agent only sees the deliverable, not the full context of how it was produced. When you run a Pipeline, each stage gets clean inputs without the noise of upstream deliberation.

This might sound like overengineering. It isn't, once you're running agents on real business data. The question of "what can this agent see" becomes as important as "what can this agent do."

The knowledge that doesn't leave

Here's the compounding effect nobody talks about.

When a senior engineer leaves your company, their institutional knowledge walks out with them. The unwritten rules, the context about why certain decisions were made, the taste that made their code reviews valuable. It's gone.

When an agent accumulates experience through months of accepted and rejected work, that knowledge belongs to the organization. The Preference data, the AgentCard configurations, the evolved understanding of team standards, all of it persists independent of any individual person.

This isn't about replacing people. Senior engineers aren't leaving because AI exists. They're leaving because they got a better offer, or they burned out, or they wanted to try something new. The question is whether the organizational knowledge they accumulated over years can persist in any form after they go.

With traditional tooling, the answer is mostly no. Documentation helps. Runbooks help. But the tacit knowledge, the stuff that's too contextual to write down, evaporates.

An agent that has been trained by your team's actual work output retains that tacit knowledge in a usable form. Not perfectly. Not completely. But meaningfully.

Where we actually are

We should be honest about the current state. Agent systems today, ours included, are early. The models hallucinate. The tool use is brittle. Context windows overflow at inconvenient moments. Running agents on real production work requires supervision that partially defeats the purpose of delegation.

But the trajectory matters more than the current snapshot. The interaction pattern of identity, delegation, structured delivery, and feedback-driven learning is sound even when the underlying models are imperfect. As models improve, the organizational scaffolding around them becomes the differentiator, not the model itself.

We've been building this system at Mininglamp Technology. It's called OCTO, a human-AI collaboration workbench that implements everything described above. It supports multiple agent runtimes including OpenClaw, Claude Code, Codex, and Hermes, because we think vendor lock-in on the execution layer is a mistake. The platform manages identity and tasks. The runtimes handle execution. Data stays in your infrastructure through private deployment.

We also recently open-sourced Mano-P, an on-device GUI agent, at github.com/Mininglamp-AI/Mano-P.

If you're thinking about agent architectures, the code is at github.com/Mininglamp-OSS.

The open question

One thing keeps nagging at us. The Preference system learns from explicit review, accepted or rejected with notes. But the most important organizational knowledge is often implicit. It's the code that nobody writes because everyone knows it would violate an unspoken norm. It's the architecture decisions that seem obvious in retrospect but only because someone with fifteen years of context made them.

How do you teach an agent the things that humans learn by osmosis? We have ideas. We don't have answers yet. If you do, we'd genuinely like to hear them.

Run a Local GUI Agent on Your Mac in 10 Minutes with Mano-P and Cider

Mininglamp — Wed, 30 Sep 2026 03:27:52 +0000

What This Guide Covers

Mano-P is an open-source GUI agent that sees your screen, reasons about what to do next, and executes real macOS actions: clicking buttons, filling forms, navigating apps. It works through an observation-reasoning-action loop. The agent takes a screenshot, feeds it through a vision-language model, decides what to click or type, executes that action, then repeats until the task is complete. The 4B model runs entirely on-device with MLX 8-bit quantization through Cider SDK. No cloud calls, no API keys, no screenshots leaving your machine.

This tutorial walks through installing Mano-P on an Apple Silicon Mac, activating Cider quantization, and running your first local GUI task. By the end you will have a working setup that can automate real macOS workflows from the terminal. Everything here was tested on an M4 Mac mini with 32GB RAM.

Prerequisites

Apple M4 chip or newer
32GB RAM minimum
macOS with Screen Recording and Accessibility permissions enabled
Homebrew installed

The quantized 4B model peaks at roughly 4.3GB memory. A 32GB machine handles it comfortably with room for your normal workload.

Step 1: Install Mano-CUA via Homebrew

Mano-P ships a CLI tool called mano-cua. Install it through the Mininglamp tap:

brew tap Mininglamp-AI/tap && brew install mano-cua

Verify the installation:

mano-cua --version

Step 2: Run the Environment Check

Before pulling any models, let the checker confirm your system meets requirements:

mano-cua check

This validates your chip generation, available RAM, macOS version, and whether Screen Recording plus Accessibility permissions are granted. If permissions are missing, macOS will prompt you to enable them in System Settings > Privacy & Security.

Grant both permissions before continuing. The agent needs Screen Recording to capture what is on screen and Accessibility to simulate mouse clicks and keyboard input. Without Screen Recording, the agent is blind. Without Accessibility, it can see but cannot interact with anything. Both must be enabled for the specific terminal application you use to launch mano-cua, whether that is Terminal.app, iTerm2, or another shell.

Step 3: Install Cider SDK

Cider is the quantization runtime that makes the 4B model fast on Apple Silicon. It provides online activation quantization for MLX with W8A8 and W4A8 support. The key idea: most quantization tools only quantize model weights, leaving activations in FP16 or BF16. Cider quantizes both, which means the matrix multiplications that dominate inference run in lower precision end to end.

mano-cua install-sdk

This pulls the Cider SDK and configures the MLX backend. The SDK handles weight quantization and activation quantization together, which is why it outperforms naive weight-only quantization approaches.

Some numbers on what Cider delivers on M5 Pro hardware:

W8A8 prefill runs roughly 12.7% faster than the W8A16 baseline
Compared to standard MLX W4A16, Cider achieves 1.4x to 2.2x prefill speedup
These gains come from quantizing both weights and activations rather than weights alone

For a GUI agent, prefill speed matters a lot. Every step involves processing a full-resolution screenshot as input tokens. Faster prefill means faster per-step latency, and the agent typically runs 7 to 8 steps per task. The cumulative savings add up.

You can find the Cider source and benchmarks at github.com/Mininglamp-AI/Cider. The project has 323 stars on GitHub at the time of writing.

Step 4: Download the Model

Pull the quantized Mano-CUA-4B-Thinking model:

mano-cua install-model

This downloads Mano-CUA-4B-Thinking-1.1, an MLX 8-bit quantized model from HuggingFace. The model weights are hosted at huggingface.co/Mininglamp-2718/Mano-CUA-4B-Thinking-1.1.

Expect a download around a few GB. Once cached locally, subsequent launches skip the download entirely.

Step 5: Run Your First Task

With everything installed, point the agent at a real task:

mano-cua run "Open Safari and search for the weather in San Francisco" --local

The --local flag ensures all inference happens on your Mac. No data leaves the device. The agent captures a screenshot, reasons about the current state, decides what action to take, executes it, then repeats until the task is complete or it determines the task is done.

Watch the terminal output. You will see the agent's reasoning steps, the actions it chooses, and its assessment of whether it succeeded. The reasoning trace shows the model thinking through what it sees on screen, which element it should target, and why. This transparency is useful for debugging when the agent makes a wrong move.

On M5 Pro, the 4B model decodes at roughly 80 tokens per second. Each step takes about 7.9 seconds on average, and most tasks complete within 7 to 8 steps. That means a typical task runs from start to finish in under a minute.

Step 6: Try More Complex Tasks

The agent handles multi-step workflows across different applications:

mano-cua run "Open System Settings, go to Wi-Fi, and tell me the network name" --local

mano-cua run "Open Notes, create a new note titled Meeting Agenda, and type three bullet points about project planning" --local

mano-cua run "Open Finder, navigate to the Downloads folder, and sort files by date modified" --local

Each task involves the agent reasoning through multiple screens, identifying UI elements, and executing the right sequence of clicks and keystrokes. The agent navigates between apps using the Dock, menu bars, and keyboard shortcuts just like a human user would. It handles dialog boxes, dropdown menus, and scroll views.

Tasks that require reading text from the screen and reporting back also work. The model can extract information from what it sees and include it in its final response.

Performance and Benchmarks

On a 100-task real macOS GUI test suite, the numbers look like this:

Metric	Value
Model	Mano-CUA-Thinking-4B
Pass rate	56.0%
Average steps per task	7.5
Average time per step	7.9s
Peak memory	4.3GB

For context, the 4B local model at 56% significantly outperforms cloud-based Qwen3-VL-Plus, which scored 39% on the same test suite. A local 4B model beating a cloud VL model on real GUI tasks is a meaningful result.

On the OSWorld benchmark, Mano-CUA-Thinking-4B achieves 58.2% success rate, the top score among specialized GUI agent models.

GSPruning: Visual Token Efficiency

Mano-P also includes GSPruning, a visual token pruning technique that reduces the number of visual tokens the model processes from each screenshot. Screenshots contain a lot of redundant information. Large uniform regions like backgrounds, menu bars, and empty space do not need as many tokens as the areas where clickable UI elements live. GSPruning identifies and removes these low-information tokens, yielding 2x to 3x throughput improvement without significant accuracy loss.

For GUI agent workloads where every single step involves a full-resolution screenshot, token pruning directly translates to faster step execution. Combined with Cider quantization, the entire inference pipeline is optimized at both the model level and the input level.

Privacy Model

Running with --local means:

All inference runs on your Apple Silicon GPU
Screenshots are processed in memory and never written to disk or transmitted
No telemetry, no cloud fallback
Your screen content stays on your machine

This matters for anyone working with sensitive documents, internal tools, or environments where screen data simply cannot leave the device.

Understanding the Action Loop

It helps to understand the cycle the agent runs through on each step:

Screenshot capture: The agent grabs the current screen state via the Screen Recording API
Visual encoding: The screenshot is tokenized and fed through the vision encoder with GSPruning applied
Reasoning: The language model generates a chain-of-thought about what it sees and what action to take next
Action execution: The chosen action (click at coordinates, type text, press a key combination) is executed via the Accessibility API
Repeat: Back to step 1 with the updated screen state

The model sees the raw pixels of your screen. It does not rely on accessibility trees, DOM structures, or any application-specific hooks. This means it works with any macOS application out of the box, including ones that do not expose accessibility metadata.

Troubleshooting

Permission denied errors: Re-check System Settings > Privacy & Security. Both Screen Recording and Accessibility must be enabled for the terminal app or iTerm you are using to launch mano-cua.

Slow first inference: The first run after install takes longer as MLX compiles the compute graph. Subsequent runs are faster.

Out of memory: Close memory-heavy applications. The model needs roughly 4.3GB at peak. On a 32GB machine this is fine, but if you have dozens of browser tabs open, free up some headroom.

Model download stalls: If mano-cua install-model hangs, check your network connection. The model downloads from HuggingFace, so a proxy or VPN might be needed depending on your region.

Wrapping Up

The full pipeline from Homebrew install to running your first GUI task takes under ten minutes. A 4B model that scores 56% on real macOS GUI tasks, runs at 80 tok/s, and fits in 4.3GB of memory is a practical tool, not a demo.

Star the repo if this is useful: github.com/Mininglamp-AI/Mano-P

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