Coder Legion - Recent posts tagged multi-agent

The Lie Outlives the Liar: Why Removing the Bad Agent Is Already Too Late

Wed, 30 Sep 2026 09:18:57 +0000

Originally published at vibeagentmaking.com.

They deleted the deceiver from the conversation. The false belief stayed, carried by agents that never lied.

In August 2026, nine researchers published the cleanest version yet of an experiment every multi-agent developer eventually runs by accident. They built 120 small worlds. In each one, an object moves, and five agents each hold a partial observation; only jointly do the observations determine where the object ends up. The agents talk, share testimony, vote. When all five are honest, the collective recovers the true endpoint in 87 of the 120 environments. Then the researchers took the agent holding a key piece of evidence and instructed it to lie.

Truth recovery fell to 17 of 120.

The paper is "When Truth Is Distributed: Misinformation Derails Collective Fact Recovery in LLM-Based Multi-Agent Systems" (arXiv:2608.03421, version 3, 13 August 2026, Yan, Yue, Zhao and six coauthors, under a framework they call ForesightSafety-TIDE). The headline numbers in the abstract are 72.50 percent and 14.17 percent, and they resolve exactly to those counts against the stated 120 environments, which is worth doing because the counts carry the denominator the percentages hide. One deceiver among five agents, positioned on the right evidence, erased about four fifths of the collective's ability to find the truth: 17 against the honest baseline's 87 means roughly a fifth of the capability survived.

But the collapse is not the finding. Collapses are cheap; everyone who has chained agents knows a bad input degrades output. The finding is what happened when the researchers did the thing you would do about it.

The instinctive fix, tested

Your pipeline has a bad agent. You have logs. You find it. You remove it. The paper measured whether that solves the problem.

The paper's process tracing follows individual claims through the conversation, and its abstract compresses the result into one devastating sentence: a single false testimony "is adopted more readily than truthful testimony, propagates to higher orders, and persists through honest agents after the deceiver exits."

Read that clause by clause, because each one closes an escape route.

Adopted more readily than truthful testimony: the lie does not merely compete with the truth, it outperforms it at the moment of uptake. This matches a result from elsewhere in the 2026 literature whose title alone states the asymmetry: "Easier to Mislead Than to Correct" (arXiv:2606.01637). A false claim, delivered confidently by an agent that plausibly holds the relevant evidence, is a well-formed, coherent input. Honest testimony from an agent with a partial view is often hedged and incomplete. The polished thing wins adoption.

Propagates to higher orders: the honest agents do not just repeat the lie, they build on it. Agent B accepts the false observation and derives a conclusion; agent C accepts B's conclusion and derives another. By the second and third hop, the falsehood no longer looks like testimony from the deceiver. It looks like the collective's own reasoning, because it is. The lie has stopped being a message and become ancestry.

Persists through honest agents after the deceiver exits: and there is the punchline. The researchers ran exit ablations, removing the deceiver from the conversation. The false belief stayed, carried entirely by agents that never lied, each honestly reporting conclusions whose corrupted lineage is invisible to them. Removing the bad agent removes the author of the lie. It does not remove the lie, because the lie's ownership has already transferred to the honest majority.

The paper tested the other instinctive fix too: add a reviewer. The abstract reports that "observers without first-hand evidence suppress incorrect consensus but do not improve truth recovery." That distinction deserves a moment, because those two things feel identical from the outside. A skeptical overseer bolted onto the pipeline can notice that the consensus smells wrong and block it, so the system stops confidently asserting the false endpoint. But the overseer holds no observation of its own, so it cannot supply the true one. You have converted a system that is wrong into a system that is stuck. In production terms: the reviewer turns a silent data-corruption incident into an outage. That is genuinely better, and it is nothing like a fix.

Humans got this result thirty-two years earlier

Here is where the paper stops being a curiosity about LLMs and becomes something older and heavier. Cognitive psychology has a name for exactly this shape: the continued influence effect. The origin paper is Johnson and Seifert, 1994, "Sources of the continued influence effect: When misinformation in memory affects later inferences," and the finding, replicated across three decades and reviewed at length by Lewandowsky and colleagues in 2012, is that misinformation keeps shaping people's inferences after they have received, understood, and can even recall the correction. The review literature's framing is blunt about how ineffective retraction is at updating memory, and that attempted corrections can even backfire.

Set the two literatures side by side and the rows line up almost embarrassingly well. In the human studies, the correction is a retraction: the false report is formally withdrawn. In the agent experiment, the correction is stronger, the liar is deleted from the world. What survives in humans is a web of inferences built on the false fact while it was believed; what survives in agents is falsehood carried by honest teammates who built on it. And what the corrector achieves in humans is a reduction in reliance without elimination, while in agents the observer suppresses the wrong consensus without restoring the right answer.

Suppression without restoration, in both species.

I think that parallel, which the agent paper does not draw, is the most useful way to read it. The result is not a surprising new fact about language models. It is evidence that a known, robust property of belief revision, one that shows up in undergraduates reading stories about a warehouse fire, survives being implemented in software. Which means you should not expect to prompt your way out of it, any more than the psychologists corrected their way out of it. The effect is not a bug in the believer. It is a consequence of building inferences on claims, and then keeping the inferences when the claim falls.

The paper that says the opposite, and why it doesn't

Honesty requires a complication: the 2026 literature is not unanimous, and one paper stakes the opposing title. "You Can't Fool Us: Understanding the Resilience of LLM-driven Agent Communities to Misinformation" (arXiv:2605.17353, May 2026) reports agent communities that resist and recover.

Read its abstract next to TIDE's and the contradiction dissolves into a design variable. The resilience paper studies communities distinguished by disposition: agents varied along actively open-minded thinking and political ideology, hit with "credible misinformation shocks," with resilience emerging as a dynamic of questioning, correction, and withdrawn support; open-minded communities resist uptake and recover better. And nothing in that setup gives the misinformer a monopoly on evidence. The false claim competes in an open market, where other agents can doubt it, check it, and talk each other down.

TIDE's deceiver is not a voice in a crowd. It is the sole holder of a piece of evidence jointly necessary for the answer. The lie arrives over the only wire that carries that fact, so no amount of open-mindedness elsewhere in the network can route around it; the other agents' observations cannot contradict a claim about evidence only the liar holds.

Put as a design sentence: resilience to misinformation is a property of topology first and disposition second, and the dangerous case is the one where the liar is load-bearing. That is worth writing on the whiteboard, because most real agent pipelines are built almost entirely out of load-bearing witnesses. Usually the retrieval agent alone read the document. The browsing agent alone saw the page. The tool-calling agent alone observed the API response. We assemble chains of sole-evidence-holders and then reassure ourselves with review stages staffed by agents who, in the paper's phrase, are observers without first-hand evidence. TIDE is not an exotic adversarial setup. It is an org chart of a normal agent system, with one node's honesty bit flipped.

The fix has a name, and it is not "removal"

What actually survives this result is not detection alone: by the time your deceiver-detector fires, the false claim has descendants, and deleting the author does nothing to the descendants. The intervention has to act earlier, at the moment claims enter the system, by recording where every claim came from, so that when a source is discredited you can find and revoke everything downstream of it.

I want to be careful here, because the temptation is to present that as this essay's clever proposal, and it is not. The architecture already exists in the literature with names and dates. "MemLineage: Lineage-Guided Enforcement for LLM Agent Memory" (arXiv:2605.14421, May 2026) attaches provenance to every agent memory entry, tracks per-derivation lineage, and refuses actions whose justifying context has a tainted chain: discredit the source and the taint propagates to every descendant automatically, which is precisely the recall that agent-removal fails to perform. "From Fluent to Verifiable: Claim-Level Auditability for Deep Research Agents" (arXiv:2602.13855, February 2026) does the sibling work at the level of individual claims. By June 2026 there was a survey of evidence tracing and execution provenance in LLM agents (arXiv:2606.04990), and a field young enough that its papers fit in one tab does not get surveyed; provenance for agent claims is established practice waiting for adoption, not research waiting for validation.

What the TIDE result supplies is the argument for why that machinery is not optional hygiene. Without provenance, the only levers you have are the two the paper tested, removal and review, and the paper's contribution is a controlled demonstration that one acts too late and the other only stalls. With provenance, discrediting a source becomes an operation on data rather than on personnel: you do not fire the witness, you recall every conclusion that cited them.

What to do on Monday

If you build or run multi-agent systems, four things follow directly from the two corpora above.

First, tag claims with their evidential source at the moment of assertion, even crudely. A source: field on every claim passed between agents, naming the observation or tool call it rests on, is a weekend of work and it converts "we removed the bad agent" from a hope into a query: select every surviving claim descending from its testimony, and re-derive those. If you cannot run that query, you do not have an incident response for agent deception; you have a superstition about it.

Second, when you map your pipeline, mark the sole witnesses. Anywhere one agent is the only holder of some evidence, you are in TIDE's topology, not in the resilient open-market topology, and dispositional fixes (better prompts, more skeptical agents, an extra reviewer) are the wrong tool class. Either add an independent evidence path or add lineage enforcement at that node.

Third, keep the reviewer, but file it honestly: a reviewer without first-hand evidence is a brake, not a steering wheel. Suppressing a wrong consensus is real value; just never let a green light from such a reviewer be recorded as verification.

Fourth, budget asymmetrically. It is easier to mislead than to correct, in machines as in people, so a dollar spent preventing false claims from entering untagged is worth more than several spent on cleanup, because the cleanup, as 120 small worlds and thirty-two years of psychology jointly attest, does not actually clean.

The deceiver in those experiments spoke once per round, held one piece of evidence, and was eventually removed. The lie stayed on, doing its work through agents of perfect integrity. That is the finding to keep: in a system that builds on testimony, integrity is not a property of agents. It is a property of lineage, and you either record lineage when claims are born or you discover, at exactly the wrong moment, that the liar was the least important part of the lie.

Reproduction and honesty notes: the count reconstruction (87 of 120, 17 of 120, and the roughly-one-fifth survival ratio 17/87) derives the counts from the abstract's percentages against the paper's stated 120 environments and shows the fit is exact. All quoted TIDE language is from the arXiv:2608.03421v3 abstract; the paper's body was not relied on. The continued-influence-effect literature is characterized qualitatively because its familiar quantitative figures circulate secondhand and the primary papers were not opened for this essay. The resilience paper (arXiv:2605.17353) is characterized only as far as its own abstract, fetched 29 August 2026.

Sources

Yan, C., Yue, Z., Zhao, F., Lin, E., Jia, L., Tong, H., Lyu, M., Sun, C., & Zeng, Y., "When Truth Is Distributed: Misinformation Derails Collective Fact Recovery in LLM-Based Multi-Agent Systems," arXiv:2608.03421v3, 13 August 2026. arxiv.org
Ouyang, C., & Hou, R., "MemLineage: Lineage-Guided Enforcement for LLM Agent Memory," arXiv:2605.14421, May 2026. arxiv.org
Rasheed, R. A., Banerjee, S., Mukherjee, A., & Hazra, R., "From Fluent to Verifiable: Claim-Level Auditability for Deep Research Agents," arXiv:2602.13855, February 2026. arxiv.org
Wang, Y., Zhang, J., Cai, T., et al., "From Agent Traces to Trust: A Survey of Evidence Tracing and Execution Provenance in LLM Agents," arXiv:2606.04990, June 2026 (cited as a survey). arxiv.org
Lin, C., Jin, Y., Hu, K., et al., "You Can't Fool Us: Understanding the Resilience of LLM-driven Agent Communities to Misinformation," arXiv:2605.17353, May 2026. arxiv.org
Qu, J., Fu, L., & Hu, Y., "Easier to Mislead Than to Correct: Harmful and Beneficial Revision in LLM Conformity," arXiv:2606.01637. arxiv.org
Johnson, H. M., & Seifert, C. M. (1994), "Sources of the continued influence effect: When misinformation in memory affects later inferences," Journal of Experimental Psychology: Learning, Memory, and Cognition (origin of the continued influence effect; cited here via reviews).
Lewandowsky, S., Ecker, U. K. H., Seifert, C. M., Schwarz, N., & Cook, J. (2012), "Misinformation and Its Correction: Continued Influence and Successful Debiasing," Psychological Science in the Public Interest, 13(3). journals.sagepub.com

Group Chat Orchestration: What AutoGen Got Right About Multi-Agent Design

Sun, 30 Aug 2026 23:58:54 +0000

Most of us here have shipped something on an agent framework in the last year, and a fair number of those frameworks have already changed names or maintainers. This is a look at the parts of Microsoft's AutoGen that were worth keeping, written for anyone picking a stack this month rather than defending one they already chose.

AutoGen came out of Microsoft Research in August 2023 and picked up more than 54,000 GitHub stars by early 2026. In October 2025 it entered maintenance mode, its team merged with the Semantic Kernel team to build the unified Microsoft Agent Framework. Critical bug fixes and security patches still land, new features do not. That makes this a good moment to separate the package from the ideas, because the ideas moved into the successor intact.

Conversation History As Shared State

Every component in AutoGen is an agent that sends and receives messages. The base class, ConversableAgent, gives each agent a name, a system message that defines its behavior, and configurable capabilities for inference, code execution and human input.

The decision that matters is what plays the role of shared state. In AutoGen it is the conversation history itself. There is no separate workflow database tracking which step finished and what it produced, because the transcript is the record.

That buys you a lot. Any agent can read what happened before it, debugging is reading a log you already have, and adding an agent does not mean adding a schema. It also costs something real, which is that the transcript grows and every agent pays for it in context. The teams who get this right keep the shared history small and structured on purpose instead of letting it accumulate.

Deciding Who Speaks Next

AutoGen scales from a two agent back and forth to a group chat where a manager agent picks the next speaker based on context, and you can supply a custom function that routes by your own rules instead.

This is the part people underestimate. Speaker selection is not a detail sitting on top of a multi-agent system, it is the system. Ask a model to choose the next speaker and you have added an inference call, a failure mode, and a source of nondeterminism to every single hop. Route by rule wherever the rule is knowable, and save model driven selection for the hops that genuinely need judgment.

Per-Agent Model Assignment

Each agent in an AutoGen system can use a different model. Put an expensive frontier model on the one step that has to reason and a small cheap model on routing, formatting and summarizing, and the economics of the whole system move further than any prompt tweak will manage.

The inference layer underneath handled caching, rate limiting, cost tracking and automatic fallback across providers, so one provider outage did not take the run down with it. If you are evaluating a replacement, that list makes a better checklist than any feature matrix. The full architecture writeup, including tool calling, deployment, framework comparisons and the migration path, is at Auto Learning Agents if you want the long version.

The Execution Boundary

An AssistantAgent reasons and writes code. A UserProxyAgent executes that code in a sandbox and relays human input, and you configure whether it approves every action, approves some of them, or runs fully autonomously.

Splitting the thing that writes code from the thing that runs it is what makes an agent system safe to operate. It gives you exactly one place to put the approval gate and one place to put the sandbox, instead of scattering both through your agent definitions.

What To Carry Forward

If you run AutoGen in production today, nothing broke this morning, so plan the migration on your own schedule rather than in a hurry. If you are starting fresh, start on the Agent Framework and read AutoGen as documentation of why the design is shaped the way it is.

Either way the durable skill is the patterns and not the imports. Group chat orchestration, a real execution boundary, and per-agent model assignment are going to outlive several more framework names.

The Wood Wide Web of AI

Mon, 18 May 2026 18:48:26 +0000

Half of what science claims about fungal networks is wrong. The corrected version is a better blueprint for multi-agent AI than the fairy tale ever was.

The Fairy Tale and Its Cracks

The popular narrative describes a forest-floor fungal internet where mother trees share nutrients with struggling seedlings. This story owes much to Suzanne Simard's 1997 Nature study showing Douglas fir trees transferring carbon through ectomycorrhizal fungal networks.

A critical correction emerged in February 2023. Justine Karst and colleagues reviewed 1,676 scientific citations about common mycorrhizal networks: 25% of citing papers misrepresented structure. 50% got something wrong about function. Unsupported claims had doubled over 25 years.

What the Fungal Network Actually Does

Fungi are paid intermediaries, not altruistic connectors. Mycorrhizal fungi receive up to one-third of a host tree's sugar production in exchange for delivering water and nutrients. This is transactional, not charitable.

Transfer rates are wildly variable. Carbon transfer ranges from 0 to 10% of receiver plant carbon uptake. Nitrogen transfer varies even more: 0-72% under field conditions.

Kin recognition is real. Mother trees transmit more carbon to genetically related seedlings than to strangers -- preferential routing based on identity.

The network enables parasitism. Mycoheterotropic plants extract carbon without contributing any. The same infrastructure enabling cooperation enables freeloading.

The Parallels That Survive Scrutiny

Hub trees and coordinator agents. The biggest, oldest trees are the most highly connected nodes, routing the most resources rather than producing the most. Multi-agent architectures feature similar coordinator nodes.

Paid intermediaries and infrastructure costs. The one-third sugar tax represents network participation costs. In agent systems, equivalent costs manifest in tokens, latency, and context windows.

Trust-based routing. Mother trees route resources preferentially based on genetic identity. Agent systems employ similar patterns: agents with proven competence receive richer context and harder tasks.

Warning signals and error propagation. When Douglas firs face insect attacks, they transmit chemical signals through mycorrhizal networks, triggering preemptive defense in neighbors. Agent systems employ parallel mechanisms.

The Meta-Parallel

Karst's most significant finding concerned scientists themselves. 50% of peer-reviewed papers misrepresented mycorrhizal network function. The romanticized narrative replicated faster than evidence supported it.

The multi-agent AI field exhibits identical patterns. Demonstrations show extraordinary capabilities. Production reality proves messier. Agents hallucinate. Context windows overflow. Coordination overhead consumes parallelism gains.

What Builders Can Steal from Fungi

One: Trust routing beats broadcast. Proven reliable agents should receive priority on similar tasks.

Two: Price your infrastructure. Track token cost and latency for every inter-agent handoff.

Three: Prune without guilt. Employ hibernation for underperforming agents.

Four: Design for parasites. Build monitoring detecting agents taking more than they contribute.

Five: Protect your hubs. Protect hub nodes through redundancy and graceful degradation.

Originally published at vibeagentmaking.com

The Real Weakness of AI Missiles Is Surprisingly Boring

Thu, 14 May 2026 22:00:50 +0000

Everyone talks about LRASM as if it were an unstoppable "AI missile." The truth is much less cinematic, and honestly, much more interesting.

I recently returned to reading about defense technology and got pulled into the discussions around LRASM and autonomous swarm coordination. At first, I was impressed by the engineering: multiple missiles sharing information, coordinating decisions, surviving under jamming, and operating with incomplete data. It looked like the future of warfare in a single weapon.

Then a very simple question stopped me.
What happens if some members of the swarm are wrong? Or worse, what if they lie?

Information sharing is the core strength of these systems, but the moment I thought about it carefully, it also looked like their biggest weakness. My background in swarm algorithms is modest, but I know enough to understand that distributed systems become genuinely dangerous when trust itself becomes uncertain. So I kept digging, expecting to find some exotic new field of military AI research.

Instead, I found a paper from decades ago: "Reaching Agreement in the Presence of Faults" by Leslie Lamport and colleagues, the foundation of Byzantine Fault Tolerance. And suddenly everything connected. The same mathematical problem that haunts distributed databases, blockchain systems, and multi-agent AI is sitting quietly inside modern autonomous military systems. How do independent agents agree on reality when communication is noisy, data is incomplete, some nodes are compromised, and deception is intentional? That is not a missile problem. That is a 1980s computer science problem wearing a uniform.

This reframes the whole conversation around LRASM. Modern warfare is no longer just about speed, range, or explosives. It has become a war of uncertainty, deception, and information quality. Systems like LRASM are designed to survive GPS denial, electronic warfare, incomplete data, and adversarial environments, which is impressive. But the same design choice that lets them survive, namely shared information with high trust priority, also turns the swarm into an attack surface. Poisoned data, false targets, or manipulated consensus could mislead the entire formation. This is not science fiction; it is a known and unsolved problem across distributed systems, adversarial AI, multi-agent coordination, and Byzantine fault tolerance.

Sensor deception makes the picture worse. Thermal imaging, passive RF sensing, and AI-based target recognition sound flawless in presentations, but real battlefields are noisy, low-resolution, deceptive, and incomplete. A decoy, a false thermal signature, or an adversarial visual pattern can quietly push the system toward the wrong decision, with full confidence. And then there is the economics. Asymmetric warfare turns this into something almost absurd: a multi-million-dollar autonomous missile may end up fighting hundreds of low-cost distributed jammers and decoys, designed not to defeat it but to confuse it.

What fascinates me most is that modern warfare increasingly looks less like a battle of machines and more like a battle of perception, trust, and uncertainty. The future battlefield may not belong to the side with the smartest missile. It may belong to the side that creates the most confusion inside the enemy's decision model first.

Modern war is quietly becoming AI versus AI, deception versus perception, probability versus certainty. And the deepest vulnerability of the most advanced weapon in the room may turn out to be a problem we already named forty years ago.

The Sovereign Machine: Chasing the Holy Grail of Private Intelligence

Sun, 26 Apr 2026 23:29:46 +0000

We are living in an era of borrowed thought.

Every time we ask a question, draft a document, or analyze a dataset, we send our cognitive context through a wire to a server farm we will never see. In the pursuit of convenience, we have accepted a strange compromise: to gain intelligence, we must surrender privacy. But what if we rejected the premise entirely? What if the intelligence never belonged to the machine in the first place?

This is the story of a rebel research vector. It’s a journey that started with INTENTIO, evolved through ARKHEIN, and is now culminating in an upcoming, unreleased project called ANDARTIS—a local-first framework designed to prove that the Holy Grail of Private AI isn't just possible; it can run natively on the laptop sitting on your desk.

The Genesis: INTENTIO and the Human-Led Cognitive Space

The research began with a disruptive realization: Local operation alone doesn’t create intelligence. And an AI is not an oracle.

INTENTIO was our first major experiment. Built 100% in PHP and powered locally by Ollama, INTENTIO completely rejected the idea that we should ask the machine to be "intelligent." Instead, it shifted the responsibility for intelligence back to the human. The machine was simply a tool for executing cognitive design, not simulating it.

As we put it: "Intelligence isn’t in the machine. It’s in the human’s crafting of the cognitive space."

In INTENTIO, you didn't just dump files into a void and hope the AI figured it out. You organized knowledge into explicit packages (like a "Cartoon Universe" for consistent visual output). You defined prompts with strict YAML frontmatter that set absolute cognitive rules and boundaries. Protecting privacy, returning data ownership, and running locally weren’t just features—they were the foundation for a human-led cognitive architecture. The AI simply responded within the boundaries the user designed, never exceeding them.

The Crucible: ARKHEIN and the 7-Level Cognitive Pipeline

If INTENTIO proved that structure creates intelligence, ARKHEIN scaled that philosophy into a robust, hierarchical application.

ARKHEIN was built as a NativePHP desktop application, bringing the concept of a true Cognitive Architecture to local files. We introduced the 7-Level Sovereign Pipeline—a formal reasoning framework that mirrored deep cognitive processes:

Perception & Canopy Discovery: The system wouldn't just search blindly; it used high-level folder summaries to identify relevant "silos" before diving deep.
Decomposition & Scratchpad: It broke complex intents into multi-phase plans and reasoned within durable, on-disk workspaces.
Self-Critique: An automated hallucination audit verified accuracy before final generation.

Supported by a custom pure-PHP vector index and a SQLite Single Source of Truth (SSOT), ARKHEIN proved that Hierarchical RAG (Retrieval-Augmented Generation) and self-healing cognitive loops could run securely within user-authorized folders on Apple Silicon.

But as powerful as ARKHEIN's architecture was, relying purely on PHP orchestration and external Ollama dependencies created a ceiling for latency and deep autonomous tool execution. We needed the speed of native silicon.

The Synthesis: Anticipating ANDARTIS

This brings us to ANDARTIS.

ANDARTIS, currently in active development, is the synthesis of INTENTIO's human-led schemas and ARKHEIN's deep cognitive pipelines, fused into an elegant, blazing-fast architecture. We are abandoning the latency of cold-booting scripts and the HTTP overhead of local third-party APIs (like Ollama). Instead, ANDARTIS introduces the Resident Daemon.

The Architecture of Rebellion

At its core, ANDARTIS orchestrates a hybrid intelligence ecosystem natively on Apple MLX:

The Orchestrator: A beautifully designed Laravel/NativePHP desktop application shell that manages your "Intelligence Nodes" with zero cloud bloat.
The Hybrid Librarian: It respects the INTENTIO philosophy of "structure is intelligence." It uses an Elite Symbolic Engine (lightning-fast regex) to instantly extract structured Markdown tables based on the user's defined Schema, while dynamically waking up an SLM to infer missing metadata from chaotic paragraphs.

The Resident Daemon: ANDARTIS spins up a detached, long-running FastAPI daemon that holds highly quantized (4-bit) SLMs—like Mistral—directly in the VRAM of a standard Mac.

When you ask ANDARTIS a question, the Resident SLM will act as an autonomous agent. It will hold a conversation while invisibly triggering local symbolic tools (like our EntityAnalytic brain) to count, aggregate, and search your SQLite Knowledge Core in milliseconds.

Democratizing the Holy Grail

The true disruption of ANDARTIS isn't just algorithmic; it's hardware democratization.

By leveraging Apple's MLX framework, we are running complex, multi-agent AI orchestration on consumer laptops. This isn't just for developers. This is for the independent doctor analyzing medical records to spot hidden health trends. It's for the psychologist managing patient archives containing all types of media—even raw audio sessions—that can be safely ingested offline. It’s for the fortress lawyer mapping connections across 50,000 pages of discovery without violating client privilege. It’s for the investigative journalist who cannot risk a data leak.

Yes, processing massive, complex archives means a longer initial ingestion phase—but the trade-off is worth it. Once the Librarian finishes its heavy lifting, the resulting interaction is a blazing-fast, instantaneous conversation with your own private Knowledge Core.

While ANDARTIS is not yet publicly available, the architecture is already proving that privacy and cutting-edge artificial intelligence do not have to be mutually exclusive. The intelligence belongs to you. The data stays with you.

We are not building a god-model in the cloud. We are building a sovereign machine for your desk.

The research continues. The forge is preparing to open.

An original post written for CoderLegion by Luca Visciola (@melasistema)

Foundational Primitive Core of Multi-Agent AI Trust Infrastructure

Sun, 01 Feb 2026 04:05:03 +0000

AI Trust Infrastructure is defined by three foundational primitives
that must be structurally fixed prior to any governance,
security, or compliance mechanisms.

DID — Persistent Identity
CID — Immutable Memory
Canonical Meaning Root (CFE)

These three primitives together form the foundational primitive core of AI Trust Infrastructure.

Learn AI Agent Security with humour, and real-world examples

Wed, 14 Jan 2026 06:49:51 +0000

AI Agents are powerful, but without security, they’re also dangerous.

In this episode, Jigyaasu learns why AI Agent security isn’t just a technical concern, but a leadership and business imperative.

From prompt injection and hallucinations to data leaks and reputation damage, we explore what can go wrong when AI systems are deployed without guardrails.

Through simple analogies, real-world incidents, and a bit of humor, Saral breaks down:

Why prompt injection is more than a prank
How AI Agents can unintentionally leak sensitive data
Why hallucinations can become legal and reputational risks
The hidden cost of deploying AI without proper safeguards
Why AI security is about trust, not just technology

Let us learn "AI Agent Evaluation" with humour.

Tue, 04 Nov 2025 05:28:53 +0000

Let us learn "AI Agent Evaluation" with humour.

AI Agents can plan, reason, and act - but how do we know if they’re doing it correctly?

What if you wanted to book a ticket to London, but the AI Agent booked one to Lisbon?

We have to evaluate them, like we test software, right?

However, evaluating AI Agents is not as simple as evaluating traditional software or even an LLM

In this episode, join Jigyaasu and Saral as they simplify AI evaluation with relatable examples.

-> Next episode: MCP and A2A

Previous episodes:

What is an AI Agent - https://lnkd.in/gbWVEfyr
Multi AI Agents - https://lnkd.in/gJFg_UrU
AI Agent Memory - https://lnkd.in/gjWRiZdV

0. Basics of AI -

https://lnkd.in/gWWHqJcn

IBM's AI agents for Oracle Fusion Applications showcase the power of Agent Mesh.

Thu, 16 Oct 2025 21:34:43 +0000

The Agent Mesh: Building the Integration Layer for the AI Renaissance

Artificial Intelligence is no longer a standalone tool—it’s evolving into ecosystems of interconnected systems working together to streamline workflows, solve complex problems, and unlock unprecedented efficiencies. Enter the era of the Agent Mesh: a collaborative network of specialized AI agents designed to bring the AI Renaissance to enterprise workflows.

This concept is no longer just theoretical. Recent developments, like IBM’s announcement of three new AI agents for Oracle Fusion Applications, show how fast we’re moving toward a world where agentic AI systems are transforming the integration layer of modern enterprises.

In this post, we’ll explore:

What the Agent Mesh is and why it matters.
How IBM’s AI agents for Oracle Fusion Applications embody this concept.
What this means for developers building the future of enterprise AI.

What Is the Agent Mesh?

The Agent Mesh is the interconnected layer of AI agents that work collaboratively across systems, automating workflows and enabling smarter integrations. Think of it as a network of specialized bots, each performing targeted tasks while communicating with one another to optimize processes.

This isn’t just automation—it’s collaboration at scale. Agents in the Mesh aren’t siloed; they leverage shared data, coordinate actions, and adapt to user needs in real time. They’re like a team of experts, each with their own specialty, working together seamlessly.

For developers, this means building systems where AI agents act as modules that integrate with broader workflows and data ecosystems. The Agent Mesh is the future of AI-driven enterprise architecture, and it’s coming faster than you think.

IBM’s AI Agents: A Case Study in Agent Mesh

IBM’s recent announcement of three new AI agents for Oracle Fusion Applications is a perfect example of the Agent Mesh in action. Let’s break it down:

The Agents

1️⃣ Intercompany Agent: Automates reviews of intercompany agreements, reducing errors and manual effort.
2️⃣ Smart Sales Order Entry Agent: Simplifies the order-to-cash process by generating required sales order data.
3️⃣ Requisition to Contract Agent: Streamlines procurement workflows by converting purchase requisitions to contract orders.

These agents are built using Oracle AI Agent Studio and are validated within Oracle’s ecosystem, ensuring seamless integration with existing enterprise workflows.

Watsonx Orchestrate: The Multi-Agent Supervisor

What makes these agents truly powerful is their multi-agent coordination enabled by IBM watsonx Orchestrate. Acting as the conductor in this orchestra of bots, watsonx Orchestrate ensures these agents don’t operate in silos but instead collaborate across Oracle and non-Oracle systems.

For developers, this highlights the importance of designing agents that can interoperate with diverse platforms. It’s no longer just about creating a single-use AI tool—it’s about building agents that work together and adapt within a dynamic ecosystem.

Why Developers Should Care

1. The Integration Layer Is Key

As enterprises embrace AI, the integration layer will become the backbone of business operations. Developers will need to build agents that seamlessly connect with APIs, databases, and other tools to create cohesive workflows.

2. Collaboration Is the Future

The Agent Mesh demands that developers think beyond individual tools and focus on how agents interact with each other. This requires expertise in multi-agent systems, governance frameworks, and cross-platform interoperability.

3. The Demand for AI-First Applications Is Growing

As companies like IBM and Oracle continue to push boundaries, the demand for AI-first enterprise applications will skyrocket. Developers who understand how to design, deploy, and manage interconnected agents are poised to become indispensable.

Putting It All Together

The Agent Mesh isn’t just a concept anymore—it’s here, shaping the future of enterprise AI. IBM’s AI agents for Oracle Fusion Applications demonstrate the power of interconnected systems to transform workflows and unlock new efficiencies.

For developers, this is an exciting challenge. Building the Integration Layer for the AI Renaissance means creating systems that are not only intelligent but also collaborative and scalable.

What are your thoughts on Agent Mesh and agentic AI? How are you preparing to build the next generation of AI-driven applications? Let’s discuss in the comments below!

Agent Payments Protocol (AP2) in simple language with an example

Tue, 07 Oct 2025 06:47:07 +0000

AI agents can buy things on your behalf, right?

but would you trust them enough to do so?

The challenge: today’s payment systems assume a human is clicking “buy.”

With agents in the loop, how do we make sure payments are:

Authorized – Did the user really give the agent permission?

Authentic – Does the agent’s request match the user’s true intent?

Accountable – Who’s responsible if something goes wrong?

Google proposes to solve this problem through new Agent Payments Protocol (AP2)

How AP2 works:

Instead of relying on a human click, AP2 introduces Mandates – cryptographically-signed digital contracts that capture a user’s intent in a tamper-proof way.

Too many jargons?

Ok let’s understand this through an example

Imagine you tell your AI agent: “Buy me concert tickets when they go on sale, but only if they are under INR 10,000.”

Now, if an AI agent tries to “click” for you:

The merchant has no way to know if the agent is really acting on your instructions or just making up the request.

The system has no way to prove you actually gave consent for that specific purchase.

There is no standard audit trail.

How AP2 solves it:

You create an Intent Mandate: a signed digital instruction that says “buy tickets under INR 10,000”

When tickets appear, your agent generates a Cart Mandate: the actual seats + price.

The merchant receives both mandates as cryptographic proof that the agent is authorized, the price matches your conditions, and the purchase is valid.

Result: The agent buys securely without you being online, while the merchant is confident the payment is legitimate.

It seems with AP2, Agents can unlock new commerce experiences, like personalized offers, delegated purchases, coordinated travel bookings, etc.

What else do you think can be unlocked with AP2?

Learn Multi-AI Agents with humour in simple language

Wed, 24 Sep 2025 06:49:01 +0000

Let us learn Multi-AI Agent systems with humour.

Key takeaways:

What Multi-AI Agent systems are
How they work together step by step
Real-world examples (travel planning, customer support, content creation)

Next episode: AI Agents' Memory

Previous episodes:
What is an AI Agent -
https://lnkd.in/gbWVEfyr

Basics of AI -
https://lnkd.in/gWWHqJcn

Opinion: Some Reflections on MCP

Mon, 07 Jul 2025 10:31:56 +0000

Overview

There’s a lot of noise surrounding "MCP (Model Context Protocol)," and much like the advent of blockchain, image generators, LLMs, and autonomous agents before it, people are once again eager to proclaim "the next big thing." Often, despite widespread skepticism toward AI hype cycles, a bit of careful examination can still yield genuinely useful insights.

What is MCP

MCP is a protocol - meaning it only has value when multiple parties agree to adhere to it. Much of the groundwork was laid when OpenAI introduced tool use APIs for ChatGPT, which employed JSON-based interfaces and explicit function definitions. What matters now is the standardization effort led by Anthropic (creators of the Claude models and tools), and the broader push within the industry toward adoption.

Beyond its publications, MCP includes server/client implementations in C#, Python, and JavaScript - making it easier and faster for developers to build, integrate, and iterate using the protocol.

It should be immediately obvious to any experienced developer that the "tool use" API concept (e.g., OpenAI's) naturally suggests automatic code generation, simplified function definitions, and the creation of custom tooling. MCP offers a plug-and-play implementation, letting you deploy a standards-based server in the language of your choice.

MCP and LLM

But here’s a key question: does MCP actually have anything to do with AI or LLMs? Not directly. What it really promotes is something software systems should have already embraced - being reflective and externally accessible. Here’s a pun to consider: it requires existing systems to become more "reasonable."

Critical Reflection

Traditionally, if a developer doesn’t expose useful APIs, power users are left with limited automation options - often relying on brittle GUI hacks or workarounds. Now, under pressure from AI integration demands, vendors are compelled to expose meaningful interfaces.

Thanks to LLMs and their natural language capabilities, selecting and invoking these interfaces becomes easier. Developers and users are more likely to adopt this route over bespoke scripting languages or fixed REST APIs - especially when the MCP server/client pattern is clear and uses a familiar, structured format like JSON-RPC.

In some ways, it feels like a return to SOAP or other early networked protocol standards. The fundamental idea remains: software should be reflective. It should be able to communicate what it can do and how it can be interacted with. From that standpoint, MCP isn’t fundamentally about LLMs - it’s about reasserting old principles: software should be reusable, programmable, and capable of exposing clean, structured APIs.

But will this catch on? Will the unified "natural language access" paradigm fundamentally reshape the role of scripting languages or traditional API models?

I’m skeptical. If developers truly wanted their tools to be accessible, they’d already provide at least a Python or Lua API. Similarly, if service providers were committed to openness, they would already expose a REST API. The ones most likely to adopt MCP are those who already believe in programmability and composability. The laggards - those still struggling with infrastructure, security, or scaling - are unlikely to embrace MCP any time soon.

Conclusion

MCP is not magic. It's another attempt to formalize a programming interface model - this time one that works well with LLMs. But its core principles are older than LLMs themselves. Like many revolutions in computing, the value won’t come from novelty alone, but from thoughtful, widespread implementation. Whether MCP becomes ubiquitous or not depends less on its cleverness, and more on who decides to build with it - and why.

Reflections on My Second LangChain Session: Hype, Substance, and Agentic Potential

Fri, 16 May 2025 16:43:56 +0000

Today marked my second time attending a LangChain talk. My first was at a previous company, and this time, I joined an ACM-invited session. Unfortunately, my impression hasn’t changed much. Like the last time, the presentation leaned more toward a marketing pitch than a meaningful deep-dive into technology.

Forty minutes into the session, we were still swimming in vague promises and general problem statements. "LangGraph can solve this," they said - without ever really explaining how.

What LangChain Brings to the Table

To be fair, LangChain does offer a decent toolbox. Its ecosystem includes:

Paid utilities (like PDF ingestion)
Core components such as text splitters, output parsers, document loaders, and vector stores
Compositional elements like prompts, example selectors, tools, and model abstractions

Among these, the PDF ingestion tool stood out. It's genuinely useful - just not particularly accessible, since it sits behind a paywall. That pattern of paywalled features brings up the classic vendor lock-in concern. When a tech stack becomes too reliant on a single platform, especially one with closed components, you're playing a risky game. And to be blunt, the overall design doesn’t feel groundbreaking.

Learning by Observing

For me, the purpose of attending wasn't just about learning the tool - it was about observing how they package and present AI service integration. As Divooka continues to evolve and offer deeper native AI capabilities, I find myself increasingly valuing compositional and node-native approaches, like what ComfyUI offers. Its visual chaining model feels more transparent and modular - something that can be critical when building robust, production-grade AI workflows.

That said, there was one key idea from the LangChain session that resonated: agents do matter. Agentic applications, when structured with purpose and supported by strong pipelines, can lead to some powerful real-world use cases.

The "Real-Time Use" Challenge

The first problem they introduced had to do with real-time responsiveness. Ironically, they later conceded it wasn’t really a "problem" but more a matter of user-perceived latency. Still, here's how they broke it down:

Challenge	Proposed Solution
Multiple LLM calls needed	Parallelize steps where possible
Non-LLM steps (e.g., RAG, database queries, tool calls)	Parallelize or batch when feasible
Keeping users engaged during waiting periods	Stream intermediate outputs (optional)

The advice wasn’t necessarily wrong - but it felt narrow. These solutions are tailored for real-time UIs and don’t necessarily tap into the deeper promise of agentic systems. Agents shouldn’t just be about speed - they should be about capability, reasoning, adaptability.

LangGraph: Intriguing Promises, Lingering Questions

LangGraph, as an extension of LangChain, introduces some genuinely interesting features:

Persistent, long-running workflows with streaming and human-in-the-loop support
Integration with LangSmith for observability
A main graph architecture augmented by subgraphs for each agent - supporting multi-agent interaction patterns
Native support for both token- and event-level streaming
(Interestingly, someone compared it to Amazon Bedrock Flows, which seems like a fair analogy)

Despite the potential, several critical questions remain unanswered:

What does the full system architecture look like?
Is LangGraph something you must self-host, or does it assume reliance on LangChain’s hosted infrastructure?
How is state managed internally, and how configurable is the runtime model?
What’s the actual developer experience like when setting up human-in-the-loop interaction?

They did recommend a textbook - Learning LangChain: Building AI and LLM Applications with LangChain and LangGraph by Mayo and Nuno - which might offer some clarity. But relying on a textbook to fill in architectural gaps from a talk feels like a missed opportunity.

Final Thoughts

These sessions are always worth attending - not necessarily for the content, but for the context. It’s important to see how the broader ecosystem evolves, what narratives companies are pushing, and where we can differentiate.

At Methodox, we’re focusing on flexibility, transparency, and seamless integration across AI services. That’s why our approach to Divooka aligns more closely with frameworks like ComfyUI - ones that embrace openness and modularity.

The future of AI applications will depend not just on speed or flashy demos, but on clarity of architecture, trust in execution, and real-world adaptability. That’s where I believe we can lead.

Coder Legion - Recent posts tagged multi-agent

The Lie Outlives the Liar: Why Removing the Bad Agent Is Already Too Late

The instinctive fix, tested

Humans got this result thirty-two years earlier

The paper that says the opposite, and why it doesn't

The fix has a name, and it is not "removal"

What to do on Monday

Sources

Group Chat Orchestration: What AutoGen Got Right About Multi-Agent Design

Conversation History As Shared State

Deciding Who Speaks Next

Per-Agent Model Assignment

The Execution Boundary

What To Carry Forward

The Wood Wide Web of AI

The Fairy Tale and Its Cracks

What the Fungal Network Actually Does

The Parallels That Survive Scrutiny

The Meta-Parallel

What Builders Can Steal from Fungi

The Real Weakness of AI Missiles Is Surprisingly Boring

The Sovereign Machine: Chasing the Holy Grail of Private Intelligence

The Genesis: INTENTIO and the Human-Led Cognitive Space

The Crucible: ARKHEIN and the 7-Level Cognitive Pipeline

The Synthesis: Anticipating ANDARTIS

The Architecture of Rebellion

Democratizing the Holy Grail

Foundational Primitive Core of Multi-Agent AI Trust Infrastructure

Learn AI Agent Security with humour, and real-world examples

Let us learn "AI Agent Evaluation" with humour.

IBM's AI agents for Oracle Fusion Applications showcase the power of Agent Mesh.

The Agent Mesh: Building the Integration Layer for the AI Renaissance

What Is the Agent Mesh?

IBM’s AI Agents: A Case Study in Agent Mesh

The Agents

Watsonx Orchestrate: The Multi-Agent Supervisor

Why Developers Should Care

1. The Integration Layer Is Key

2. Collaboration Is the Future

3. The Demand for AI-First Applications Is Growing

Putting It All Together

Further Reading

Agent Payments Protocol (AP2) in simple language with an example

Learn Multi-AI Agents with humour in simple language

Opinion: Some Reflections on MCP

Overview

What is MCP

MCP and LLM

Critical Reflection

Conclusion

Reflections on My Second LangChain Session: Hype, Substance, and Agentic Potential

What LangChain Brings to the Table

Learning by Observing

The "Real-Time Use" Challenge

LangGraph: Intriguing Promises, Lingering Questions

Final Thoughts