DEV Community: Mininglamp

I Saved Every AI Code Review Message for a Sprint. Here's What Stood Out.

Mininglamp — Mon, 09 Nov 2026 02:52:23 +0000

I Saved Every AI Code Review Message for a Sprint. Here's What Stood Out.

For one sprint I archived every message from our AI code reviews. Full transcripts, not summaries. One agent writes the change, a second reviews it, and they go round after round until the review passes or a human steps in. Then I read all of it. Going through those logs taught me more than skimming merged PRs ever did.

Rejections carried most of the value

Pass reviews are short and boring. The reviewer runs its checks, finds nothing, signs off. All the interesting reading lived in the rejection rounds. A rejection forces the author agent to restate what the change actually does, and halfway through restating it, the author sometimes catches a second problem on its own. In our logs, several bugs got fixed while answering a rejection, before the reviewer even looked again.

One catch I kept rereading

The find of the sprint was a download function with no failure handling. Server returns an error page, the code saves that HTML as the downloaded file, and nobody notices until a user opens it. The reviewer agent flagged it in round one. Reading the transcript back, the rejection message does not just name the bug. It points at the exact spot where the response body gets written unconditionally.

Review comments that stop evaporating

Our review conversations live in loops, the workspace unit that carries a task from kickoff to acceptance. Every round of comments stays attached to the loop, so when a change lands three weeks later I can open it and read why an early decision was made. Before this, review feedback lived in chat and evaporated. Searching chat for old feedback is archaeology with unreliable results.

Feedback that rolls forward

The part that surprised me most sits at the end of the process. Rejections and the final acceptance feed preference cards. Each card is one verifiable rule with the evidence behind it, where it applies, and a confidence level. The download bug became a card about handling non-200 responses in any code path that writes files. The next task of that shape starts with that card already in context, so the lesson shows up before I have to repeat it.

Two or three rounds, then a human

Most PRs settled around two or three rounds. A single round usually meant the change was trivial. Past four rounds, something was off in the task itself, a vague spec or a wrong assumption baked in from the start. Those went to a person. Looking back, round count tells you about spec quality as much as code quality. Those numbers are our experience over one sprint, not a benchmark.

If you only read merged PRs, you see the final state, which is the least informative part of the process. The messages before it, especially the rejected ones, show what your review setup actually catches versus what it waves through.

All of this runs on Octo, the open-source workspace we use for human-agent collaboration. The review setup is its Critic mode, where the author agent and the reviewer agent never see each other, and work moves through do, review, reject or pass. Nothing else crosses between them. The loops and preference cards are what make the transcripts worth keeping.

https://github.com/Mininglamp-AI/Octo

Running the Same GUI Agent on Different Hardware: What Changes?

Mininglamp — Wed, 04 Nov 2026 03:39:33 +0000

When we talk about running AI locally, the first questions are usually about model size, memory, and tokens per second.

Those numbers matter. But they do not tell the whole story for a GUI agent.

A GUI agent does not receive one prompt and return one answer. It repeatedly observes a screen, reasons about the current state, performs an action, and observes the result. A task may involve many such cycles. That makes the device, inference runtime, and interaction loop part of one system.

This is one of the things we have been thinking about while working with Mano-P, our open-source, vision-driven GUI agent.

A GUI agent has a different workload from chat

A typical chat request has text input followed by generated text. A GUI agent may process a screenshot at every step, along with the task instruction and the history of previous actions. Its output, on the other hand, may be only a click, a keystroke, or a scroll action.

That changes what we should measure.

Decode tokens per second is not enough. We also need to look at prefill latency at realistic context lengths, end-to-end time per interaction, total task time, and task completion rate.

A small delay repeated across many steps can become a noticeable delay for the user.

One on-device baseline from our Mano-CUA testing

In one existing test, we ran Mano-CUA-Thinking-4B on a MacBook Pro M5 with 16GB of memory and evaluated it on 100 real macOS GUI tasks.

The recorded results were:

Task pass rate: 56%
Average inference time per step: 7.9 seconds
Average number of steps per task: 11.5 This is not a universal benchmark for every Mac or every GUI agent. It is a baseline from a specific device, model, and task set.

What it illustrates is that task-level evaluation matters. A model starting successfully does not mean the complete interaction loop is usable.

Desktop, laptop, or dedicated hardware?

We think these form factors should be evaluated against their intended use cases rather than ranked with one universal score.

Desktop machines can make sense for fixed workstations or workloads that need to run for long periods. Power and maintenance may be easier to manage, but display sessions, external peripherals, sleep settings, and remote administration still matter.

Laptops offer an integrated screen, keyboard, trackpad, and compute unit. They are convenient for individual use and development. Battery state, power profiles, and sustained thermal behavior can affect long-running workloads.

Dedicated devices may be useful when an agent needs to run as part of a fixed workflow. But a small form factor is not automatically an advantage. We still need to evaluate compute capacity, I/O, system updates, recovery, and the effort required to maintain the device.

For GUI agents, there is another practical detail: the desktop session itself matters. A locked screen, a sleeping machine, a changed display resolution, or an unavailable input device can interrupt the workflow even when model inference is working correctly.

What should a fair cross-device test include?

If we compare the same agent across a desktop, a laptop, and a dedicated device, we should keep the variables as consistent as possible:

Use the same model, runtime, and quantization configuration.
Run the same task set from the same initial UI state.
Define task success before running the test.
Repeat tasks and report both averages and failure cases.
Measure per-step latency and total task time.
Record memory pressure, power state, and sustained performance.
Separate model failures from UI execution and recovery failures. Without these controls, a device comparison can easily become a comparison of different software configurations or different tasks.

We also have separate inference measurements on M5 Pro. For a 4B vision-language model with a 4,516-token context, the W8A16 baseline recorded 2.839 seconds of prefill and 80.1 tokens/s decode. With Cider W8A8, prefill was 2.519 seconds and decode was 79.5 tokens/s.

Those measurements are useful for understanding runtime behavior, but they were collected under a different setup from the 100-task GUI evaluation. We should not combine them into one cross-device benchmark.

The question is not simply “Which device is fastest?”

For an on-device agent, the better question is: which hardware form factor can complete the target workflow reliably, at an acceptable interaction speed, with manageable deployment and maintenance costs?

That answer may be different for a developer's laptop, a fixed office workstation, and a dedicated device in a specific environment.

If you are running GUI agents locally, what do you optimize for first: task success rate, end-to-end latency, sustained performance, or ease of deployment? And what hardware are you using?

Context Gives Agents Direction. Skills Give Them the Ability to Act.

Mininglamp — Mon, 02 Nov 2026 07:38:47 +0000

A model can generate a good answer and still be a poor teammate.

The gap often appears after the first few tasks. An agent may know how to write, search, or summarize, but it does not yet understand the team's product boundaries, decision history, or working conventions. In a multi-agent workflow, that missing context can become a coordination problem: each role receives a task, but not necessarily the reasoning behind it.

We have been exploring this through two OCTO-related practices at our team: a continuous-learning workflow and a multi-agent software-fix workflow.
A practical starting point: the agent did not know the organization
In the early stage of one continuous-learning effort, the agent had little understanding of the organization and its products. People gradually supplied that background through ongoing conversations: strategic context from leadership, communication guidance from the PR team, and technical boundaries from product and engineering colleagues.

The internal case notes describe a progression: as the background accumulated, the agent became able to distinguish product positioning and take on more complete content tasks, such as preparing a speech outline.

The useful lesson is not that an agent simply “remembers more.” It is that relevant context changes how it interprets the next task.
Context and Skills solve different problems
The same practice also exposed a second gap. Understanding the business did not automatically give the agent the ability to perform every task.

Initially, its work was mostly text-based. The team later added capabilities such as search, presentation creation, and logic review.

We use this distinction:

Context gives the agent the background, goals, constraints, and team-specific knowledge needed to interpret a task.
Skills give it reusable methods and capabilities to carry out the task. Context without Skills can produce an agent that understands what is needed but lacks a reliable way to do it. Skills without Context can produce an agent that follows a procedure in the wrong situation. What this looks like in a real multi-agent workflow A separate engineering case from our team describes a bug-fix workflow.

A human started with a narrow request: verify whether a reported bug was real, and if so, fix it according to the team's process.

An AI product-manager agent analyzed the issue, planned the fix, selected a branch strategy, and assigned the work. A developer agent inspected the relevant files, made the change, and opened a PR. A reviewer agent found issues—including a case where a failed download could result in an error page being saved as a file—and sent the PR back. The developer agent updated the change; the reviewer checked it again. After review, a deployment agent packaged the change and deployed it to a test environment. The product-manager agent then prepared an acceptance checklist for a human to test.

This is a more useful picture of collaboration than “agents hand tasks to each other.” The workflow depends on shared project context, role-specific capabilities, and a feedback loop that allows a result to be rejected and corrected.

The case describes deployment to a test environment; it should not be read as a claim that the change was automatically released to production.
The hard part is governing shared experience
These practices also raise questions that are easy to overlook:

Which context should be shared across all agents, and which should stay role- or project-specific?
When is a repeated procedure stable enough to become a Skill?
How should outdated decisions or conflicting instructions be detected?
What evidence should we use to decide whether a Skill is actually improving task quality? More stored context is not automatically better. A shared mistake can spread just as easily as a useful convention.

For us, the goal is to turn relevant team experience into context that agents can interpret, skills they can reuse, and workflows where results can be reviewed. We are exploring these ideas in OCTO. Related open-source projects are collected at Mininglamp-OSS.

We Stopped Taking Meeting Notes — Here's What the Loop From Meeting to Delivered Work Actually Looks Like

Mininglamp — Fri, 30 Oct 2026 10:21:17 +0000

Two hours after a forty-minute review meeting ended, I opened OCTO and found the things we'd agreed on already sitting in the Loop as task briefs. One of them had a dev agent actively working on it.

Nobody took notes. Nobody wrote up action items. That's the part I want to unpack, because "meeting to task" sounds like a two-step thing and it really isn't.

The problem with meeting notes isn't the notes

We tracked open rates on our own meeting summaries. Three fates:

Someone reacts with a thumbs up, nobody opens it again.
Someone scans it, notices they got assigned three things, remembers one.
Rarely, someone actually does everything on it.
The third case is negligible. But the work still got done — just not by following the summary. Someone brought it up again, or one person happened to remember, or it got re-discussed next week and only then moved.

So the summary works fine as a record and fails completely as a driver. The notes were fine. The format was wrong for what we wanted the notes to do.

Why action items don't survive the handoff

Ask a person to "optimize the dashboard load time, next release" and they have enough to start. They know what the dashboard looks like, why it's slow, roughly when "next release" is, who wants it.

None of that is in the action item. It's in their head.

That's the whole problem. Humans fill gaps from context. Agents can't. An action item that's perfectly clear to a teammate is unusable input to an agent, because the agent doesn't know what to touch, what "done" means, or what it needs first.

We spent a while trying to make action items more detailed. Doesn't work. The concept of an action item is designed for a human reader.

What we actually built

The chain has six stages:

Capture — local real-time transcription during the meeting
Speaker separation — who said what, because tasks are owned by people
Topic segmentation — a 40-minute meeting is seven things, not one
Structuring — each thing becomes a task card
Dispatch — the card becomes a task brief in the Loop, routed to an agent
Execution and verification — the agent picks it up, works, self-verifies, delivers, a human accepts
Stages 1–3 are data movement. Stage 5–6 is plumbing. Stage 4 is where the whole thing lives or dies.

Stage 4 is the bottleneck

A task in natural language is spread across sentences. Someone says "this dashboard is slow," the tech lead says "no pagination," the PM says "next release." That's one task, and not a single sentence is a complete task description.

A brief that an agent can actually work from needs:

Goal. Optimize dashboard load time.

Constraints. Via pagination, next release. And "next release" has to resolve to a date, because agents don't understand fuzzy version numbers.

Acceptance criteria. The hard one. What counts as fast enough? If you don't pin it to something like "P95 first paint under 2 seconds," the agent finishes and you still can't tell whether it's done.

References. Which dashboard, where the logs are, whether there's prior work on this. None of that is in the meeting audio — it has to come from team context.

This is why a transcription tool can't solve it. Transcription solves recording. It doesn't solve understanding. The gap between the two is filled with your team's own context — your project structure, your stack, your definition of done.

Our rule: when in doubt, stop and ask rather than guess. An agent working toward a wrong acceptance criterion is worse than an agent that waited two minutes for clarification.

Why the task brief matters more than it looks

I think the task brief is the most underrated interface in human-agent collaboration.

Meeting summaries exist to move information between humans. Humans tolerate a lot of ambiguity — "optimize the load time next release" fills in about 70% automatically.

Agents tolerate none. No acceptance criteria and they don't know when to stop. No constraints and they pick the dumbest safe path. No references and they'll invent context.

So the field design of a task brief is really a definition of what an agent needs to know to do the job. Get it right and completion quality jumps. Get it vague and you get a pile of deliverables that look done and aren't.

The visibility part

One more thing, and it's why I noticed the tasks running two hours later.

Once a brief is in the Loop it isn't a black box. Who picked it up, what stage it's at, where it's stuck, when it'll land — all queryable state. Nobody has to schedule a follow-up meeting to find out whether the thing we agreed on is moving.

That sounds minor. It changed how our meetings feel. "Who owns this" used to be a question that got answered at the next meeting. Now it's a status field.

Where this actually stands

Honest version:

Working: capture, separation, segmentation, dispatch, execution visibility. We use these daily.

Still rough: structuring accuracy on complex tasks — the kind where a sentence has nested conditions and exceptions. Those often need a human to patch before dispatch. We're not pretending that step is solved.

Our call is that this is the right place to keep a human in the loop. Let the model handle the 90% of grunt work, keep a human on the 10% that's judgment. Chasing 100% automation gets you a pile of wrong tasks and nobody to blame.

If you're building something similar
Don't start with transcription accuracy. Start with "how do we define the acceptance criteria for a task." That's the part that decides whether the chain runs at all.

The project is open source — setup and the schema are in the repo README. Issues welcome.

Cider Quantization: Engineering Trade-offs in On-Device Inference

Mininglamp — Wed, 28 Oct 2026 04:15:35 +0000

Most conversations about on-device models start and end with one question: how much did quantization speed things up? That is the easiest question to answer and the least important. The trade-offs that decide whether a quantized agent is usable sit where no speed benchmark reaches. Here are the ones we hit building Cider, our on-device inference layer.

The speedup is smaller than the compression ratio suggests
Weight quantization feels dramatic. Take a model from FP16 to INT4 and the weights occupy roughly a quarter of the memory. That part is real.

Latency is different. A desktop agent runs a pipeline: capture the screen, encode the visual input, assemble context, decode the next action, parse it, execute it. The forward pass is one segment of that pipeline, and weight reads are one part of the forward pass.

On many edge chips, memory bandwidth and kernel scheduling are the harder constraints. If decoding is autoregressive and dominates wall-clock time, that cost does not shrink with model size. A model 4x smaller is rarely 4x faster, and sometimes barely faster at all.

When someone quotes a speedup, the useful follow-up is: prefill or decode, single turn or full episode? Those two framings differ by an order of magnitude.

The real risk is that behavior boundaries move
Speed is measurable. Boundaries are not. You find out by watching something fail.

Run the same GUI tasks on FP16 and INT4. On click, type, scroll, the two are indistinguishable; any gap sits in the noise. Then look at specific categories and the split appears:

Dense small-text interfaces. Quantization error amplifies in the visual features, and a checked box gets read as unchecked.
Toolbars with similar, tightly packed icons. Low precision conflates neighbors more often.
Multi-step decisions over long context. Each step is slightly off, and errors compound. Divergence at step five becomes a runaway by step ten.
These are the daily-use cases. They are underrepresented in standard benchmarks, so an aggregate score drops a point or two and still looks fine. In real use they are what people keep hitting.

Activations are the harder half
Weight quantization is comparatively mature: stable distributions, developed toolchains, static and analyzable error. Activation quantization is where it gets difficult.

Activations depend on input, so the distribution is dynamic, wide, and carries outliers. For a visual model, the spread across resolutions and interface densities is far larger than for text. Coarse activation quantization does not spread error evenly across tokens; it concentrates on the harder inputs. The situations needing judgment most are exactly where precision degrades most.

Our choice: keep activations more conservative than weights. Weights get pushed harder, activations keep headroom. The model ends up slightly larger than it could be, but the boundaries hold. There is no universal answer; it depends on how much your task fears edge cases.

The calibration set sets the ceiling
Algorithm choice matters less than most comparisons suggest. Calibration data matters more.

Calibration is what the quantizer uses to estimate activation distributions and fix parameters. Calibrate on generic text or natural images and the parameters lean toward those distributions. But an on-device agent sees desktop screenshots: windows, toolbars, input method boxes. Calibrate against the wrong distribution and the parameters are off from the start; no tuning recovers it.

We sample calibration data from real task traces: different resolutions, different layouts, light and dark themes. Small volume, but it covers the distribution we actually meet.

Evaluation has to change too
A generic text benchmark is driving with your eyes closed. It cannot measure accumulation across an episode, or precision loss on visual input.

Three layers: per-step accuracy, which localizes where precision was lost; multi-step completion rate, which captures accumulation (95 percent per step becomes roughly 60 percent over ten); and recall on critical interface elements, a small share of any aggregate score and the most visible to users.

A counterintuitive finding: the same quantization config varies more across tasks than different configs vary on the same tasks. Understanding your task distribution matters more than tuning parameters.

Closing
Quantization is not about shrinking numbers. The speedup is measurable, the boundary shift is not; weights are easy, activations are not; the algorithm is easy to pick, the calibration set is not. What makes a scheme production-ready is whether it holds the line on the tasks you fear most.

The full on-device agent pipeline is open source: https://github.com/Mininglamp-AI/Mano-P

After the Meeting Ends: How Audio Becomes Structured Work in Our System

Mininglamp — Mon, 26 Oct 2026 03:13:16 +0000

After the Meeting Ends: How Audio Becomes Structured Work in Our System

We spent a year building a pipeline that turns meeting audio into dispatched, tracked, and delivered tasks. Not transcript summaries. Actual structured work that gets executed and closed.

The Gap

Our team builds Octo, an agentic AI collaboration platform, and Octic, a hardware recording device for noisy meeting rooms. Octic worked great for capture and real-time transcription. People stopped taking notes. Transcripts were accurate. And then nothing changed. Action items still got lost. The same requests resurfaced two weeks later.

So we connected the recording device directly to task creation.

The Pipeline

Recording. Click to start on Octic. Real-time transcription runs alongside audio capture.

Requirement identification. The system scans transcripts and organizes requirements into structured cards, each carrying conversational context.

One-click write-in. Click a card. That requirement enters Octo Loop as a task with full context.

Task refinement. The Octo assistant turns vague asks into clear, executable, verifiable briefs and dispatches them to the right expert agent.

Visibility. Agent progress, handoffs, and milestones are all trackable.

Delivery. Agent finishes, results come back. One meeting line becomes a shipped feature.

What We Learned

The hardest part was the handoff between an identified requirement and an executable task. A line like we should look into dashboard caching needs serious context enrichment before any agent can act on it.

Visibility mattered more than speed. People trust the system when they can see every stage. We invested heavily in milestone tracking because black-box execution made everyone nervous.

The repo is at github.com/nicepkg/octo if you want to dig in.

Choosing an On-Device Inference Engine in 2026: It's Not Just llama.cpp Anymore

Mininglamp — Fri, 23 Oct 2026 06:26:51 +0000

Choosing an On-Device Inference Engine in 2026: It's Not Just llama.cpp Anymore

Running models locally used to mean one thing: llama.cpp, some GGUF quantization, done. Fine for text generation. But the moment you run a vision language model on device, or need fast prefill for long contexts, the engine choice matters way more than the model itself.

We building Cider, an INT8 activation quantization SDK on top of MLX. The problem we kept hitting: MLX does weight quantization well, W4A16 and W8A16, but leaves activations in full precision. For VLMs processing screenshots at 4000+ tokens of visual context, that prefill cost adds up fast.

What actually changed in 2026

Three things shifted the landscape this year.

First, Apple silicon got real INT8 support. The M5 generation added hardware paths that make W8A8 and W4A8 viable without software emulation. Before M5, you could do INT8 weights but activations still ran in fp16 on the matrix units.

Second, vision models went mainstream on device. GUI agents, document parsers, visual QA. These models have massive prefill requirements because image tokens dominate the context. A single screenshot can be 2000+ tokens. The old decode speed benchmarks everyone focused on just dont tell the full story anymore.

Third, quantization got more nuanced. Its not just about making the model smaller. W8A8 per channel quantization on M5 Pro gives you roughly 1.8x prefill speedup over W8A16 baselines. Thats not a rounding error, its the difference between a usable agent and one that feels broken.

Some real numbers

On M5 Pro with 64GB RAM and 307 GB/s memory bandwidth, running a 4B VLM with 4516 tokens of context:

W8A16 baseline: 2.839s prefill, 80.1 tok/s decode.
W8A8 with Cider: 2.519s prefill, 79.5 tok/s decode.

Decode speed stays about the same because thats memory bandwidth bound either way. But prefill drops by roughly 12.7%, and on heavier contexts the gap widens further.

Picking an engine in practice

If you are doing text only inference on Apple silicon, MLX with standard weight quantization is totally fine. llama.cpp with Metal backend works great too. No reason to overcomplicate it.

Once you add vision, or need to handle contexts above 4K tokens regularly, you want to look at engines that support activation quantization. Cider is one option, it works with any MLX model and you can check it out at https://github.com/Mininglamp-AI/Mano-P under the Cider repo. There are others emerging too, and the right choice depends on your target hardware generation.

The bigger point: the engine layer is no longer a solved problem. Model selection gets all the attention, but the inference stack underneath determines whether your 4B model actually feels responsive or just technically runs.

Vision-Only vs API-Based Desktop Agents: Same Task, Two Approaches, Different Results

Mininglamp — Wed, 21 Oct 2026 04:07:29 +0000

Most desktop automation tools work by hooking into system APIs, accessibility trees, or browser DOM. They parse HTML, call CDP endpoints, read element selectors. It works. But it also means every new app, every UI change, every platform quirk needs a new integration.

There is another way: skip all of that and just look at the screen.

What vision-only actually means
A vision-only GUI agent takes screenshots and decides what to click, type, or scroll based on pixels alone. No DOM parsing. No accessibility API. No system hooks. The model sees a screenshot, reasons about the task, and outputs mouse/keyboard actions.

This sounds inefficient at first. Why would you throw away structured data that APIs give you for free? The tradeoff becomes clear when you try to automate something across different apps.

Say you want to pull data from a desktop spreadsheet app, paste it into a web form, then confirm a dialog box. An API-based agent needs connectors for each piece: a spreadsheet API, a browser automation library, and OS-level dialog handling. A vision-only agent just... does it. Same way a human would. Look, click, type, move on.

Where each approach actually performs
API-based agents are faster when they work. Direct API calls skip the rendering layer entirely. No need to wait for screenshots, no pixel-level inference. For well-structured web apps with stable selectors, this is hard to beat.

Vision-only agents shine in messy environments. Legacy desktop software with no API. Custom enterprise tools. Anything where the UI is the only interface available. They also handle cross-application workflows without needing separate integrations per tool.

On benchmarks, the gap is narrowing. On OSWorld, which tests GUI task completion across real desktop environments, specialized vision-only models now score 58.2% on task success rate. That is the top score among specialized models. For reference, general-purpose cloud models with full API access score higher in absolute terms, but they also send every screenshot to a remote server.

The latency question
Vision-only agents run in a loop: screenshot, think, act, verify. Each cycle takes a few seconds. On a MacBook Pro M5 with a 4B parameter model running locally, each step takes about 8 seconds. A complex task might need 10+ steps, so you are looking at a couple minutes for something non-trivial.

API-based agents can often batch operations or skip the visual reasoning entirely. For a straightforward form fill, API wins on speed every time.

But for tasks that require visual judgment, like reading a chart, identifying a button by its icon rather than its label, or navigating a UI that changes layout dynamically, the vision agent does not need special handling. It just sees what is on screen.

Running both approaches on real tasks
We ran a 100-task test set on macOS covering common desktop operations: file management, web browsing, app interactions.

A cloud-backed vision agent hit 83% pass rate. A local 4B thinking model managed 56%. A cloud general-purpose VL model scored 39% on the same tasks. When the vision agent was allowed to also use bash commands alongside GUI interaction, it reached 90%.

The local 4B model beating a cloud VL model by 17 points is notable. A model small enough to run on a laptop with 4.3GB peak memory outperformed a much larger cloud model on real-world GUI tasks. The training methodology matters more than raw parameter count here.

When to pick which
Use API-based automation when you have reliable APIs, stable selectors, and speed matters. Web scraping, CI/CD pipelines, repetitive form submissions.

Use vision-only when APIs do not exist, when you are crossing application boundaries, or when data privacy requires everything to stay on-device. No screenshots leave the machine, no task descriptions get sent to any server.

Most real workflows will probably use a hybrid. Vision for the parts that resist API integration, API calls for the parts that are well-structured.

Try it yourself
If you want to experiment with vision-only desktop automation, Mano-P is an open source GUI agent that runs locally on Apple Silicon. 4B model, works on M4+ Macs, Apache 2.0 license.

Install the CLI: brew tap Mininglamp-AI/tap && brew install mano-cua

Run a task: mano-cua run "open Safari and search for OSWorld leaderboard" --local

The model is on HuggingFace: Mininglamp-2718/Mano-CUA-4B-Thinking-1.1

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

If you end up trying it, a star on the repo helps the project stay visible.

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