Mininglamp-OSS

How do you help agents learn your team's conventions over time? We've been looking at a practical problem in multi-agent systems: an agent can be capable at individual tasks and still not understand how a team works. In one of our team's continuous-learning efforts started with an agent that had very little knowledge of the organization or its products. That knowledge was built gradually through day-to-day collaboration: leadership discussions added strategic background, the PR team provided communication guidance, and product/engineering colleagues explained technical boundaries. The internal notes describe the agent becoming better at distinguishing product positioning and taking on more complete content tasks as that context accumulated. That made us separate two things that are easy to mix together: Context: what the agent needs to understand For us, this includes team goals, product boundaries, prior decisions, working conventions, and feedback. It can come from people, but it can also come from other agents. The same learning effort included agents sharing things like brand standards and review experience. Skills: how the agent can carry out work Understanding the team's context did not automatically make the agent good at every task. It initially focused mostly on text. The team later added capabilities such as search, slide creation, and logic review. So the shorthand is: - Context helps answer: “What is going on here, and what should I take into account?” - Skills help answer: “What procedure or capability can I use to get this done?” A second example from our engineering work made the distinction more concrete. A human asked the system to verify a bug and fix it if confirmed. An AI product-manager agent analyzed and assigned the task; a developer agent fixed the code and opened a PR; a reviewer agent found issues and sent it back; the developer updated the PR; the reviewer checked again; then a deployment agent packaged the change to a test environment. The product-manager agent prepared an acceptance checklist for a human to test. What mattered was not just the handoff. The review agent could reject the first result, and the developer had to revise it. Shared project context helped the roles coordinate; role-specific skills let them do their parts; feedback kept the workflow from treating the first generated result as finished. We're still interested in the boundaries: - Do you keep team memory separate from task-specific context? - How do you decide when a repeated workflow deserves to become a skill? - How do you stop stale or incorrect knowledge from spreading between agents? - Do you have a review step for shared agent memory, or is it mostly implicit? We're exploring these questions in OCTO; the related open-source work is at Mininglamp-OSS. Curious how other teams are handling this in practice.

Why Shared Organizational Memory Matters More Than Prompt Chaining in Agent Teams 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: github.com/Mininglamp-OSS

Shared organizational memory for agent teams turned out to be the missing piece

Multi-Agent Bug Fix Pipeline: Architecture of Role Separation

One human sentence kicked off a full agent-driven bug fix So we've been running this internally at Mininglamp Technology. Four AI agents in a group chat, each with a specific role: product manager, developer, reviewer, deployer. They share the same project context. When a bug comes in, they coordinate the full cycle. Here's a recent run. A download method was failing under certain conditions, silently losing the filename. The human typed one sentence: 'Confirm whether this bug is real. If so, fix it per the process.' Then stepped away. The PM agent read the codebase, found the root cause, identified which files were affected, planned the fix, specified the branch strategy, and assigned it to the developer agent. No one pasted a Jira link. No one explained the codebase. The context was already there because all agents operate in the same workspace. Developer confirmed both files had the issue. Spun up Claude Code, fixed the code, created a PR. Took minutes. The reviewer didn't just approve it. It found two real problems. One of them: if the file download fails, the code would save an error page as the actual file. Silent data corruption. Sent it back. Developer fixed both, updated the PR. Reviewer went through everything again item by item. All passed. Deployer packaged and deployed to test. PM generated an acceptance checklist and pinged the human to click-test. Done. What makes this different from a single agent coding tool The temptation is to compare this to Claude Code or Cursor or Copilot doing a fix. But those tools require a human to be the orchestrator. You feed context, review output, decide next steps, run the deploy yourself. Here the agents self-organize. With tools like Claude Code, someone has to feed in the context each time. In this setup, a group of agents share the same organizational context and coordinate without a human in the middle. The role separation matters more than you'd think. The reviewer agent has no incentive to approve fast. Its only job is to find problems. In our run it caught a real bug that would have shipped. That's not something you get from a single agent doing generate-then-self-review. The handoff protocol Each agent knows when its work is done and who gets it next. PM to dev, dev to reviewer, reviewer back to dev if there are issues or forward to deployer if it passes. It's a pipeline with actual quality gates. This runs on OCTO, which is our workspace for human-AI collaboration. The relevant concepts: - A Loop is a work unit with an owner, deliverables, and acceptance criteria. One bug fix equals one Loop. - There are six orchestration modes (Solo, Roundtable, Critic, Pipeline, Split, Swarm) that define how context flows between agents. This bug fix used Pipeline. - Preference: every time a human accepts or rejects a deliverable, that becomes experience the agent references next time. What's still hard Agents misinterpret ambiguous requirements. The 'fix it per the process' instruction worked because the process was documented in the shared context. Vague processes mean more clarification rounds. Calibrating reviewer strictness is a tuning problem. Too strict, nothing ships. Too lenient, you're rubber-stamping. Debugging across agents is harder than debugging one agent. When step 3 fails, you trace through step 1 and 2 context to understand why. So what did the human do Raised the problem. Accepted the result. That was the human's contribution to this bug fix. This isn't a demo. It's our internal workflow on real production code. The full chain from one sentence to deployed fix took minutes. The reviewer caught actual bugs. Deploy happened without manual intervention. If you're building multi-agent systems, I think the key thing is: role boundaries and handoff contracts matter more than making a single agent smarter. That's where we've been getting the most value. Happy to answer questions about the architecture or share more details on the orchestration modes.Project: github.com/Mininglamp-OSS

Our agents keep learning from each other, not just from us Been running a set of agents in a shared workspace for a few months now and the thing that surprised me most is not how much they learn from us. It is how much they learn from each other. Context first since it matters for the rest. We use OCTO, an open source workplace we build for humans and agents. Agents live in the same channels as people, so the project background and the history of decisions are just sitting there in the conversation. Nobody writes a briefing doc. Early on we assumed the useful learning would come from the humans. Someone corrects an output, the agent adjusts, done. That part works. But the correction only lands on the agent that got corrected. If a second agent makes the same mistake a week later, it makes the same mistake a week later. What changed things was when agents started correcting each other. The one that handles design review will flag another agent's writeup for not matching the brand voice. The one doing logic review will point out a gap in someone else's argument. There is no mentorship setup. They are just working in the same channels and the standards travel. Two things make this different from how it works with people. It is basically free, since one agent explaining a standard to ten others costs the same as explaining it to one. And it runs in parallel, there is no constraint on how many can be in the room. The part I am still not comfortable with is that bad lessons spread the same way. Humans push back when a senior person says something that sounds off. Agents do not have that instinct. A wrong call from one agent gets picked up as fact by another and after a couple hops it looks like a shared assumption. We put human review on the gate for anything entering the reusable experience store, which slows things down but stops the quiet version of this problem. Second thing I did not expect: individual habits converge into team wide knowledge without anyone planning it. One agent picks up a preference, and over time it shows up in how the others behave. More agents in the space, denser the knowledge gets. Still working out how much of this to automate. Curious whether anyone else running multiple agents in one workspace has seen the same convergence or if it is an artifact of how we set things up. The whole thing is the architecture of OCTO, the workspace we run, and it is open, Apache 2.0, the Go backend and the React client both on the Mininglamp-OSS org if anyone wants to dig into how the experience store and the review gate actually work. A star is nice if it turns out to be useful to you. github.com/Mininglamp-OSS

Day 1 to Day 49: What One Agent Actually Learned 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: 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: Mininglamp-AI/Mano-P ---