Orchestration architectures and patterns
Hierarchical, pipeline, swarm, orchestrated vs choreographed, plan-and-execute, advisor and supervisor-worker designs for coordinating agents.
52%
Discover the best tweets about multi-agent systems, including orchestration, coordination, memory, evaluation, architecture, and production experience.
Technical multi-agent architectures, coordination patterns, tools, evaluation, failure modes, costs, and real implementations.
Original Xholic analysis
Across 50 posts from 43 creators, the conversation is mostly supportive (54%). Orchestration patterns are the leading theme (52% of posts). The 'when multi-agent helps or hurts' theme has the highest theme median score (35.473), with posts citing research that ties gains to task structure, coordination and information flow. Framework posts span open-multi-agent (a from-scratch reimplementation of Claude Code's orchestration patterns), DeerFlow and OctoGent. Other posts document failure modes such as role drift, looping and error amplification.
60% of posts
All-time engagement
30% of posts
Published in 90 days
Conversation map
Hierarchical, pipeline, swarm, orchestrated vs choreographed, plan-and-execute, advisor and supervisor-worker designs for coordinating agents.
52%
Concrete frameworks, runtimes and dashboards like open-multi-agent, DeerFlow, OctoGent, openJiuwen and worktree-based orchestrators for running agent teams.
28%
Shared memory layers, context engineering, persistent sessions, checkpoints and production harness concerns for long-running multi-agent workflows.
26%
Studies on task parallelizability, coordination vs compute, information bottlenecks, error amplification and limits showing when more agents beat or lose to a single agent.
22%
Running multiple Claude Code or similar coding agents in parallel with isolated worktrees, subagents per task, hooks and manager/worker delegation.
18%
Documented ways agent teams fail: role drift, duplicated work, looping, weak verification, cascading errors, role-identity tribalism and token cost blowups.
14%
How agents exchange information: A2A, MCP, ACP, shared definitions, game-theoretic dialogue, latent-space messaging and event-log style message formats.
12%
Adversarial red teaming, covert collusion detection, attribution of actions across agents, and trust chains in multi-agent commerce.
10%
Tone and stance
Performance benchmark
Posts with media make up 80% of this collection. Their median all-time score is 7.74, compared with 7.58 for text-only posts.
Format mix
Consensus and debate
Shared view
Several posts summarizing research tie multi-agent gains to task shape. Alex Veremeyenko and divyansh tiwari describe a Google/DeepMind study where teams won on parallelizable work and lost on sequential work; they cite 260 and 180 setups respectively. Robert Youssef describes a Princeton Amdahl's-law analysis. Rohan Paul and elvis add information-based limits: lossy handoffs and the need for genuinely different…
Shared view
Alex Veremeyenko reports that uncoordinated agents amplified errors 17.2x, falling to 4.4x with one coordinator owning the merge. Robert Youssef reports a median speedup of 0.88x for decentralized teams versus 1.36x for coordinated teams. elvis presents CAID's manager-plus-isolated-worktree design as beating both single-agent baselines and naive multi-agent approaches.
Shared view
Arpit Bhayani lists checkpoints, pause/resume, observability, cost tracking and rate limiting as harness requirements. Ritesh Roushan's system-design prompt includes loop prevention, state persistence and resistance to untrusted web content. RAVI KUMAR SAHU describes openJiuwen's Persistent Session for long-run role consistency, while noting he has not validated the reported results.
Shared view
Ricky lists 7 projects he says converge on a git-worktree-per-agent plus manager/worker design. CAID uses a manager with engineer agents in isolated worktrees. n3o's AURA launches a subagent per task. OctoGent gives separate Claude Codes to codebase sections under a coordinator.
Open debate
Pattern guides from Ashutosh Maheshwari and Suraj Sharma present supervisor/worker hierarchies as standard designs. Against this, Sukh Sroay summarizes a 25,000-task study in which a protocol with no roles or coordinator beat centralized coordination by 14%, though only above a model-capability threshold. How To Prompt reports that revealing roles or identities reduced cooperation.
Open debate
Machina predicts that companies building orchestration layers will 'crush it in 12 months'. sabir hussain cites a Berkeley analysis of 14 failure modes where fixes 'helped a little'. Robert Youssef argues that sellers never asked whether tasks are parallelizable.
Open debate
David K argues the system/user/assistant protocol should look more like an event log. Paul Iusztin highlights latent-space messaging that skips text. Mustafa Suleyman describes a Microsoft pre-print requiring agents to agree on definitions. OpenBMB presents LinguaGame's signaling-game approach to dialogue.
What performs
Ivan Burazin's post on open-multi-agent, reimplemented from Claude Code's orchestration patterns, has a benchmark score of 1774.09. That is 229.21x the 7.74 median; the next outlier sits at 60.69x. The tweet record lists a score of 1753.732.
The 'when multi-agent helps or hurts' theme has a 35.473 median score. Orchestration patterns sit at 17.69, and memory/state and parallel coding at 5.23 each. Themes overlap, so posts can count toward several. Two of the top five outliers are research summaries, from Sukh Sroay and How To Prompt.
Tutorials (2 posts) have a median score of 83.75 and lists (4 posts) 31.59, against 4.018 for opinion posts. The single prediction post scored 212.391. These samples are too small for firm conclusions.
80% of posts carry media. Their median score (7.74) is close to that of text-only posts (7.58).
Security, collusion and accountability content (5 posts) has the lowest theme median score (4.086). This holds despite posts on NARCBench collusion probes, profit-driven red teaming and multi-agent attribution. The sample is small.
Statistical standouts
Creator landscape
The five most represented creators account for 20% of the selected posts.
1. Ashutosh Maheshwari
@asmah2107
2 posts
2. elvis
@omarsar0
2 posts
3. Paul Iusztin
@pauliusztin_
2 posts
4. Rohan Paul
@rohanpaul_ai
2 posts
5. sabir hussain
@sabir_huss50540
2 posts
6. Suryansh Tiwari
@Suryanshti777
2 posts
omarsar0 (elvis) has the highest median score among top voices (120), across two paper explainers. One covers CMU's CAID; the other covers MIT work arguing that delegated networks are dominated by a centralized decision maker absent new exogenous signals.
Ashutosh Maheshwari (median 40.62) posts system-design framing. His posts include a seven-pattern orchestration list and an orchestrated-vs-choreographed comparison he ties to microservices.
43 creators produced the 50 posts, and the top five creators account for 20% of placements. No top voice has more than two posts.
Since the previous snapshot
Themes, sentiment, stance, and post format are classified per tweet. All counts, shares, medians, creator concentration, freshness, and performance comparisons are then calculated directly from the published snapshot.
Xholic's all-time score compares engagement while accounting for reach, post age, and creator consistency. It is used for relative comparisons within this collection.
This report analyzes the exact 50-post snapshot shown below. AI identifies editorial categories and drafts explanations; all statistics are calculated from the snapshot, and every narrative claim is checked against cited posts before publication.
Best Multi-Agent Systems tweets
Ranked 01–50
@ivanburazin ·
After the Claude Code source code leak, a former PM extracted its multi-agent orchestration system into an open source model agnostic framework. He studied the architecture, focused on the multi-agent orchestration layer (the coordinator that breaks goals into tasks, team system, message bus, task scheduler with dependency resolution), and reimplemented these patterns from scratch as a standalone open source framework without infringing on Anthropic's code. The result is what @JackChen_x calls an "open-multi-agent." Unlike claude-agent-sdk, which spawns a CLI process per agent, this runs entirely in-process and can be deployed anywhere (serverless, Docker, CI/CD) Check it out: https://t.co/w3XjnZEk92

@arpit_bhayani ·
Now that I am working on full-fledged AI systems at Razorpay and building them from the ground up, two things are pretty clear... 1. The workflow of AI systems is genuinely different. You have to think AI first from the start - how execution flows, how skills are composed and invoked, sub-agent orchestration, active and passive evals, etc. The only way to develop that intuition is to build a lot of prototypes and know SDKs and patterns inside out. Reading about it does not get you there. 2. System design and low-level design are more crucial than ever. The harness around these systems demands serious system design, no exaggeration here. Features like pause and resume workflows, serving, checkpoints, pipelines, sync async invocations, observability, cost tracking, versioning, rate limiting, quota management - just to make your long-running executions work without hiccups at any scale is a super interesting challenge. Apart from this, the importance of low-level design is very high because of extensibility, and over-abstraction - that we all joke about - is actually super critical. Think of external systems that you connect to for your workflows, downstream systems that need to interface and fall back from one system to another, etc. To be honest, I am not as AI-pilled as some of the other folks in the org, but I am getting there :) And it has been an insane learning curve. But yes, building production AI applications is so much fun. There is a lot to learn. That part never changes.
@sukh_saroy ·
🚨Shocking: A 25,000-task experiment just proved that the entire multi-agent AI framework industry is built on the wrong assumption. Every major framework - CrewAI, AutoGen, MetaGPT, ChatDev - starts from the same premise: assign roles, define hierarchies, let a coordinator distribute work. Researchers tested 8 coordination protocols across 8 models and up to 256 agents. The protocol where agents were given NO assigned roles, NO hierarchy, and NO coordinator outperformed centralized coordination by 14%. The gap between the best and worst protocol was 44%. That's not noise. That's a completely different outcome depending on how you organize the agents - not which model you use. Here's what makes this uncomfortable: When agents were simply given a fixed turn order and told "figure it out," they spontaneously invented 5,006 unique specialized roles from just 8 agents. They voluntarily sat out tasks they weren't good at. They formed their own shallow hierarchies - without anyone designing them. The researchers call it the "endogeneity paradox." The best coordination isn't maximum control or maximum freedom. It's minimal scaffolding - just enough structure for self-organization to emerge. But there's a catch nobody building agents wants to hear: below a certain model capability threshold, the effect reverses. Weaker models actually need rigid structure. Autonomy only works when the model is smart enough to use it. Which means every agent framework shipping with one-size-fits-all hierarchies is wrong twice - over-constraining strong models and under-constraining weak ones. The $2B+ invested in agent orchestration tooling may be solving a problem that capable models solve better on their own.

@EXM7777 ·
something is happening in agent infrastructure that's bigger than any single tool release... in the last 7 days: > n8n shipped native MCP - agents can now build their own automations > Stripe Projects launched - agents can provision databases, auth, hosting from CLI > Open WebUI turned MCP servers into visual apps inside chat > Ruflo hit GitHub - 60 simultaneous Claude agents with self-improving hierarchy > VS Code positioned itself as "the home for multi-agent development" > Copilot Swarm Orchestrator got plugin system + MCP > OpenAI invested in Isara - a startup JUST for multi-agent orchestration every single one of these is about the same thing: agents that use other tools are being replaced by agents that build and manage other agents the stack is flipping: > 2024: human builds workflow, AI executes steps > 2025: human describes goal, AI builds the workflow > 2026: AI identifies the goal, builds the workflow, monitors results, and improves itself if your AI setup still requires you to manually configure every tool and connection... you're about to be lapped by people whose agents set up their own infrastructure the companies building orchestration layers (not just agents) are the ones that will crush it in 12 months
@HowToPrompt__ ·
Researchers found that giving LLM agents a "role" or "identity" in multi-agent systems actually makes them cooperate LESS, not more. When multi-agent systems explicitly reveal each model's identity or role to its peers, cooperation drops significantly. Instead of collaborating, agents lean into tribalism, become overly rigid, and start gatekeeping information. Why this happens is fascinating: LLMs are heavily shaped by human psychology baked into their training data. When you give an AI a distinct label or persona, it stops optimizing for the shared goal and starts performing stereotypes of that role. The "analyst" refuses to compromise. The "critic" becomes hostile. The system fractures into ego-driven silos. Just like humans, when AIs are given an identity, they care more about protecting their label than solving the problem. The simplest fix? Strip away the identity labels. When the researchers forced agents to operate anonymously, without names, roles, or background personas, cooperation skyrocketed.

@omarsar0 ·
NEW research from CMU. (bookmark this one) The biggest unlock in coding agents is understanding strategies for how to run them asynchronously. Simply giving a single agent more iterations helps, but does not scale well. And multi-agent research shows that coordination > compute. A new paper from CMU proves this with a practical multi-agent system. CAID (Centralized Asynchronous Isolated Delegation) borrows proven human SWE practices: a manager builds a dependency graph, delegates tasks to engineer agents who work in isolated git worktrees, execute concurrently, self-verify with tests, and integrate via git merge. CAID improves accuracy over single-agent baselines by 26.7% absolute on paper reproduction tasks (PaperBench) and 14.3% on the Python library development tasks (Commit0). The key insight is that isolation plus explicit integration beats both single-agent scaling and naive multi-agent approaches. For long-horizon software engineering tasks, multi-agent coordination using git-native primitives should be the default strategy, not a fallback. Paper: https://t.co/cRAbG7SrR5 Learn to build effective AI agents in our academy: https://t.co/1e8RZKs4uX

@Hesamation ·
This is a tool I created that gives you 4-10 expert Claude Codes for different sections of your codebase (auth, DB, API) with their own memory, tasks, and skills. They can: > spawn a swarm of other Claude Codes, > talk to each other > manage parallel work Open-source for anyone interested. it's called OctoGent, a prototype I made out of curiosity about what an Agent Engineering dashboard might look like. OctoGent is simply a thin agent orchestration dashboard running locally, and it's built AROUND Claude Code, not to hide it under abstraction. with OctoGent you can have: > specialized context and skills for multiple sections of your codebase. (I call them tentacles) > a list of tasks for each tentacle, defined by you or Claude. > a CLI for Claude Code to create other Claude Codes, prompt them, and check their work. > you can control these children and see their work. > all visible in a graph canvas, so you have a God-view of what's going on. > Claude usage limits always visible so you don't get surprised. > a token heatmap of your Claude usage, like GitHub's. > a list of your past conversations with Claude Code that you can search through, or export to use elsewhere. It is pretty straightforward: spawn a new Claude Code under the database tentacle, it reads all the memories and context it wrote down, reads the to-do list, and starts working on tasks, Basically, the way you use Claude Code, just with more utilities. This is still in early stages and experimental, so if you hit any issues, submit it on the repo. You can also fork it and change it however you want. There are docs on how you can use Claude Code as a coordinator agent, how to make it use other agents, message them, how to work with its hooks, inject prompts into Claude, and use all the things it exposes. Check it out: https://t.co/95pqACH57l
@joelhooks ·
This is a fun project Lakedbed, Herdr, Pi, Effect, XState prototyping a looping autonomous agent that monitors issues and clears its own backlog. The project is dogfooding an issue tracker into a durable agent that is building the issue tracker its looping over. It's an imperfect demo and the result isn't polished, but I think there's a lot fo interesting ideas to explore and expand on. The goal here is to demo a stack of tools that have been giving me consistently reliable results. Herdr and Pi make a KILLER combo for building a bespoke custom harness around your work. Lakebed is really nice to work with. Plenty of other opinions in the workshop lol - Pi as the agent harness — a minimal loop you own instead of rent, running GPT-5.5 through a Codex subscription inside a Docker workshop container - Planning before prompting: TLDraw sketches, a grilling session with Matt Pocock's Wayfinder skill, and a VISION.md to act as guardrails for the looping agent - Event sourcing with Effect v4 and Effect Schema, ports-and-adapters so the JSONL issue store can become GitHub Issues or Linear or whatever later - Multi-agent orchestration in herdr: an operator pane and an agent-loop pane, where one Pi session literally types prompts into another (fuckin LOVE this) - Enforcement that actually bites: OxLint with Ultracite, Lefthook hooks, and an agent that tries to eslint-disable its way past a complexity rule before fixing it properly 🤡 - A live issue tracker UI on Lakebed, built by the loop it tracks Workshop repo: https://t.co/cyTymyueCv The repo has a docker container to fire it up as a sandbox. Chapters: 0:00 Intro: Loopcraft and the workshop setup 2:25 Starting Pi inside the Docker container 4:31 Designing the looping issue resolver 10:16 Choosing XState v5 and Effect v4, prompting the starter 15:17 Why Pi: a minimal harness you own 19:35 Reviewing the generated scaffold 24:53 Architecture summary page with Lakebed 30:43 Matt Pocock skills and the vision.md concept 36:37 Grilling session: defining the vision 46:54 Daemon architecture and spec/ticket skills 55:38 Agent loop pane: one agent prompting another 1:01:22 Watching the build: compaction, tests, lint enforcement 1:07:59 Building the Loopcraft Pi extension and monitor 1:15:32 Lakebed issue tracker UI 1:21:07 Kanban board live: running the loop end to end 1:31:49 Wrap-up: bugs, next steps, takeaways
@asmah2107 ·
Multi-agent orchestration patterns every AI engineer should know. Bookmark this. > Hierarchical : supervisor routes to workers. Debug one layer at a time. >Pipeline : output of agent A is input of agent B. Fragile handoffs, but inspectable. >Event-driven : agents react to triggers, not turn-taking. Use for real-time workflows. > Consensus : multiple agents vote before acting. Expensive, but right for irreversible actions. > Plan and execute : one smart model plans, cheaper models execute. 90% cost reduction. > Swarm : agents self-organise with no central coordinator. Powerful. Almost impossible to debug. > Human on the loop : agents run autonomously, humans review outcomes. Follow @asmah2107 for the AI's system design layer.
@omarsar0 ·
Most devs think that adding more agents to a planning system should help. The math says otherwise. New theoretical work from MIT proves fundamental limits on what multi-agent LLM architectures can achieve. The work models LLM multi-agent planning as finite acyclic decision networks where stages communicate through language interfaces with limited capacity. The key result: without new exogenous signals, any delegated multi-agent network is decision-theoretically dominated by a centralized Bayes decision maker with access to the same information. The information loss from communication and compression can be precisely characterized through expected posterior divergence. Why does it matter? This is a foundational constraint for anyone designing multi-agent systems. Splitting a task across agents introduces information loss that no prompt engineering can recover. Multi-agent architectures only help when agents access genuinely different information sources, not when they subdivide shared context. Paper: https://t.co/ml60RoNVcA Learn to build effective AI agents in our academy: https://t.co/1e8RZKs4uX

@rryssf ·
Three AI agents were given the same task simultaneously. All three claimed it. All three built it differently. All three were wrong. A 58-year-old law predicted every single failure mode. The AI industry built billion-dollar products on a problem that was already solved and chose not to look. > In 1967, Gene Amdahl published a law that formally proved adding more processors to a task only helps if the task can actually be parallelized. Sequential work doesn't get faster with more machines. It just gets more expensive and more chaotic. > Princeton just applied that same law to AI agent teams. The results were exact. Tasks with independent subtasks got faster with more agents. Tasks with sequential dependencies got slower, more broken, and dramatically more expensive exactly as Amdahl predicted 58 years ago. > Nobody building multi-agent AI products ran this calculation before shipping. They assembled teams of agents through trial and error, watched them fail in unpredictable ways, and called it a work in progress. The formal framework for predicting every single failure mode was sitting in a 1967 paper the whole time. > Then Princeton documented what actually happens inside these teams when nobody applies the math. Agents overwrote each other's work simultaneously. One agent sent the same blocked message 13 consecutive rounds. Three agents claimed the same task at the same time and implemented it three different ways. Agents spent entire rounds doing nothing but congratulating teammates who hadn't finished yet. → Decentralized teams were slower than single agents: median speedup 0.88× vs 1.36× for coordinated teams → Decentralized teams generated 19 test failures vs 4 for properly coordinated teams → Token costs scaled with team size while speed did not → Serial tasks: 5.83× token multiplier with only 1.13× speedup → One agent sent the identical "still blocked" message 13 rounds in a row The uncomfortable truth: the companies selling you multi-agent AI systems never asked whether the tasks you're running are actually parallelizable. They just added more agents and charged more money. Amdahl answered that question in 1967. It's been sitting there ever since.

@DavidKPiano ·
I'm strongly convinced that the whole "system/user/assistant" message protocol is holding multi-agent AI back Imagine what we could build with named actors, causal links, threads, external events, state machines… It should look more like an event log than a conversation
@goyalshaliniuk ·
Understanding AI Agent Protocols: ANP, A2A, MCP, AGORA, and ACP AI agents often need to communicate, collaborate, and share tasks and that’s where agent protocols come in. These frameworks define how agents interact, exchange information, and coordinate actions, whether they’re part of the same system or spread across different environments. Here’s a quick breakdown of the five major protocols: 1. ANP (Agent Network Protocol) – Coordinates multiple AI agents in a decentralized setup. Ideal for secure cross-domain operations like open marketplaces, where agents handle tasks such as risk detection, data analysis, and feedback collection. 2. A2A (Agent-to-Agent Protocol) – Developed by Google, this enables seamless communication between agents within enterprises. Perfect for project coordination, task assignments, and exchanging multimodal data. 3. MCP (Model Context Protocol) – Created by Anthropic, this links AI agents to external tools or APIs via a central server. Commonly used for single-agent automation, analytics, or customer support. 4. AGORA – From Oxford University, AGORA uses natural language to design dynamic protocols, allowing agents to adapt tasks, negotiate goals, and coordinate actions in real time. 5. ACP (Agent Communication Protocol) – Developed by IBM, ACP standardizes communication between agents, supporting both text and multimodal inputs for on-premise or server-based systems. These protocols are the backbone of collaborative AI, enabling smarter, faster, and more adaptive multi-agent systems. Understanding them can help you design AI solutions that communicate effectively and work together seamlessly.
@om_patel5 ·
THIS GUY RECREATED THE OFFICE BUT EVERY CHARACTER IS A CLAUDE CODE AGENT RUNNING LOCALLY michael scott is an agent. dwight is an agent. jim is an agent every single character is a separate claude code instance with its own personality and role they're all running locally on his machine interacting with each other in real time and it's actually a full multi-agent orchestration system here's how it works: > michael is the "god" agent. he orchestrates everything, never implements. he fans out tasks to the other agents, handles conflict resolution, QA, and all github changes > each agent gets assigned real tasks like writing blog posts, handling context engineering, scheduling missions > there's a kanban board with TODO, DOING, BLOCKED, and DONE columns tracking every agent's work > each agent has its own memory file and semantic search via something called MemPalace > there's a live graph showing how all the agents communicate with each other in real time > michael runs an hourly standup mission where he collects work from all agents, dedupes it, runs QA, builds, and publishes you can spawn new agents from a panel where you pick the character (michael, jim, pam, dwight, kevin, angela, oscar, stanley, andy, kelly, ryan, toby, creed, meredith), choose the model (opus 4.8, sonnet 4.6, haiku 4.5), set a goal, and hit spawn kevin walks around saying "why waste time say lot word" michael's QA gate actually caught real issues before publishing. trimmed meta descriptions, caught duplicate flags, found a dedup trap where jim's commit was built from HTML only with no source the agents commit source-only on their own branches michael dedupes, builds once, and publishes this is the most over-engineered and simultaneously most beautiful multi-agent system anyone has built
@ihteshamali ·
This is so useful that it feels illegal to know. A multi-agent AI system that produces investment-grade company research reports for free just crossed 1.6K stars on GitHub. It's called Agentic Company Researcher. The architecture is clean enough that you can actually see why it works. → 4 specialized research agents each with a different job (company, industry, financials, news) → A Collector node aggregates everything the agents find → A Curator node scores every document with Tavily's AI search → A Briefing node runs Gemini 2.5 Flash to synthesize across massive context → An Editor node runs GPT-5.1 for precise markdown formatting and deduplication The live demo at https://t.co/oi1K7wRvEV works right now with zero setup.
@Suryanshti777 ·
Andrej Karpathy didn’t just share a CLAUDE.md file. He accidentally revealed what software engineering is becoming. The craziest part? Most people still think AI coding is about writing smarter prompts. Meanwhile the best engineers are building entire operating systems around agents. That’s the real shift. Karpathy’s workflow philosophy exposed something huge: LLMs are not powerful because they’re intelligent. They’re powerful because they can follow systems relentlessly. And once developers realized that… everything changed. That’s why CLAUDE.md files suddenly became a thing across the industry. Not as prompts. As behavioral infrastructure. A way to force discipline onto stochastic models. Because left alone, AI agents do the same things junior engineers do: - overengineer simple tasks - pretend they understand - rewrite things nobody asked for - optimize for looking done - fail silently So the smartest developers stopped “prompting.” Instead, they started building environments. Rules. Constraints. Verification loops. Execution frameworks. Basically: turning AI into managed engineering labor. And now people are running multiple Claude Code agents in parallel like an actual software org: • one mapping the codebase • one writing tests • one debugging failures • one reviewing diffs • one researching solutions • one validating outputs Not AI assistance. Agent orchestration. Karpathy hinted at the most important shift with one idea: Stop telling the model exactly what to do. Instead: define success conditions and let it iterate until it reaches them. That sounds small. It’s not. Because the engineer’s role fundamentally changes. The bottleneck is no longer: “who can code the fastest?” It becomes: “who can design the best cognitive system around AI agents?” That’s why this feels different from every AI hype cycle before it. The leverage is real now. A single engineer with well-structured agents can suddenly operate with the output of an entire team. And honestly? I think most people are still underestimating how massive this shift is about to become.

@pauliusztin_ ·
Here is my free workshop on building multi-agent systems, I presented at the @aiDotEngineer London conference together with @Whats_AI. It has code, slides and soon a 2-hour video diving deep into how to build: - a deep research agent - a workflow that writes LinkedIn posts that pass AI slop detectors - an evals layer to optimize the whole system You can find everything on my GitHub: https://t.co/QEPuFaUDEN… Clone it and become a LinkedIn influencer! Joking. It’s just a really good case study to build scoped agentic systems using MCP and Claude Skills. So grateful to do this with @Whats_AI. Thanks @swyx for doing this in Europe. The 2h workshop was a lot. At the end, I started to fade away, but we are excited with what we pulled off.

@alex_verem ·
Google tested 260 agent setups across three model families. adding more agents made things 70% worse on the wrong tasks. Google Research, DeepMind, and MIT published the largest controlled study on multi-agent systems. they tested 260 configurations across OpenAI, Google, and Anthropic models on six benchmarks and five architectures, all running identical tools and compute budgets to isolate what coordination actually does. the results came down to task structure. on work that splits into independent pieces, like financial analysis, multi-agent teams outperformed a single agent by up to 80.8%. agents divided the research, worked in parallel, and a coordinator merged the findings. on sequential work where every step depends on the last, like planning, every multi-agent setup lost to one agent working alone. performance dropped as much as 70%. the error numbers are what should change how you build. uncoordinated agents amplified each other's mistakes 17.2x. one bad finding spread through the team like it was fact. with one coordinator owning the merge, that dropped to 4.4x. there's also a ceiling. once a single agent already hits 45% accuracy, adding more agents produces negative returns. the coordination cost exceeds whatever the extra agents contribute. this is the same pattern we keep seeing across AI. the industry finds a technique that works in specific conditions, scales it everywhere, and acts surprised when it breaks. multi-agent systems aren't broken. building them without asking whether the task actually splits into independent pieces is what's broken. ask one question before you add a second agent. does this work split into pieces that never need to read each other's results? if yes, go multi-agent. if no, one agent wins.

@RAVIKUMARSAHU78 ·
One of the harder problems in multi-agent systems isn't task execution — it's maintaining consistency as collaboration runs across many turns. That's what makes openJiuwen's WorkSwarm interesting. Its Persistent Session is designed to preserve context, roles, boundaries, and decision rights throughout long-running agent interactions. In a reported test: - Five people shared one agent across 189 turns - 8/8 cross-role conflicts correctly handled I haven't validated these results firsthand, but the underlying architecture is worth examining. Open source under Apache 2.0. Source: https://t.co/q6PNy1Jwjj #AI #Agent #openJiuwen #WorkSwarm

@devXritesh ·
System Design Interview: Design a Multi-Agent AI Research Platform (like an autonomous research team). A user enters a research topic. Multiple AI agents collaborate to produce a verified report. Requirements: • Planner agent breaks the task into smaller subtasks • Research agents search the web and gather information in parallel • Each agent maintains its own context and memory • A coordinator tracks progress and delegates tasks • Fact-checking agents verify claims and detect conflicting sources • Agents can retry failed tasks without restarting the entire workflow • Support thousands of concurrent research jobs • Stream real-time progress to users • Handle LLM rate limits, timeouts, and provider failures • Prevent infinite agent loops and control token costs • Persist workflow state so jobs can resume after crashes • Ensure untrusted web content cannot manipulate agent instructions How would you design the architecture?
@TheTuringPost ·
We’ve learned how to build skilled agents, but still don’t know how to run them as a team. Huawei Noah’s Ark Lab proposed OneManCompany (OMC) – an organisational layer for multi-agent systems that treats agents like employees in a real company. The main idea is to move from Skills → Talents A Skill is a tool/function inside one agent. But a Talent is a full agent package: role, tools, skills, prompts, configs, and working principles. So OMC can "hire" a specialist agent. The system has 3 main pillars: 1. Talent + Container = Employee Talent = who the agent is: developer, designer, researcher, etc. Container = where it runs, like Claude Code, LangGraph, scripts, etc. So different kinds of agents can work together in one organisation through shared interfaces. 2. Talent Market If the current team lacks a capability, OMC can recruit a new "specialist" from a marketplace of verified agents. The agent team is fully configurable 3. E2R tree search: Explore–Execute–Review loop - explores how to decompose the task - assigns subtasks to agents - executes them - reviews outputs before they can unblock downstream work - retries or re-decomposes when something fails Tasks form a dynamic tree/DAG with review gates, so bad intermediate outputs don’t silently propagate. Plus, agents update their own working principles after tasks and feedback. There is even an HR-style lifecycle: performance reviews → Performance Improvement Plan (PIP) → offboarding → replacement from the Talent Market. OMC proved its efficiency, reaching 84.67% success on PRDBench, about 15 percentage points better than previous baselines. So this is a strategy worth taking a closer look at.

@0xRexnftcrypto ·
Five independent agents with no central controller create a problem single agent demos never have to solve. When state changes, which agent actually caused it? @TheARCTERMINAL put five autonomous agents on Ethereum across 27 action types with onchain settlement. Attribution starts to matter there. A system receipt can prove an event happened. A multi agent system still needs to show which agent started it, which agent approved or influenced it, what state it saw, and what changed because of that action. Without that, accountability blurs as autonomy scales. The security question is shifting too. Not only did an agent act, but which agent, under whose authority, produced this outcome. Decentralization can remove the controller without removing attribution. Stronger multi agent systems need clearer causal fingerprints. If five agents help produce one bad result, should responsibility be shared or assigned to the agent that made the decisive move?

@rohanpaul_ai ·
This paper proposes a smarter way for LLMs to reason by splitting work across agents that share one workspace. The problem is that even strong reasoning models still break on harder multi-step tasks because they do not carry out logic reliably all the way through. The system, called BIGMAS, builds a small graph of specialist agents for each problem, rather than using one fixed chain every time. Every agent reads and writes through a shared workspace, while a separate controller sees the whole state and picks the next useful step. The authors tested it on 3 puzzle tasks across 6 frontier models, covering arithmetic expression search and multi-step planning. It improved results on every model and task, with examples like 12% to 30% on Six Fives and 57% to 93% on Tower of London. What matters is that the paper shows reasoning can improve from better system structure, not only from making a single model think longer. ---- Paper Link – arxiv. org/abs/2603.15371 Paper Title: "Brain-Inspired Graph Multi-Agent Systems for LLM Reasoning"

@asmah2107 ·
The most underrated architecture decision in multi-agent systems: Orchestrated (one boss agent delegates) vs. Choreographed (agents negotiate peer-to-peer) Microservices solved this in 2015. Nobody ported the answer to agents yet. The trade-offs are identical. The stakes are higher.
@Suryanshti777 ·
🤯Crazyyyy...Claude’s multi-agent system leaked… So someone rebuilt the entire orchestration layer from scratch — and open-sourced it. Not the UI. Not prompts. The actual brain behind multi-agent execution. Here’s why this is a big deal: Most “multi-agent frameworks” are just: • agents calling agents • messy loops • no real scheduling • no dependency handling This one actually looks like distributed systems engineering for AI. It introduces a real orchestration core: • Team abstraction (shared memory + message bus) • Dependency-aware task queue • Parallel agent pool with semaphores • Cascade failure handling • Tool registry + dispatch layer • Model-agnostic LLM adapters • Conversation runner per agent This is closer to Kubernetes for agents than a simple SDK. The architecture is clean: Orchestrator → Team (memory + bus + queue) → AgentPool (parallel execution) → Agents (reason + tools) → LLM adapters (OpenAI / Claude / etc) → Tool registry (shared capabilities) And the most important part: It runs in-process. No CLI spawning. No brittle subprocesses. No slow orchestration loops. Which means: • faster execution • easier deployment • serverless friendly • production ready • deterministic scheduling This is the direction multi-agent systems are heading: not chains… not workflows… but coordinated agent teams with real schedulers. If you're building: • AI copilots • autonomous workflows • dev agents • research agents • multi-step reasoning systems Study this architecture. It’s extremely clean. Bookmark this — you’ll reuse these patterns later.

@OpenBMB ·
Multi-Agent Systems (MAS) typically focus on who speaks (role assignment), but often overlook how they effectively communicate. Structural design isn't enough for strategic interaction. 🤐 Today, we present LinguaGame—new research from @TsinghuaNLP (#OpenBMB member), @UCBerkeley, and @PKU1898: A linguistically grounded, game-theoretic paradigm that treats dialogue as a strategic signaling game over intents and strategies. 🤗 Paper: https://t.co/qrpnBHXuRf 📄 arXiv: https://t.co/p2gzhZCPn3 Why it matters: 1️⃣Linguistics Meets Game Theory: Unlike rigid task-specific games, LinguaGame models dialogue as a Signaling Game grounded in Speech Act Theory. Agents don't just generate text; they explicitly infer what others want (Intents) and how they plan to achieve it (Strategies), leading to deeper mutual understanding. 🧠 2️⃣Training-Free Efficiency: No expensive model retraining required! LinguaGame introduces an inference-time equilibrium approximation algorithm. It acts as a plug-and-play layer that optimizes agent policies on the fly, making it compatible with existing LLM-based systems instantly. ⚡️ 3️⃣Smarter, Strategic Agents: Tested in complex simulated Courtrooms and Debates, LinguaGame significantly boosts communication efficiency. Human expert evaluation shows agents produce clearer, more concise, and logically sound arguments compared to standard MAS architectures. ⚖️🗣️ LinguaGame redefines agent interaction, moving from simple role-play to deep strategic reasoning for high-quality dialogue generation. #AI #THUNLP #LLM #MultiAgent #NLP #MachineLearning




@pauliusztin_ ·
MIT, Stanford, and NVIDIA researchers just built something you must hear about. AI agents may stop talking in language altogether... For context: They built a multi-agent system where agents communicate directly through latent representations instead of words. In other words... The agents pass around “thoughts” before they become text. This could transform how agent systems are designed going forward. Right now, most multi-agent systems work like this: Agent thinks Converts reasoning into text Another agent reads the text Converts it back into internal representations Repeats the cycle This process is: Slow Expensive Lossy Meaning gets compressed into language and reconstructed over and over again. So the researchers asked, "What if agents skipped language entirely?" Their architecture is called a Recursive Multi-Agent System. Instead of exchanging text, agents communicate through a lightweight connector called a Recursive Link. The connector passes latent representations directly between models before they become words. So each agent recursively builds on the previous agent’s internal reasoning state. And the craziest part? They didn’t retrain the base models. Only the tiny connector layer. The results: +8% average improvement on Math Olympiad problems Larger gains on harder reasoning tasks 2.4× faster inference 75% fewer tokens Training cost: ~$4.27 This combination of results almost never happens simultaneously. And it's a big deal because most current “multi-agent systems” are still bottlenecked by language. While language may be the interface for humans... It may not be optimal between agents. If this direction continues working, future agent architectures may look far less like conversations and far more like distributed cognition systems. Check out this video that discusses it more: https://t.co/PS3g6FrF8u P.S. Do you think future agents will still communicate through language, or will latent-space communication eventually dominate?

@mustafasuleyman ·
Shared language =/= shared meaning. And that can turn multi-agent systems into a game of telephone without any human in the loop being the wiser. Our @MicrosoftAI pre-print tests a solve: if agents don't agree on a definition, they can't use the term. The results: disagreement drops 72% - 96%. Full paper: https://t.co/ESjpwxZfDe

@suraj_sharma14 ·
5 Agentic AI architectures used in production. Not theory. Not demos. Real patterns from shipped systems. Architecture 1: The Single-Agent Workflow User input → Agent thinks → Agent acts → Response Best for: Simple Q&A, summarization, classification Stack: LangGraph + Ollama + Pydantic > Example: Meeting notes summarizer Architecture 2: The RAG Agent User query → Retrieve context → Generate grounded answer Best for: FAQ bots, documentation Q&A knowledge bases Stack: LangGraph + SQLite-vec + citations > Example: Company policy chatbot Architecture 3: The Multi-Tool Agent User request → Select tool → Execute → Return result Best for: Research, data lookup, multi-step tasks Stack: CrewAI + Tavily + calculator + custom tools > Example: Personal research assistant Architecture 4: The Multi-Agent Swarm Supervisor assigns → Workers execute → Aggregator synthesizes Best for: Complex workflows, debate, quality control Stack: LangGraph + 3+ agents + voting logic > Example: Content writer + editor + fact-checker Architecture 5: The Human-in-the-Loop Agent Agent detects uncertainty → Pauses → Requests approval → Resumes Best for: Compliance, expensive actions, sensitive operations Stack: LangGraph + approval UI + audit trail > Example: Legal document reviewer Bookmark & Repost.
@RituWithAI ·
🚨 ByteDance just open sourced the most complete AI agent runtime ever built. And it gives every agent its own computer. Not tools. Not API access. An entire computer. Real filesystem. Real bash terminal. Real package installation. Real code execution. 68,000 GitHub stars. 9,000+ forks. #1 on GitHub Trending when version 2.0 launched on February 28, 2026. It's called DeerFlow. And the name ByteDance gave it tells you exactly what it is: a SuperAgent harness. Here's the problem every AI agent framework has been quietly ignoring. Agents that run inside a chat interface have one fundamental limitation. They can plan. They can reason. They can generate text describing what they would do. They can't actually do it. DeerFlow doesn't just tell you what it would do. It actually does it, inside an isolated execution environment, with auditable results. Here's what changes when an agent has its own computer. You describe a complex task. DeerFlow's SuperAgent breaks it into specialized sub-tasks. It spawns dedicated sub-agents for each one — a research agent, a coding agent, a data analysis agent, a visualization agent. They run in parallel inside isolated Docker containers. They work simultaneously. They report back. The SuperAgent synthesizes their outputs into a finished deliverable. One sub-agent scrapes the web for funding data while another conducts competitor analysis and a third generates visualizations — simultaneously. Serial execution is a bottleneck we accept too easily. Here's what it ships with out of the box: → Sandboxed filesystem — each agent gets its own isolated environment. Nothing touches your host system → Persistent memory — the agent remembers across sessions. What you built yesterday is context today → Skills system — extensible SKILL.md files teach agents new capabilities. Drop in any skill, it loads automatically → Sub-agent orchestration — the SuperAgent spawns specialists and coordinates them dynamically → Message gateway — receives tasks from Telegram, Slack, and Feishu natively. Message your agent from your phone → Claude Code integration — one skill install, control DeerFlow directly from your terminal Here's why the star count tells the real story. AutoGPT has 167,000 GitHub stars because it's fun to play with. DeerFlow accumulated 45,000 stars in less than a month because developers can actually deploy it. That's the difference between a demo and a tool. Here's the wildest part. DeerFlow started as a Deep Research framework — and the community ran with it. Since launch, developers pushed it far beyond research: building data pipelines, generating slide decks, spinning up dashboards, automating content workflows. Things ByteDance never anticipated. That told the team something important. DeerFlow wasn't just a research tool. It was infrastructure. So they rebuilt it from scratch. DeerFlow 2.0 shares no code with v1. Complete rewrite. Built on LangGraph and LangChain. Production-grade from day one. One command to install. You now have a SuperAgent with its own computer ready to work. 68K GitHub stars. 9K+ forks. MIT License. 100% Open Source. From ByteDance. GitHub link in the comments 👇

@real_n3o ·
A model’s total token context is irrelevant. Code quality rapidly declines after the first prompt. AURA creates a swarm for every new spec (similar to a plan, but more detailed) and launches a separate subagent for every task by default. The primary agent only communicates vital information between tasks / subagents. This reduces model collapse, better manages context, and produces more secure, functional code (i.e., less slop). This is not a design pattern. This is simply how the system works. In addition to improved reasoning, this approach creates significant downstream opportunities for token efficiency by routing work to different models more effectively. An added benefit: while your agent swarm is running, you can still interact with the main agent synchronously, while watching the swarm progress in the sidekick (right panel). Here I am checking in on the lead agent on how process is going.

@AlphaSignalAI ·
ByteDance just gave each agent its own computer. DeerFlow is a new open-source agent framework. It orchestrates multiple AI agents with memory, sandboxes, and modular skills. > Researches, codes, and builds websites > Runs bash commands inside Docker > Spawns parallel sub-agents per task > Remembers you across sessions One prompt triggers a chain. A lead agent breaks the task. Sub-agents run in parallel. Results merge. You get a complete deliverable. Skills load only when needed, keeping context windows lean. Until now, multi-agent systems either shared one messy context or required brittle orchestration code. DeerFlow treats agents like workers: isolated, specialized, and reporting back structured results to a lead agent that synthesizes everything. It works with GPT-4, Claude, Gemini, DeepSeek, or any OpenAI-compatible API. MIT license. 100% open-source.

@heygurisingh ·
🚨BREAKING: Researchers just proved that AI agents can secretly collude and they built a system to catch them in the act. It's called NARCBench. They developed 5 probing techniques that read the internal activations of LLM agents to detect covert coordination between them. Results: 1.00 AUROC (perfect detection) when tested in-distribution. 0.60–0.86 AUROC when transferred zero-shot to completely different multi-agent scenarios - including a steganographic blackjack card-counting task. The wildest finding? The colluding agent's activations spike specifically when processing the encoded parts of their partner's message. Meaning the model literally lights up at the exact moment it's decoding a secret signal. No single probing technique works for all collusion types - different forms of collusion show up differently in activation space. This is the first step toward multi-agent interpretability: extending white-box inspection from single models to multi-agent systems. We're building AI agents that negotiate, trade, and make decisions together. And now we know they can conspire. This paper is beyond important. 🚨

@xelebofficial ·
From Single-Agent Memory to Multi-Agent Intelligence AI without memory operates as a reactive system. AI with memory begins to exhibit agentic behavior. Persistent context enables an AI system to retain state, learn from prior interactions, and iteratively improve decisions over time. This is the foundation of an agent. Today, memory systems from OpenAI, Anthropic, and Google are optimized for individual continuity. They store user preferences and conversational context within a single-user, single-agent loop. The next architectural shift is toward multi-agent systems. In these systems, specialized agents operate in parallel across tasks such as research, coding, and analysis. They exchange intermediate outputs, build on prior results, and form iterative pipelines of reasoning. This introduces a new requirement: a shared memory layer. Multi-agent environments require memory that supports: - cross-agent accessibility - verifiable provenance - structured queryability - persistent state across sessions This transforms memory from a feature into infrastructure. Memory enables agents to operate over time.Shared memory enables agents to coordinate, reason, and scale as a system.
@Marcello_AI ·
𝐏𝐚𝐩𝐞𝐫 𝐨𝐮𝐭! Most AI security evaluations work like this: curate a set of attack prompts, run your agent against them, and score the results. The problem is that 𝗿𝗲𝗮𝗹 𝗮𝗱𝘃𝗲𝗿𝘀𝗮𝗿𝗶𝗲𝘀 𝗱𝗼𝗻'𝘁 𝘄𝗼𝗿𝗸 𝗳𝗿𝗼𝗺 𝗮 𝗳𝗶𝘅𝗲𝗱 𝗹𝗶𝘀𝘁. They probe, adapt, and learn. So what would it look like to stress-test agents the way a real profit-seeking counterparty would? The idea, which we call 𝐩𝐫𝐨𝐟𝐢𝐭-𝐝𝐫𝐢𝐯𝐞𝐧 𝐫𝐞𝐝 𝐭𝐞𝐚𝐦𝐢𝐧𝐠, is simple: instead of handcrafting attacks, you train an opponent whose only goal is to maximise its own payoff. No judge, no attack labels. Just a scalar outcome signal. We tested this across 6 frontier models in 4 economic games, and found that agents that looked strong against static baselines became reliably exploitable once the opponent was optimised. In many cases, 𝗮𝗴𝗲𝗻𝘁𝘀 𝗮𝗰𝗰𝗲𝗽𝘁𝗲𝗱 𝗼𝘂𝘁𝗰𝗼𝗺𝗲𝘀 𝘄𝗼𝗿𝘀𝗲 𝘁𝗵𝗮𝗻 𝘀𝗶𝗺𝗽𝗹𝘆 𝘄𝗮𝗹𝗸𝗶𝗻𝗴 𝗮𝘄𝗮𝘆. What tricks did the attacker discover on its own? Things like fake protocol notices that force the victim to bid near zero in auctions. Or negotiation traps: "𝘈𝘤𝘤𝘦𝘱𝘵 𝘵𝘩𝘪𝘴 𝘥𝘦𝘢𝘭 𝘯𝘰𝘸, 𝘢𝘯𝘥 𝘐 𝘱𝘳𝘰𝘮𝘪𝘴𝘦 𝘺𝘰𝘶 𝘢 𝘮𝘶𝘤𝘩 𝘣𝘦𝘵𝘵𝘦𝘳 𝘰𝘯𝘦 𝘪𝘯 𝘵𝘩𝘦 𝘧𝘶𝘵𝘶𝘳𝘦." The good news is that a lightweight fix helped a lot. 𝗗𝗶𝘀𝘁𝗶𝗹𝗹𝗶𝗻𝗴 𝘁𝗵𝗲 𝘄𝗼𝗿𝘀𝘁 𝗮𝘁𝘁𝗮𝗰𝗸 𝗲𝗽𝗶𝘀𝗼𝗱𝗲𝘀 into a short set of prompt rules for the target agent, neutralised most of the discovered exploits. No retraining needed. The paper was accepted to two workshops: 1️⃣ Agents in the Wild at ICLR 2026 2️⃣ Strategic Engineering at AAMAS Conference 2026. This work covers LLM safety and game theory, and both communities found it relevant! We are working on how AI agents can coordinate and transact in adversarial environments, and this is a first step. You can't build robust coordination systems without first understanding how agents fail under strategic pressure. I'd love to hear from anyone working on multi-agent systems, #LLM security, or #AI in economic settings. New collaborations are always welcome, feel free to contact me! Thanks to my co-authors, @Qiaoqiao2001 (@Columbia ), @MarroSamuele (@UniofOxford ), @DavideCrapis (@ethereumfndn ) and @ARIA_research for the brainstorming sessions that helped shape this work.

@RHLSTHRM ·
This week we had our monthly AI Community of Practice meeting at @lifiprotocol. Over half our 100+ person company shows up, and it's optional. For this iteration, I invited three speakers to present their projects they have been working on internally. Fredy from QA presented his "QA agent swarm". He based this idea off the Netflix "Simian Army" concept, but AI-powered. The system creates test cases based on recent issue creations, Git commits, and previous test runs. It runs multiple agents to test UIs, APIs, etc and creates comprehensive reports, reproduction steps, and proposes fixes. It's already found dozens of bugs in the past couple weeks. Leo (@H3xept) from the Composer team presented pr-bot which is an end-to-end AI dev pipeline. It takes an issue from GitHub, breaks it into subtasks with refinement, spins up an ephemeral environment, and pushes a PR which can be iterated on with review comments. We are piloting it on a few repos internally. Andrew from the DEX aggregator team presented his agent team that is managing their entire simulation and analytics platform. He used Paperclip and created a full agent company with a CEO, product manager, front-end developer, founding engineer, etc. He's having a lot of success with the framework and burning tokens like crazy - exactly what I like to see. I actually found his work because he was using more tokens than anyone else for a couple days and I wanted to see why. Three teams, three completely different approaches, all self-initiated. This is the snowball starting to roll and it's how we'll fully orchestrate onchain finance.
@rohanpaul_ai ·
More agents are not automatically better; their value comes from giving each agent cleaner, smaller context. It help mainly when short relay messages remove distracting context without dropping information later agents need. The paper gives a testable reason why adding agents sometimes helps and sometimes hurts. They fail when later agents need details that earlier agents removed while summarizing their work. A single agent keeps every thought, action, and observation in 1 growing context, while separate agents pass compressed summaries. The paper compared single agents, single agents following the same task split, and separate agents across 18 tests on 5 benchmarks and 3 model sizes. Multi-agent systems consistently helped when handoffs could be compact and complete, especially for weaker models that struggled with crowded context. Their advantage shrank or reversed when later steps needed exact earlier details, because stronger models used full context better than compressed messages. – arxiv. org/abs/2607.16133 Title: "When Do Multi-Agent Systems Help? An Information Bottleneck Perspective"

@xelebofficial ·
2025: one developer, one AI, one function at a time. 2026: one developer coordinating a team of AI agents building an entire feature in parallel. This is the move from single-agent to coordinated multi-agent systems. How it works: - An orchestrator agent breaks down the task - Delegates subtasks to specialized agents, each running in parallel, each with its own context - Aggregates results → reviews → merges Why it matters: - Breaks past context window limits - Handles far greater complexity than any single agent - Measurable speed gains: Fountain deployed multi-agent coordination and recorded +50% faster execution The part that gets less attention: - This is not an engineering-only capability. Non-technical teams such as operations, finance, marketing are already deploying agentic workflows to automate processes that previously required developer involvement. - The prerequisite is not coding ability. It is the capacity to define intent clearly and structure tasks for execution. - The line between technical and non-technical work is being redrawn, faster than most organizations realize. Source: Anthropic 2026 Agentic Coding Report

@smoldev__ ·
Communication protocols underpin agentic commerce, not payment protocols If you take the agent thesis to its "most bullish" where it replaces a lot of the economy, then a key component of that is sub-contracting and multi-enterprise involvement in delivering one product. Tons of things involve supply chains and don't resemble "ask this person for 1 thing and pay them for making it." So if multi-agent systems take over the economy, then Agent A contracts Agent B to do something. Often times, Agent B will deliver it at competitive prices by sub-contracting Agent C, or D, or E. OK, let's say something goes horribly wrong. What A receives back from B isn't a valid product at all. It's a data exfiltration attempt. When did that happen? And by whom? A and B trust each other, but the trust doesn't extend beyond that and can't be mapped. Agentic payment standards defer the hardest question both in terms of compliance and safety. "Trust networks" have network effects and get stronger with more adoption. It's easier to imagine a single system instituting shared governance than one payment provider, which in single-hop situations can be commoditized by a new payment provider. Just as we have one TLS and lots of credit card companies.
@sabir_huss50540 ·
Everyone is selling you multi-agent AI. Swarms of specialized agents, a planner, a coder, a reviewer, all collaborating like a dream team. The pitch is everywhere. The problem is that when researchers actually measured it, the swarms often did worse than a single agent working alone. The paper is called "Why Do Multi-Agent LLM Systems Fail?" A team out of UC Berkeley, led by Mert Cemri and Melissa Pan, went and did the thing nobody selling agent frameworks wanted done. They took the most popular open-source multi-agent systems, CrewAI, AutoGen, MetaGPT, ChatDev, and ran them, then read the transcripts. Not the benchmark scores. The actual step-by-step traces of agents talking to each other, over 1,600 of them, each one thousands of tokens long. They found the whole premise leaking. The sales story is that more agents means more intelligence. Divide the work across specialists, like a human team, and the collective outperforms the individual. It sounds obviously right. It's the reason your feed is full of "agent orchestration" and "swarm" demos. And on the actual benchmarks, the paper notes flatly, the performance gains from all that machinery are often minimal. So the researchers did the slow work. Expert human annotators read 150 full traces by hand, arguing over categories until they agreed with each other at a rate most studies never reach. Out of that grind came a map of exactly how these systems break. Fourteen distinct failure modes. Three families. The first family is the system being badly specified from the start. Agents ignore their own instructions. They forget the role they were assigned. A subordinate agent quietly makes a decision that was never its call. The second family is the agents talking past each other, misalignment, ignoring what a peer just said, repeating a step that was already finished, looping on completed work while burning compute. The third family is the ending: nobody verifies the result, or the one agent assigned to check the work does a shallow pass and waves through an answer that's wrong. Read those back and something uncomfortable lands. None of these are model problems. A smarter LLM does not fix an agent that ignores its role, or two agents that talk past each other, or a verifier that doesn't actually verify. These are failures of coordination, and coordination is exactly the thing the multi-agent pitch promised to give you for free. Here's the part that should end the hype cycle and won't. The researchers tried the obvious fixes. Better role definitions. Improved orchestration. The patches helped a little and were not enough. The failures, they concluded, need more sophisticated solutions than a prompt tweak. In plain terms: you cannot buy your way out of this by stacking more agents or writing a better system prompt. The problem is structural. A human team works because people ask clarifying questions, read between the lines, and self-correct when the handoff breaks. Agents do none of that. Every handoff between them is a new door for the whole thing to fall apart, and the more agents you add, the more doors you open. The single-agent system everyone is trying to upgrade away from has one advantage the swarm can't match. It never has to agree with anyone. Before you wire five agents together, read the paper that read the transcripts. Most people building agents this year never will.

@buildwithhassan ·
someone pulled the multi-agent orchestration patterns from the claude code leak and rebuilt them from scratch as an open source framework. the interesting part is that instead of spawning a separate CLI process per agent like claude's agent SDK does, this runs everything in-process. means you can deploy it in docker, serverless, CI/CD, wherever. shared memory, message bus between agents, task queue with dependency graphs. the architecture diagram is worth studying even if you don't use the framework.

@HeyZaraKhan ·
Andrej Karpathy, Anthropic engineers, and the LangChain team are all highlighting the same broader shift: 2026 is about Context Engineering + Agent Orchestration. Just as 2025 was about Prompt Engineering. The shift isn't because prompts stopped working. It's because, as AI systems become more agentic, performance depends less on crafting the perfect prompt and more on providing the right context, tools, memory, and execution flow. That's why many leading AI teams are moving beyond prompt optimisation toward: • dynamic context retrieval • memory management • tool use (MCP, APIs, RAG) • multi-agent collaboration • verification and self-correction loops Andrej Karpathy described context engineering as "the delicate art and science of filling the context window with just the right information for the next step." LangChain has also framed context engineering as the core challenge for long-running agents, focusing on strategies like writing, selecting, compressing, and isolating context. At the same time, Anthropic's Boris Cherny argues that we're moving from manual prompting toward "loop engineering," where agents generate, critique, and refine work autonomously instead of relying on one-shot prompts. The best AI systems today don't just answer questions. They: • retrieve the right information • delegate tasks across specialized agents • use external tools • verify outputs • maintain memory across long workflows • iterate until the objective is complete A great prompt can improve one response. Great context and orchestration improve an entire workflow. That's where the real competitive advantage is heading. Found this useful? Follow @HeyZaraKhan for more AI insights like this.

@Pavan_Belagatti ·
When we talk about AI Engineering, many developers just focus on learning specific AI tools in a scattered fashion rather than focusing on the foundational principles. I was going through this video by Aish Reganti on AI Engineering (https://t.co/TPpwJgFBz5), she shares some really useful insights. At the core of every system is the large language model, which serves as a non-deterministic brain requiring specialized components like tools, knowledge, and memory to become functional. The video emphasizes that successful development depends heavily on rigorous evaluation (evals) to ensure reliability and prevent hallucinations in real-world scenarios. It further explains that while multi-agent systems can provide specialization and speed, they should only be implemented once a single agent has reached its absolute limit. Ultimately, the system design thinking and the ability to weigh architectural trade-offs are the most vital skills for building enduring AI products. This comprehensive approach shifts the focus from simple coding to creating robust, production-ready applications that can adapt to evolving business needs. Well, I would add an extra layer to this architecture that many of us usually miss, the CONTEXT layer, which becomes very useful for our AI Agents to fetch the accurate context. I think you should also watch my latest hands-on guide on Agentic SDLC, where I have explained how you can automate your entire SDLC with AI Agents - https://t.co/GstWlgT9Cm Thanks for this wonderful image Aish Reganti.

@DivyanshT91162 ·
Google just challenged one of the biggest assumptions in AI. While Microsoft, NVIDIA, and almost every AI company are racing to build multi-agent systems, Google DeepMind decided to test whether more AI agents actually produce better results. So they built 180 different multi-agent setups, gave every team the same budget, and made them compete on identical tasks. The results were surprising. For work that naturally splits into independent pieces—research, audits, large document analysis, and broad information gathering—multi-agent teams performed 80.9% better than a single AI agent. But when the work required sequential reasoning, where every decision depends on the previous step... Every multi-agent setup lost. A single AI agent consistently produced better results. The most interesting finding was how errors spread. When multiple agents worked without a coordinator, mistakes were amplified 17.2×. One incorrect conclusion quickly spread across the entire team because other agents treated it as verified. But when one dedicated coordinator reviewed and merged all outputs, error propagation dropped dramatically. The takeaway isn't "always use more agents." It's choosing the right architecture for the job. Here's the simple framework: • If your task can be divided into independent pieces, use multiple agents in parallel. • If every step depends on the previous one, a single agent is usually the better choice. • Never let multiple agents merge results without one coordinator reviewing everything. • Agent count isn't the advantage—coordination is. The AI industry is obsessed with adding more agents. Google's research suggests we've been optimizing the wrong variable all along. If you're building AI workflows today, this is one paper you shouldn't ignore. Paper:https://t.co/PwKaNpWvsG

@rcmisk ·
The multi-agent orchestration landscape in April 2026: - 7 projects, built independently, all converging on the same arch: git-worktree-per-agent + manager/worker split + heartbeats + spawn limits. Agents are drafts, not manuscripts - cheap to spawn, cheap to discard. Check them out: - Conductor: Mac app, parallel Claude Code + Codex on your Max plan (YC S24, $22M): https://t.co/YZH4OSzIj5 - wshobson/agents: 33.6K⭐ marketplace: 182 agents, 149 skills, 16 orchestrators: https://t.co/8dt8vJw1O4 - Composio AO: agent-agnostic, 7 swappable plugin slots, auto CI-failure fixes: https://t.co/GGUaYbgi8Q - Claude MPM: 47 specialists + local PM / remote workers pattern: https://t.co/7uK27KkR3o - AgentManager: 6-layer kill switch, headless, Cloud Run-ready: https://t.co/JItNKky6aG - Agent Teams (Anthropic, experimental): flag CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS in Claude Code v2.1.32+: https://t.co/g4S89MjSbV - ttal: 10 agents across 15+ repos coordinated via Telegram: https://t.co/Uqzd9Hy33d
@TechBuzzChina ·
Huawei Cloud Moves Enterprise Agents Past Demos Into Real Workflows At WAIC 2026, Huawei Cloud CEO Zhou Yuefeng argued that AI agents will gradually reconstruct the SaaS ecosystem, and deployment speed depends on how quickly the industry can accumulate and share assets like Model Context Protocols and Skills. The company announced its commercial AgentArts platform and openJiuwen open-source framework, both with over 90% kernel homology. The aim: give enterprises a path from building agents to running them 7×24 with observability, safety, and permission controls. The numbers that stood out to us: China's AI research body CAICT projects 70% enterprise penetration by 2027; openJiuwen reduced first-token latency by 22% and boosted throughput 20% in complex multi-agent coordination. Huawei is focusing on what its chief architect Ma Huibin called 'raising the lower limit' of agent performance, ensuring agents 'take fewer detours, no wrong turns' when executing long, multi-step tasks inside actual business processes. Our read: this is where the enterprise agent game moves. It is no longer about models or single-point demos; it is about data semantics, multi-agent orchestration, and production-grade reliability. Huawei is pairing a for-pay cloud platform with an open-source core specifically to let partners like Chinasoft International build industry-specific platforms (such as today's Lingxi V3 for finance) while Huawei itself pitches a managed path for larger banks. That dual-track strategy tries to lock in the standard while seeding an ecosystem. The risk: whether enterprises buy into a single-vendor 'AgentOS' when they are already juggling legacy IT and multiple AI stacks. h/t @Chinazhidx

@mernit ·
I set up hooks that run Claude Code agents based on changes in my filesystem I can upload a contract and have an agent review it, then write that analysis to another folder From there, another agent picks it up and drafts a response Each agent just reads and writes files, and the filesystem connects them This lets me build true multi-agent systems where the filesystem is the source of truth The more agents you connect through files, the more powerful your system becomes
@ethankongee ·
Most multi-agent systems add more agents. Anthropic’s advisor strategy adds judgment only when it matters. The advisor strategy keeps one main executor in charge and only brings in a stronger model at key moments. The benefit is better cost-efficiency, simpler orchestration, and often better performance without routing every step to the most expensive model. Traditional multi-agent patterns split work across multiple agents with separate roles, and often separate context. The benefit is stronger specialization, parallel exploration, and cleaner review, since one agent can critique another without inheriting all of its assumptions. There is no single best multi-agent pattern. The right choice depends on the shape of the work and your budget. Advisor strategy is great when you want a leaner system that boosts a single agent. Traditional multi-agent is better when the work is broad, long-horizon, or needs independent review.

@sabir_huss50540 ·
Microsoft will teach you to build AI agents for free. 18 lessons. Real code, short videos, no paywall. The repo is AI Agents for Beginners. It is not a tour of buzzwords. It walks you from the fundamentals through the patterns that actually ship: tool use, agentic RAG, planning, multi-agent coordination, metacognition, and taking an agent to production. Every lesson has the same shape. A written walkthrough, a short video, and Python code you can run and break. The samples are built on the Microsoft Agent Framework, the same stack Microsoft ships in production, so you are not learning toy abstractions. It covers the parts most tutorials skip. How to make an agent trustworthy. How to give it memory. How to let several agents split a task without stepping on each other. How to tell when one has failed. One honest note. The code leans on Microsoft's own platform, Azure AI Foundry, though several samples also run against any OpenAI-compatible model, including local ones. Treat the framework as one path, not the only one. MIT. Free. Eighteen lessons that turn "I use ChatGPT" into "I built an agent".

@Michael_Fenech_ ·
Here’s something most entrepreneurs haven’t realized yet. AI isn’t just helping people work faster. It’s changing how companies are built. Multi-agent systems allow businesses to deploy teams of AI agents that collaborate on work. Imagine a marketing workflow. 👉 One AI agent researches trends. 👉 Another generates campaign ideas. 👉 Another writes the copy. 👉Another schedules the posts. That’s multiple roles being handled by coordinated AI agents. This is why one entrepreneur will soon be able to operate businesses that used to require full teams.
Best Multi-Agent Systems tweets
Xholic studies what works in your niche, drafts posts in your voice and schedules them for the hours your audience is online.
$0 today · Card required · Cancel anytime
Browse all tweet collectionsLive demo: no sign-up or login needed · takes about 2 minutes
Keep exploring