autogen

2. AutoGen AutoGen is a framework from Microsoft for building applications with multiple AI agents. Different agents can communicate with each other and work together to solve a problem. You can use it to experiment with multi-agent AI systems. microsoft/autogen

Tool spotlight: AutoGen Microsoft's open source framework for building agents that talk to each other (and to humans) to get work done. Good for experimenting with multi-agent conversation patterns. microsoft/autogen h/t @MSFTResearch

AI Agent Frameworks Compared: LangGraph vs CrewAI vs AutoGen --- title: "AI Agent Frameworks Compared: LangGraph vs CrewAI vs AutoGen" published: true description: "Which AI agent framework to pick in 2026: release history, production failures and real costs for LangGraph, CrewAI and AutoGen." tags: ai, python, langchain, llm canonical_url: avenotech.com cover_image: avenotech.com --- Why is the most-starred framework in this comparison the one you shouldn't start a new project on in 2026? AutoGen holds roughly 60,400 GitHub stars, more than CrewAI's 57,100 and LangGraph's 39,800. It hasn't shipped a Python release in 320 days. Its last tagged version (python-v0.7.5) shipped on September 30, 2025. The repo hasn't had a commit pushed since April 15, 2026. And yet every "LangGraph vs CrewAI vs AutoGen" post being written right now is still treating it as a live option. That gap, between stars and production reality, is what this post is actually about. Not a feature matrix. Not a benchmark that can't be audited. The evidence of where each of these frameworks breaks when you run it at scale, who maintains it, and what it actually costs when things go wrong. Every fact here comes from the GitHub REST API, PyPI release history, official READMEs, vendor migration guides, and public issue trackers, all verified on 2026-08-16. Where evidence is one engineer's account rather than a measurement, it's labeled that way. Key Takeaways - AutoGen is in maintenance mode per its own README, and the Python package hasn't shipped a stable release in about 320 days. The successor is Microsoft Agent Framework, GA since 2026-04-03. New projects should start there. AG2 is a real option for legacy codebases, and it's a fork, not a rebrand. - Stars lie; installs are closer to the truth. AutoGen leads on stars (about 60K) and trails on monthly PyPI installs (about 1M). LangGraph has fewer stars (about 40K) and runs at about 71M installs, roughly 65x AutoGen. The gap survives every honest caveat. - Treat the star-to-install ratio as a freshness signal in reverse. Stars accumulate at peak hype; installs track present-tense production dependence. A high ratio means a project was once exciting and now isn't load-bearing anywhere. - Verified 2026-08-16 against LangGraph 1.2.11, CrewAI 1.15.16, AutoGen 0.7.5 and Microsoft Agent Framework 1.0. This category moves within weeks, so check those versions on PyPI before you act on any of it. - Don't pick on star counts. Pick on what shipped, what broke, and what's still being maintained. If you're scoping this for a real system rather than a spike, the framework choice is one input into building a production agent system, and it's rarely the input that decides whether the thing ships. Which agent framework should you use in 2026? The short answer, before the evidence. Pick LangGraph if you need explicit, auditable control flow and durable state, and you can staff the persistence work it brings. Pick CrewAI if you're prototyping multi-agent workflows fast and you accept that delegation is model-mediated. Don't start on AutoGen: as of August 2026 its README carries a maintenance-mode banner directing new users elsewhere. If you're already on AutoGen, your target is Microsoft Agent Framework, GA since April 2026, and the move is a rewrite rather than an upgrade. And if your workflow is three LLM calls in a loop, use no framework at all. Why that answer isn't the usual one Every framework here can call a tool and pass a message, so a feature matrix can't separate them. What separates them is what fails at scale: LangGraph breaks on checkpoint growth, CrewAI breaks on prompt-mediated delegation, AutoGen breaks on maintenance. The rest of this post is the evidence for each, with the tracker issues and post-mortems that document them. The metric that should matter (but doesn't show up in comparison posts) Stars are a lagging indicator. They record what got bookmarked at peak hype, which for AutoGen was the v0.2 launch era in 2024. Stars accumulate indefinitely and are never removed, even when a project goes quiet. Installs are the opposite: a recurring production cost, paid every time CI runs or an image rebuilds. The numbers have completely decoupled. Monthly PyPI installs, last 30 days | Category | Value | |---|---| | LangGraph | 71.1M | | CrewAI | 20.7M | | MS Agent Framework | 1.6M | | AutoGen | 1.1M | LangGraph ships roughly 71 million monthly PyPI installs. AutoGen ships about 1.08 million. That's 65x more installs for the framework with fewer stars. CrewAI sits at roughly 20.7 million monthly installs, real production usage by any reading, but a fraction of LangGraph's volume. A 65x gap in installs against a lead in stars is a strong signal about where the production load actually is. It's not a popularity contest. It's a load map. GitHub footprint: stars vs forks | Category | Stars | Forks | |---|---|---| | AutoGen | 60K | 9K | | CrewAI | 57K | 8K | | LangGraph | 40K | 7K | | MS Agent Fw. | 13K | 2K | Here's the thing that makes it a procurement problem: PyPI counts include CI pipelines and container rebuilds, so they're not user counts. Treat them as a relative signal, not an absolute. And LangGraph benefits from being pulled in transitively by the wider LangChain ecosystem, which inflates its number relative to a standalone install. AutoGen has no such tailwind, and the gap is still enormous. A 65x gap survives both caveats. A 1.2x gap wouldn't. Release cadence tells the same story from a different angle. Days since the last release, as of 2026-08-16: - AG2: 1 day - CrewAI and MS Agent Framework: 2 days - LangGraph: 5 days - AutoGen: 320 days One more cadence note before we get to the frameworks. CrewAI shipped 1.15.16 on August 14, 1.15.15 on August 12, 1.15.14 on August 8, and two releases on August 5. That's roughly ten releases in nineteen days. Whether that signals fast fixes or fast churn depends on how much you trust their release process, but either way, lock your version before you start. The mental models (and why the model matters) | | LangGraph | CrewAI | AutoGen | |---|---|---|---| | Best for | Stateful, controllable graphs | Fast multi-agent prototypes | Nothing new in 2026 | | Latest stable | 1.2.11 (2026-08-11) | 1.15.16 (2026-08-14) | 0.7.5 (2025-09-30) | | Monthly PyPI installs | 71,095,727 | 20,672,935 | 1,082,331 | | Licence | MIT | MIT | Ambiguous, see below | | Orchestration model | Explicit graph, developer-defined edges | Manager agent, prompt-mediated | Group chat, speaker selection | | Control flow | Enforced by the graph | Suggested by the prompt | Suggested by the prompt | | State | Checkpointed, persistent, JSON-shaped | Task outputs plus optional memory | Agent-held conversation history | | Default loop ceiling | 1,000 supersteps | 20 iterations per agent | String-matched termination | | Maintenance status | Active (5 days since release) | Active (2 days since release) | Maintenance mode (320 days) | | Our verdict | Default choice for production | Good for speed, verify delegation | Migrate off | Framework comparison as of 2026-08-16. Sources: GitHub REST API, PyPI, official documentation. LangGraph is a directed graph with a central state object. Agents are nodes. Edges define flow. Conditional edges handle branching. Reducers merge concurrent state updates. You draw the control flow; the LLM executes within it. The mental model is a state machine, and the framework enforces it in code. Built-in primitives: durable execution (checkpointing, resume from interruption), human-in-the-loop (interrupt the graph, collect input, resume), short-term and long-term memory. It's the most explicit of the three about where control lives. CrewAI is a role-based team. Every agent carries a role, a goal, a backstory, and tools. A Crew executes tasks sequentially or hierarchically. In hierarchical mode, an auto-generated manager agent delegates and reviews. The runtime provides the hierarchy; the delegation decisions inside it are model-mediated rather than encoded as developer-defined conditional edges. Flows, a newer primitive, are event-driven pipelines that offer more predictable production control: one LLM call per step, no autonomous delegation. AutoGen, in its current maintained mode, is a conversation-driven multi-agent runtime. Two-agent chats, group chats with an LLM-powered speaker selector, sequential and nested conversations. The successor, Microsoft Agent Framework, has the same patterns but a different architecture. AutoGen itself is not being developed. AutoGen's licence deserves a flag of its own, because it's a procurement problem rather than a technical one: GitHub detects the repo as CC-BY-4.0, the README describes a dual CC-BY-4.0 and MIT arrangement, and PyPI reports MIT. Your legal team will not enjoy that conversation. Where LangGraph breaks in production The failure point isn't the API. It isn't the tooling either. It's the checkpointer, and specifically, what happens to your Postgres instance when nobody has planned for checkpoint growth. Tadeo Donegana Braunschweig, an engineer at Tiendanube, published the clearest public account of this in April 2026. At more than 120,000 conversations per week, his team's checkpoint tables grew without bound. The open-source checkpointer ships no native TTL. An average conversation produced roughly 93 rows across four checkpoint tables after just two messages and three tool calls. Two messages, and your database is ninety-three rows heavier. In staging, checkpoint_blobs alone hit 56 MB after a single week of traffic. His summary: operational databases should store operational state, not historical exhaust. This isn't one team's unlucky configuration. On the LangGraphJS tracker, issue #1138, "How do I keep data in Postgres checkpointer database from growing unbounded?", was opened in April 2025 and is still open. LangChain's own documentation suggests running a cron job to delete old checkpoints. That's a clear statement about where lifecycle management lives. The vendor shipped a fix, and it's worth reading the numbers carefully because they get misquoted. PR #7586 introduced DeltaChannel, which stores a small sentinel value plus replay instructions instead of re-serializing the full accumulated state at every step. Checkpoint storage for a 500-turn thread | Category | Value | |---|---| | add_messages (default) | 221 MB | | DeltaChannel, snapshots every 50 | 10.53 MB | | DeltaChannel, no snapshots | 1.98 MB | The default reducer writes more than a hundred times what the tightest DeltaChannel configuration does, and the middle row is the setting most teams actually want. Three caveats before you bank on it. It landed in LangGraph 1.2.0 on 2026-05-12, it's marked beta, and it's opt-in: upgrading does nothing until you actually annotate the channels you want it on. Bloat already written to your tables stays written. Here's where it gets expensive for teams that didn't budget the operational work. LangGraph's checkpoint packages (checkpoint, checkpoint-postgres, checkpoint-sqlite) version separately from core. If you pin core and float the checkpointers, you've secured the wrong half of the stack. Budget the persistence work before launch, not after Braunschweig's three fixes generalise. Move checkpoint table creation into Alembic migrations rather than calling LangGraph's setup(), so your schema is version-controlled like everything else. Run recurring TTL deletion, paired with a weekly job that archives history to object storage if you need it for analysis. And checkpoint selectively: persist only the supervisor graph and keep sub-graphs stateless. None of this is exotic work, which is exactly why it gets skipped when an agent prototype gets bolted onto a product that already exists. The typed-state complaint Separate from persistence, there's a recurring ergonomics objection about state typing, and it needs stating carefully because the strong version of it is wrong. StateGraph accepts a real schema: TypedDict, a dataclass, or a Pydantic BaseModel if you want recursive validation. LangGraph is not untyped. The gap is one level up. LangChain's own documentation notes that the higher-level create_agent factory does not support Pydantic state schemas, and the factory is where most teams start. So the typing is available on the API you graduate to, not the one you begin on. One engineer on Hacker News put the frustration this way: > "My experience with langgraph is you spend so much time just fixing stupid runtime type errors because the state of every graph is a stupid JSON blob with very minimal typing, and it's so hard figuring out how data moves through the system." That's one account. But it's not floating free of evidence, and the evidence points at the same seam. Issue #5891 (TypeError: Type is not msgpack serializable: Send) is a create_react_agent bug, which is exactly the factory path that can't take a Pydantic schema. Issue #740 (InvalidUpdateError on state writing) names the same root cause: state shape discovered at runtime rather than at definition time. The practical read: LangGraph gives you the tools to keep state contracts honest, and it doesn't force you to use them. The risk isn't missing typing, it's contracts drifting across nodes because nothing made you declare them. Define the schema explicitly at the boundaries that matter, and most of this class of bug disappears. Where LangGraph is actually strong Explicit node structure makes execution topology predictable: the graph decides which nodes run and in what order, rather than the model deciding for itself. Token usage is a separate question, and it stays dependent on prompt size, retrieved context, tool outputs, retries and model behaviour. Predictable structure is not a predictable bill, which is why the cost section below argues what it does. What the structure does buy you is auditability. LangGraph's control flow is enforced in code, not suggested in a prompt, so when a compliance reviewer asks which agent can call which tool under what condition, you can point at an edge instead of a paragraph of instructions. Where CrewAI breaks in production Delegation. Not as a theoretical concern, but as a documented, reproducible failure mode that's been sitting in the issue tracker for over a year. The 15,759-token incident. Partha Sarkar documented this in detail: a three-agent support crew (triage, technical, billing) running in hierarchical mode received a purely technical query. The manager invoked all three agents, including billing. The billing agent's response then overwrote the correct technical answer. The run consumed 38 seconds and 15,759 tokens to produce roughly 200 tokens of output. Nothing errored. Root cause: hierarchical mode doesn't enforce conditional branching or true delegation. The manager decides, and when the model's judgment wobbles, the control flow wobbles with it. Look at what the failing workload actually was: routing a support question to the right specialist is ordinary chatbot routing, and it's the case a multi-agent crew is supposed to handle best. His fix was to replace the built-in manager with a custom manager agent carrying explicit step-wise instructions. After that change, technical-only runs took 24 seconds and about 10,000 tokens. You recover roughly a third of the cost by hand-rolling the orchestration the framework was supposed to handle. Three delegation bugs in eleven months They all show the same theme. Issue #2606 (April 2025): manager passes dicts while the schema expects strings. Issue #4783 (March 2026): manager executes tasks with its own tools and never delegates, collapsing hierarchical into sequential. Closed as not_planned. Issue #3925 (November 2025): with English task descriptions the manager delegates correctly; with Japanese descriptions the manager answers alone without delegating. Reproducible in both directions. Sit with what that last one implies. The control flow of a production system changed because the natural language of its task descriptions changed. No framework that enforces orchestration in code can exhibit that behaviour, which makes #3925 the cleanest available proof that CrewAI's hierarchy is a request written into the prompt, not a rule the runtime enforces. If you run CrewAI in a non-English market, make this your regression test before you ship. Comment counts are not an engagement signal on this repo One methodology note from reading the tracker directly, because it changes how you should read any CrewAI issue thread. CrewAI's highest-comment issues (#4877 at 271 comments, #5802 at 98, #4560 at 97, #5888 at 82) all carry zero reactions, which is an odd shape for genuinely contested threads. Reading #5802 explains it: the issue author repeatedly pitches their own product, and one commenter opens with "Hey! I'm Hermes Agent, an autonomous coding AI agent. I saw this issue and thought I could help." Use reactions and maintainer replies instead. In 2026 that's a general lesson about evaluating open source, not a knock on CrewAI specifically. The open security issue Issue #5057, "Memory content injected into system prompt without sanitization enables indirect prompt injection," has been open since March 2026 and was last updated in July. Mechanically, lite_agent.py concatenates retrieved memories straight into the system prompt. Anything written to memory inherits system-level instruction authority. It's rated Medium and cites the OWASP Agentic Security Index. Nearly five months on, it's still open. If you use CrewAI memory with any user-influenced content, apply the recommended mitigation (moving memory out of the system prompt and into user messages) before you ship. The release cadence as a risk CrewAI shipped its 1.0.0 rewrite on October 20, 2025, with breaking changes. Since then, the pace has been relentless, roughly a release every two days. That means your pinned version is end-of-life within weeks. It also means bugs get fixed fast. Weigh both. Where CrewAI is actually strong For teams that need to ship a multi-agent prototype quickly, CrewAI's higher-level abstractions are genuine. The role/goal/backstory model means you can get a working crew running in hours. The 20.7 million monthly installs reflect real production usage. And if something breaks, there's a good chance a fix is already in the next release. Where AutoGen breaks (and why "migrate off" is the right starting point) AutoGen is in maintenance mode. That's the sentence that should end the discussion for anyone starting a new project. But it's worth understanding what that means in practice, because there are teams already running on it who need to know the shape of their exit. The README carries a maintenance-mode banner verbatim: "AutoGen is now in maintenance mode. It will not receive new features or enhancements and is community managed going forward. New users should start with Microsoft Agent Framework." Last tagged release: python-v0.7.5, September 30, 2025. Last repo push: April 15, 2026. That's roughly ten and a half months without a release, and no archive banner marks the repo, so at a glance the project doesn't look dead. It just is. !A person in a dark suit standing at a large monitor showing a glowing circular data dashboard, with a lit city skyline through the window behind them Migrating off AutoGen is an architecture review, not a dependency bump. The behaviour that changes underneath you is invisible until a user reports it. The lineage is worth knowing. Original authors Chi Wang and Qingyun Wu left Microsoft in November 2024 and forked the project to AG2 (ag2ai/ag2), now at v1.0.x under Apache-2.0. Microsoft shipped Microsoft Agent Framework (MAF) 1.0 GA on April 3, 2026, developed by the core AutoGen and Semantic Kernel teams. MAF ships for Python and .NET under MIT, supports A2A and MCP interop, and has stable APIs with an LTS commitment. Official migration guides exist for AutoGen to MAF and Semantic Kernel to MAF. The migration is a rewrite, and one change is silent Microsoft's own migration guide reads as a from-scratch guide, not an upgrade guide. AssistantAgent becomes Agent, and the state semantics invert underneath the rename. AssistantAgent maintained conversation history as part of its state. Agent is stateless and does not maintain history between invocations. Nothing errors when you port the code. Your agent doesn't throw an error, it just stops remembering, and you discover it from a customer complaint. There's a second inversion in the same rename. AssistantAgent is single-turn unless you raise max_tool_iterations. Agent is multi-turn by default. So the migration turns one component from "remembers, but acts once" into "acts many times, but remembers nothing." Both inversions hide inside a port that looks like a rename (the_silent_migration_bug.py): # AutoGen: single-turn by default, and the agent holds the history agent = AssistantAgent(name="support", model_client=client, tools=[lookup]) await agent.run(task="What did I order?") await agent.run(task="And when does it ship?") # remembers the first turn # Agent Framework: the port compiles, runs, and errors on nothing agent = Agent(name="support", chat_client=client, tools=[lookup]) await agent.run("What did I order?") await agent.run("And when does it ship?") # no memory of turn one # Nothing raised. The agent just answers the second question blind, # and you find out when a customer complains. Thread state is now # yours to carry explicitly between invocations. One more gap to scope before you commit: AutoGen supports local code execution tools, and Microsoft's guide states that this feature is planned for future Agent Framework versions. Today it's a hole. Termination by string matching AutoGen terminates when an LLM generates the exact token TERMINATE. Because models are sloppy with exact tokens, they emit terminate, Terminate., Task terminated, or wrap it in markdown. None of those match, so the loop continues and you pay for every turn. Speaker selection fails the same way: if the selector's output doesn't exactly match an agent name, the same agent gets re-selected repeatedly, producing a single-agent infinite loop. Issue #12 ("force TERMINATE") dates to July 2023. On classic AutoGen, pair max_consecutive_auto_reply with a token ceiling at your gateway before you deploy anything. Note that the knob doesn't carry over to Agent Framework, which is one more reason to treat the migration as a rewrite. And a framework in maintenance mode isn't shipping fixes for any of it. One honest caveat AG2 is a real option for teams on classic AutoGen with heavy investment and no appetite for a Microsoft-shaped migration. The original authors maintain it. It's at v1.0.x under Apache-2.0, actively released, with the classic API preserved in a separate ag2-classic repo. It's a smaller ecosystem and a fork rather than a corporate-backed project, so weigh that accordingly. What multi-agent orchestration actually costs Roughly 2.3x a sequential baseline, if you pick the most accurate pattern. Kulkarni and Kulkarni benchmarked multi-agent architectures on SEC filings (arXiv:2603.22651, March 2026). Reflexive self-correcting loops achieved the highest field-level F1 (accuracy per extracted field) at 0.943, at 2.3x the cost of a sequential baseline. Hierarchical supervisor-worker reached F1 0.921 at 1.4x cost, the best cost-accuracy point in the study. A hybrid recovered 89% of the reflexive gains at 1.15x baseline cost. Relative cost of four orchestration patterns | Category | Value | |---|---| | Sequential | 1x | | Hybrid | 1.15x | | Hierarchical | 1.4x | | Reflexive | 2.3x | Those patterns map onto the frameworks directly. CrewAI's hierarchical process is the supervisor-worker row. LangGraph's cyclic graphs are how you build the reflexive loop. AutoGen's group chat is a third shape, less disciplined than either. Practically: if you're paying 2.3x for reflexion across every field in a document, you're overpaying, because the hybrid recovers most of the accuracy for a 15% premium. None of these three will stop a run on spend One finding that should shape how you budget this: across LangGraph, CrewAI and Microsoft Agent Framework, every available control knob bounds structure. None bounds money. | Framework | Knob | Default | What it actually bounds | |---|---|---|---| | CrewAI | max_iter | 20 | Iterations per agent | | CrewAI | max_retry_limit | 2 | Retries, and it multiplies spend | | CrewAI | respect_context_window | True | Summarizes to stay under context | | LangGraph | recursion_limit | 1,000 | Supersteps per execution | | Agent Framework | max_iterations | 100 | Workflow iterations | Every knob bounds structure. None bounds money. Sources: official CrewAI, LangGraph and Microsoft Agent Framework documentation, retrieved 2026-08-16. Two problems hide in that table. Default ceilings differ by 50x and nobody compares them. LangGraph allows 1,000 supersteps. MAF allows 100 workflow iterations. CrewAI allows 20 iterations per agent. CrewAI's looks tightest until you notice it's per-agent, so a five-agent crew's effective ceiling multiplies, and max_retry_limit=2 multiplies it again. A structural limit also treats a 200-token call and a 200,000-token long-context call as identical events. That's why teams file "we set max_iter, why was the bill still huge?" tickets. You capped the number of steps, but your bill is counting tokens, and the two move independently. Watching it happen isn't an option either: CrewAI's usage metrics are strictly post-hoc, available after kickoff() completes. The bill only shows up once the run has already finished and been paid. If spend is a hard constraint, put the cap at your gateway or proxy layer, where you can actually count tokens as they're spent. When to skip the framework entirely Sometimes the right agent framework is none. Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027 (press release, June 2025). Cost, unclear business value, and inadequate risk controls are the leading reasons. Cost and risk controls are exactly the two things these frameworks don't give you natively. Anthropic Engineering's "Building Effective AI Agents" makes the case most directly: the most successful implementations weren't using complex frameworks but simple, composable patterns. If your workflow is a fixed sequence of three LLM calls with a retry, a framework adds an abstraction layer, a dependency tree, and a migration risk for very little. Plenty of production AI features never need orchestration at all, and finding that out early saves the migration you'd otherwise pay for later. Useful test: write the workflow as a plain function first. If that function reads cleanly, you don't need a framework. Once it starts accumulating retries, branches, and shared state, you do, and that's when agent development becomes an architecture problem rather than a library choice. The verdict | Dimension | Winner | Why | |---|---|---| | Production reliability | LangGraph | Control flow enforced in code, not prompts | | Time to first working crew | CrewAI | Higher-level abstractions; fastest to prototype | | Real production usage | LangGraph | 71M monthly PyPI installs; LangGraph is load-bearing | | Release responsiveness | CrewAI | Ten releases in nineteen days; bugs get fixed fast | | Licence clarity | LangGraph / CrewAI (tie) | Both MIT; AutoGen reports three different answers | | Cost controls | None | None of the three halts a run on spend | | Operational burden | CrewAI | LangGraph's checkpointer needs lifecycle management upfront | | Enterprise support path | Microsoft Agent Framework | GA April 2026, stable APIs, LTS commitment | | Overall for new projects | LangGraph | Best control-to-risk ratio for production work | Verdict by dimension, as of 2026-08-16. Choose LangGraph if you need explicit, auditable control flow; you need durable execution or human-in-the-loop steps; your workflow has real branching and shared state; and your team will own the persistence work. Budget that work upfront: checkpoint TTL deletion, selective persistence on the supervisor graph only, and pinning the checkpoint packages separately from core. Its persistence is your problem, not the vendor's. Choose CrewAI if you're shipping a multi-agent prototype this quarter, you want higher-level abstractions, and you can absorb the operational risk. Pin your version. Write delegation assertions into your test suite. Apply the #5057 memory mitigation before user content touches agent memory. Ten releases in nineteen days means your pinned version is end-of-life within weeks, so plan the upgrade cadence rather than discovering it. Don't start on AutoGen if you're picking a framework today and have no legacy investment holding you there. If you're already on it, scope the MAF migration as a rewrite, put the stateless Agent behavior at the top of your test plan, and know that local code execution is a feature gap in MAF today. Its termination depends on string-matching a literal token, so pair max_consecutive_auto_reply with a token ceiling until you're off it. Choose Microsoft Agent Framework if you're a Microsoft shop, you're migrating off AutoGen or Semantic Kernel, or a vendor-backed support path with an LTS commitment is what gets the project approved. Choose no framework if your workflow is a few deterministic LLM calls and a plain function with retries is still readable. Write the function. Add a retry. Only reach for a framework when the function stops being readable. The AutoGen lesson isn't that Microsoft abandoned a project. It's that a framework stuck at v0.x was never really a product: it's a research prototype that happened to get famous. Check the maintenance status, the release cadence, and the maintainer's roadmap before you commit. Everything in this post was accurate on 2026-08-16. For this kind of tool, that's not a long shelf life. Frequently Asked Questions Is AutoGen deprecated? Not formally archived, but effectively yes. The README carries a maintenance-mode banner. Last stable Python release: autogen-agentchat 0.7.5 on 2025-09-30, about 320 days before 2026-08-16. The repo remains publicly readable and community-managed. Microsoft recommends Agent Framework for new projects. What's the difference between AutoGen and AG2? AG2 is a fork, not a rebrand. Original AutoGen authors Chi Wang and Qingyun Wu left Microsoft in November 2024 and forked the project. AG2 reached v1.0.0 in late July 2026. The classic autogen.* API lives in a separate ag2-classic repo, so 'move to AG2' is a migration. AutoGen stays with Microsoft under a mixed CC-BY-4.0/MIT licence situation; AG2 is Apache-2.0. Does LangGraph handle its own database cleanup? No. The open-source Postgres checkpointer ships no native TTL. LangChain's docs recommend a cron job to delete old checkpoints. LangGraph issue #1138 (open since 2025-04-29) reports around 100 rows per graph traversal across three tables with no maintainer resolution. Plan TTL deletion and archival before launch. Can I cap how much an agent run costs? Not within LangGraph, CrewAI or Microsoft Agent Framework. All three expose structural limits (recursion_limit at 1000, max_iter at 20 per agent, max_iterations at 100) but none halts execution on spend. CrewAI's usage metrics are post-hoc, available only after kickoff() returns. Enforce budgets at your API gateway or proxy. Is multi-agent worth the cost over a single agent? Depends on the accuracy you need. On SEC filings, reflexive loops hit F1 0.943 at 2.3x sequential cost; hierarchical hit 0.921 at 1.4x; a hybrid recovered 89% of the reflexive gains at 1.15x (arXiv:2603.22651, March 2026). Start hybrid. Escalate to reflexive only where accuracy pays for itself. Should I trust framework star counts? Treat them as a freshness signal in reverse. Stars accumulate at peak hype. Installs track present-tense production dependence. A high star-to-install ratio means a project was once exciting and now isn't load-bearing anywhere. AutoGen's ratio is the worst of the three by an order of magnitude, and the release cadence (320 days since last release) agrees. --- Originally published on the Avenotech blog, where we write about shipping AI and mobile products to production. Figures were verified on August 16, 2026; check current versions before you act on them.

Single Agent vs Multi-Agent: A Decision Framework for Enterprise Teams --- title: Single Agent vs Multi-Agent: A Decision Framework for Enterprise Teams published: true description: A practical decision framework for choosing between single-agent and multi-agent LLM architectures — state management, failure handling, human oversight, latency, cost, reliability, and security, with version-aware comparisons of LangGraph, CrewAI, AutoGen, and Microsoft Agent Framework. tags: ai, llm, agents, architecture --- Single Agent vs Multi-Agent: A Decision Framework for Enterprise Teams Teams adopting LLM agents face a recurring question: one agent with good tools, or several working together? Demos make the multi-agent answer look natural. Production is less flattering — coordination costs, state bugs, and evaluation burden arrive together, and late. This article is a decision framework around the dimensions that determine whether multi-agent designs pay off: task structure, state management, failure handling, human oversight, latency, cost, reliability, and security. It compares LangGraph, CrewAI, and Microsoft AutoGen — plus Microsoft Agent Framework, now Microsoft's recommended choice for new projects. Version note: Microsoft's AutoGen repository states AutoGen is in maintenance mode — no new features, community-managed — and recommends Microsoft Agent Framework (1.0, GA April 2026) for new projects. The comparison keeps AutoGen for existing systems and covers Agent Framework for new work. Claims reference October 2026 docs — verify before implementing. 1. Start With One Agent Build the single-agent version first. One LLM loop with a defined toolset forces the hard questions early: task boundary, real tool needs, where the agent gets stuck. Stay with one agent when: - The work is linear. Research-then-write, fetch-then-transform. Ordered steps where each output feeds the next are a pipeline; one agent running tools in sequence is simpler and easier to trace than choreographed agents. - One context window holds the problem. If documents, tool outputs, and history fit comfortably in context, splitting agents adds coordination overhead without adding capability. - One party is accountable for the output. Approvals, customer-facing messages, and financial operations need a clear owner of the final decision. - The team is new to agents. One agent teaches the failure modes — tool errors, prompt drift, runaway loops — with full visibility. Those lessons transfer upward; the reverse rarely holds. 2. When Multiple Agents Earn Their Keep None of these is automatic — each needs a concrete, checkable form. Treat them as hypotheses, not justifications. Independent subtasks exist. Parallel research across unrelated sources or concurrent calls against different systems. The operative word is independent: if step B cannot start until step A finishes, you have a pipeline — and a pipeline does not necessarily need multiple agents either. Roles genuinely differ in instructions, tools, or models. A researcher with web-search tools and a policy reviewer with compliance documents degrade each other when crammed into one system prompt. CrewAI models this directly: agents carry a role, goal, and backstory; tasks bind to agents with explicit expected outputs. Isolation is engineered, not assumed. Splitting work across agents does not by itself contain failures — a shared downstream consumer still sees every upstream error. Fault isolation has to be designed: per-agent retry budgets, timeouts, validation at handoff boundaries. The workflow is long-lived and interruptible. Processes spanning hours or days with human checkpoints need durable per-step state. LangGraph splits this into checkpointers (thread-scoped: continuity, human-in-the-loop, time travel, fault tolerance) and stores (cross-thread facts and preferences); Microsoft Agent Framework's workflow engine likewise offers checkpointing and hydration. Trust boundaries differ across steps. When workflow parts operate under different credentials or data-access scopes, separate agents give each step a clean identity. Qualification: differing permissions do not always require multiple agents — one agent can assume scoped credentials per tool call. Multiple agents earn their keep when the boundaries are stable, auditable, and worth enforcing structurally. 3. When They Don't Shared state is the actual complexity. Once agents must agree on shared facts — the current plan, the customer's intent — you have a distributed-systems problem. Conflicts and stale reads do not vanish because the components are language models; managing them is real engineering work. Debugging surface multiplies. One agent, one trace. Five agents: reconstruct who said what to whom, in which order, on which version of shared state. Budget for observability or stay with one agent. Latency stacks on the critical path. Sequential handoffs add model-call latency at every step. Count the sequential LLM calls before the user sees output; for interactive use cases this alone can disqualify a design. Evaluation gets more complex. Testing interacting agents means covering the interaction space, not just individual outputs — demanding, not impossible. The workable pattern: per-agent unit tests plus integration tests on the composed workflow. If no one can say how the system would be evaluated, it is not ready to be built. 4. Coordination Patterns, Version-Aware | Dimension | LangGraph | CrewAI | AutoGen (existing systems) | Microsoft Agent Framework (new projects) | |---|---|---|---| | Status | Actively developed | Actively developed | Maintenance mode — no new features; community-managed | 1.0 GA April 2026; Microsoft's recommended successor | | Mental model | Explicit graph: nodes are steps, edges are transitions | Role-based crew: agents with roles, goals, backstories | AgentChat teams (0.4.x): predefined collaboration patterns | Agents + orchestrations + graph-based workflows; declarative YAML support | | Coordination | You wire it: conditional edges, subgraphs | Declarative process: sequential (default) or hierarchical (requires manager_llm or manager_agent) | Round-robin, selector-based, swarm, graph flow teams | Sequential, concurrent, handoff, group chat, Magentic-One; workflow engine with branching and fan-out | | State | Typed state schema; checkpointer (thread-scoped) + store (cross-thread) | Task outputs as context; structured TaskOutput; guardrails validate handoffs | Shared context within a team; memory components | Pluggable memory: conversational history, persistent key-value state, vector retrieval | | Human-in-the-loop | interrupt(): pause anywhere, resume via Command | Per-task human_input flag | Approval steps within team design | HITL approvals, pause/resume for long-running workflows | | Failure recovery | Resume from checkpoints; inspect historical state | guardrail_max_retries; manager re-plans in hierarchical mode | Termination conditions bound execution | Checkpointing; middleware hooks for safety/compliance | | Best fit | Long-running, stateful, auditable workflows | Specialist teams with clear task boundaries | Maintaining existing AutoGen deployments | New enterprise projects, especially on the Microsoft stack | !Decision flowchart: single agent vs multi-agent architecture Alt text: Flowchart for deciding between single-agent and multi-agent architectures. From "Task arrives": if the task is not decomposable into independent subtasks, use a single agent with well-chosen tools. If decomposable but roles, models, or trust boundaries do not differ, use a single agent with parallel tool calls. If they differ and the workflow is long-lived, interruptible, or auditable, use graph-based LangGraph. Otherwise, if starting new work on the Microsoft stack, use Microsoft Agent Framework; if manager-led delegation is needed, use hierarchical CrewAI; otherwise this path applies to existing AutoGen systems only (maintenance mode). !Three multi-agent coordination patterns: sequential, hierarchical, team chat Alt text: Three multi-agent coordination patterns. Sequential: Task 1 (Agent A) flows to Task 2 (Agent B) flows to Task 3 (Agent C). Hierarchical: a manager agent that plans and validates delegates to Worker 1 and Worker 2, which return results to the manager. Team chat: Agent 1, Agent 2, and Agent 3 all read from and write to a shared team context. Do not mix API generations: AutoGen 0.2's GroupChat/GroupChatManager/max_round/TERMINATE-token idiom is superseded, and even the 0.4.x AgentChat API is now in maintenance mode. For new projects Microsoft points to Agent Framework, which unifies Semantic Kernel's enterprise foundations with AutoGen's orchestration research. 5. State: The Decision That Matters Most Three patterns: Explicit state (LangGraph). You declare the schema; nodes read and write named fields. Two persistence systems with different jobs: the checkpointer saves thread-scoped snapshots (pause/resume, time-travel inspection); the store keeps cross-thread facts. Two facts teams get wrong: MemorySaver/InMemorySaver keep checkpoints in RAM and lose everything on process restart — production needs a durable checkpointer — and resuming from an interrupt() restarts the entire node from its beginning, re-executing earlier code. Side effects before an interrupt must be idempotent, or moved after it. Validated handoffs (CrewAI). Task outputs flow downstream as context, wrapped in structured TaskOutput (raw, JSON, or Pydantic-validated). The corrective to the "no inspectable state" caricature: guardrails. A task can carry function-based or LLM-based guardrails that validate outputs before the next task runs, with configurable retries (guardrail_max_retries) — a concrete mechanism for enforcing state invariants at handoff boundaries. Conversation as state (team-chat architectures). Agents coordinate through shared conversational context — expressive, but hardest to reason about. State invariants are still enforceable, only more expensive: validation steps, structured outputs, termination conditions that halt the team on violation. Write the invariants down first, whichever pattern you choose: which facts must never be stale, who may change them, what halts the system on disagreement. 6. Failure Handling Is Designed, Not Inherited Assume every component fails; the design question is blast radius: - Tool failures (API down, malformed output): per-tool retries and fallbacks — never let one tool's failure mode become the system's. - Delegation loops (A asks B asks A): bound with termination conditions, round limits, and watchdog timers. - State corruption: one bad write poisoning downstream work. Defend with validation at write boundaries plus checkpoint inspection before resuming a failed run. - Silent quality decay: the system runs and produces mediocre output. No framework solves this; it needs evaluation harnesses with ground-truth examples on every change. 7. Human Oversight: Where the Human Sits Enterprise use makes this non-optional, and the frameworks differ in granularity: - LangGraph: interrupt() pauses anywhere — inside a node, even inside a tool — persists state via the checkpointer, and resumes via Command. Static interrupt_before/interrupt_after cover known checkpoints. Remember the re-execution rule: keep pre-interrupt code side-effect-free or idempotent. - CrewAI: the human_input flag puts human review at task boundaries — coarser-grained, simpler to reason about. - Microsoft Agent Framework: human-in-the-loop approvals with pause/resume, plus middleware hooks for compliance policies without prompt changes. Gate where the cost of being wrong exceeds the cost of waiting: production writes, customer-facing sends, financial actions. Drafting an internal summary does not earn a gate. 8. Latency, Cost, Reliability, Security: Run the Numbers Latency: count sequential LLM calls on the critical path; multiply by typical per-call latency. Redesign before building if the total exceeds the UX budget. Cost: (calls per run) × (tokens per call) × (runs per day) × (price per token). Multi-agent designs multiply the first three factors; run the arithmetic with real volumes, not demo volumes. Reliability: the textbook estimate — ten sequential steps at 95% each yield about 60% end-to-end (0.95^10 ≈ 59.9%) — rests on a simplifying independence assumption (uncorrelated failures). Correlation can shift that estimate in either direction depending on the dependence structure: shared failure causes can make joint failure more likely, while shared mitigations (common verification, retries) can make it less likely. Use the number as a starting argument for adding verification and measuring your own step reliabilities, not as a prediction. Security: more agents mean more trust boundaries. Scope credentials per agent or per tool call; treat inter-agent messages as untrusted input across trust levels (prompt injection propagates through agent teams as through microservices); log decisions for audit. One over-privileged agent is a single point of risk; five credential sets are five configurations to get wrong. A short pilot against the single-agent baseline, measured on latency, cost, and reliability, teaches more than any diagram. 9. Worked Example (Hypothetical, Illustrative) Hypothetical illustration — not a real deployment. A support-triage workflow: tickets are categorized, enriched with customer history, and routed, with a human approving SLA-changing routing. - Single-agent version: one agent, three tools (classifier, CRM lookup, router); the approval gate sits before the router tool. Every decision visible in one transcript. - Multi-agent version: separate triage, enrichment, and routing agents — worth considering only on concrete signals: slow independent enrichment calls (parallelism), or fast-changing routing rules deserving their own owner and evaluation harness (specialization, with fault isolation engineered in). "It feels more scalable" is not a signal. A measured baseline is. 10. Pre-Commit Checklist - [ ] The single-agent baseline is built and measured (latency, cost, reliability). - [ ] At least one multi-agent signal is concretely true — verified, not assumed. - [ ] State invariants are written down: what must never be stale, who may change them, what halts the system. - [ ] Persistence choice is explicit: what survives a restart, and what does not. - [ ] Framework choice is version-aware: no new enterprise builds on maintenance-mode frameworks without a migration plan. - [ ] Human gates sit where the cost of error exceeds the cost of waiting. - [ ] Termination conditions, round limits, retry budgets, and idempotency rules are defined. - [ ] An evaluation harness with ground-truth examples runs on every change. - [ ] Credential scoping and audit logging are designed, not deferred. - [ ] The team can explain behavior from traces, not just diagrams. Further Reading - LangGraph persistence (checkpointers vs stores) — docs.langchain.com - LangGraph interrupts (human-in-the-loop) — docs.langchain.com - CrewAI tasks (guardrails, human_input, structured outputs) — docs.crewai.com - CrewAI processes (sequential, hierarchical) — docs.crewai.com - Microsoft Agent Framework 1.0 announcement — devblogs.microsoft.com - Microsoft Agent Framework repository — microsoft/agent-framework - AutoGen repository (maintenance-mode notice) — microsoft/autogen - AutoGen AgentChat user guide (for existing systems) — microsoft.github.io - DEV Community guidelines for AI-assisted articles — dev.to - DEV Community editor guide (Markdown/embeds; no Mermaid established) — dev.to --- Disclosure: This article was created with AI assistance. Technical claims were checked against official framework documentation in October 2026; verify against current documentation before implementing. Proposed author: Sufyan Abbasi — IT Expert, Bitneka Technologies (13 years overall IT experience; AI and LLM technologies). Draft prepared for the author's review and approval; it should not be presented as the author's writing unless reviewed, verified, and approved.

「一人公司」多数人理解反了：不是一个人扛所有活，是把能标准化的交给 AI，自己只留判断。 先列出每天重复的动作，能脚本化的全脚本化。 microsoft/autogen

Human-in-the-Loop Control for Multi-Agent Revenue Pipelines: CrewAI, MCP and Slack Handoffs Many revenue teams have moved past a single large-prompt LLM wrapper that researches, qualifies and closes in one call. They now split the work across specialized agents built with frameworks such as CrewAI, LangGraph and Microsoft’s Agent Framework. That gain in specialization brings two engineering problems: state drift, where critical facts get lost or distorted between agent handoffs, and context fragmentation, where each tool and system sees only part of the deal. “State drift” is this article’s shorthand, not a standard term. The underlying failures are well documented. A study of multi-agent LLM systems found that they often add little over single-agent setups. It also cataloged where they break. This article covers three things: 1. Where multi-agent revenue pipelines fail. 2. How to place human-in-the-loop (HITL) checkpoints at the points where failures cost the most. 3. How to route tool calls from the Model Context Protocol (MCP) into a Slack queue where an Account Executive (AE) can claim the deal. Control planes such as InstaChime package this pattern. The code below is illustrative, and every threshold, endpoint and name in it is a placeholder. Part 1: Why Multi-Agent Handoffs Fail The Anatomy of a Multi-Agent Revenue Pipeline A typical pipeline splits work into specialized roles: - Research agent: gathers firmographics, technographics, intent signals and recent news about the account. - Qualification agent: scores the lead against a framework such as BANT or MEDDPICC. - Objection-handling agent: answers technical, security and pricing questions in the conversation. +----------------+ +---------------------+ +--------------------+ | Research Agent | --> | Qualification Agent | --> | Objection Agent | | (enrichment) | | (BANT / MEDDPICC) | | (pricing / tech) | +----------------+ +---------------------+ +--------------------+ | risk threshold or high-intent signal v +----------------------+ | HITL control layer | +----------------------+ | v +----------------------+ | AE Slack queue | +----------------------+ What the Research Says About Failure The paper “Why Do Multi-Agent LLM Systems Fail?” (Cemri et al., NeurIPS 2025) is the best empirical grounding for this problem. The authors annotated more than 1,600 execution traces from seven multi-agent frameworks. They defined a taxonomy, MAST, of 14 failure modes in three categories: - specification and system-design issues - inter-agent misalignment - task-verification failures One of those failure modes is agents failing to ask for clarification when they should. Several others involve information getting lost or ignored between agents. Each maps onto a revenue scenario. 1. Context loss at handoffs When Agent A passes work to Agent B, long histories are usually summarized or truncated. Details that matter commercially can disappear in that step: an exact budget ceiling, a data-residency requirement, a negotiated contract term. The next agent then works from an incomplete picture. 2. Errors that propagate If the qualification agent misreads a buyer’s timeline, the objection-handling agent inherits that mistake. Nothing in a plain sequential pipeline forces anyone to verify the earlier agent’s output. Task verification is one of the three MAST categories for this reason. 3. Loops and latency Conversational and delegating frameworks can bounce a question between agents. A buyer who asks about an enterprise SLA or HIPAA compliance may wait through several internal exchanges before getting an answer. Cap turns and add a timeout path that ends in a human. # Sequential CrewAI pipeline with no checkpoint: nothing verifies # one agent's output before the next agent relies on it. from crewai import Agent, Crew, Process, Task researcher = Agent( role="Lead Researcher", goal="Gather account intelligence and key buyer pain points", backstory="Senior B2B researcher.", ) qualifier = Agent( role="MEDDPICC Qualifier", goal="Score the opportunity and summarize buying intent", backstory="Enterprise sales qualifier.", ) research_task = Task( description="Research {account} and summarize pains, stack and recent news.", expected_output="A one-page account brief.", agent=researcher, ) qualification_task = Task( description="Qualify the lead using the research brief.", expected_output="A MEDDPICC summary with a score and open questions.", agent=qualifier, ) crew = Crew( agents=[researcher, qualifier], tasks=[research_task, qualification_task], process=Process.sequential, ) Where Human Checkpoints Belong A human review at every step cancels the speed advantage of automation. A review at no step lets errors reach buyers. The practical middle is to pause on specific conditions: - High-value intent: large seat counts, security or compliance documentation requests, custom-pricing requests. - Loop detection: more than N turns, or the same two agents trading messages repeatedly. - Verification failures: a validator step flags a contradiction with CRM data. - Irreversible actions: sending a contract, committing to a price or SLA, scheduling an executive meeting. [ Agent pipeline ] | ( policy evaluation ) | +------------+-------------+ | | [ within bounds ] [ rule triggered ] | | continue agents pause + snapshot state route card to AE in Slack When a rule fires, the system should do four things: 1. Pause the workflow. 2. Persist a snapshot of the state: conversation, tool-call log, scoring metadata and the proposed next action. 3. Present that snapshot in a place the AE already works. 4. Wait for an explicit decision: take over, approve the agent’s plan, or correct the context and reroute. What Frameworks Already Provide You do not have to build the pause-and-resume mechanics from scratch. - CrewAI supports HITL in two ways. Flows have an @human_feedback decorator, available from version 1.8.0. Crews have a webhook-based approach in which a task pauses in a “Pending Human Input” state until feedback is submitted. CrewAI Enterprise adds routing, escalation policies and SLA settings for Flow HITL, including automatic fallback responses when no human replies in time. - LangGraph provides interrupt() with a checkpointer, so a graph can stop at a node and resume with a human-supplied value. - AutoGen is now in maintenance mode. Microsoft moved it there in October 2025, and its README directs new users to the Microsoft Agent Framework, which reached 1.0 general availability in April 2026. A community fork, AG2, continues separately. Use Agent Framework for new builds and plan a migration if you run AutoGen today. A CrewAI Flow with a human review step: from crewai.flow.flow import Flow, start, listen from crewai.flow.human_feedback import human_feedback class QualificationFlow(Flow): @start() def qualify(self): # Call your qualification crew here and return its summary. return "Account: Acme Corp | Seats: 450 | Score: 0.94 | Ask: custom VPC" @listen(qualify) @human_feedback(message="Review this qualification before outreach continues:") def review(self, summary): return summary And a LangGraph pause that carries a state snapshot to a reviewer: from langgraph.types import interrupt, Command def ae_review(state: dict) -> dict: # Pauses the graph (requires a checkpointer) and surfaces the payload. decision = interrupt({ "account": state["account"], "proposed_action": state["proposed_action"], "transcript": state["messages"][-10:], }) # Resumed later with Command(resume={"action": "approve" | "takeover" | "edit", ...}) return {"ae_decision": decision} Part 2: Routing MCP Tool Calls to an AE Queue MCP in a Revenue Stack The Model Context Protocol is an open standard for connecting AI models to tools and data. Anthropic created it, and in December 2025 donated it to the Linux Foundation, where it is a founding project of the Agentic AI Foundation alongside Block’s goose and OpenAI’s AGENTS.md. In a revenue stack, an agent with an MCP client can discover and call tools such as CRM lookups, enrichment, billing queries and calendar availability. +-------------------------------------------------------------+ | MCP host: agent / LLM + MCP client | +----------------------------+--------------------------------+ | MCP (JSON-RPC) v +-------------------------------------------------------------+ | MCP servers | | CRM | enrichment | billing | calendar | quoting | +-------------------------------------------------------------+ Most tool calls are routine. A few signal real buying intent: a request for an enterprise quote, a security questionnaire, or a custom proposal. Those are the calls worth routing to a person. What the MCP Specification Says About Humans The MCP tools specification recommends that applications keep a human in the loop who can deny tool invocations. It suggests visual indicators when tools run and confirmation prompts for operations. This is a recommendation, not a mandate. The protocol deliberately leaves the approval interface and workflow to implementers. The most recent specification revision (2026-07-28) also lets a server respond to tools/call with an InputRequiredResult, which signals that more input is needed before the call can complete. That mechanism suits human approval and gives you a protocol-level place for the pattern described here. Check the current spec for exact semantics before building on it. Design: Intercept at a Tool Boundary Put the policy check where tool calls pass through a single point: an MCP server wrapping a sensitive tool, or a gateway in front of several servers. Buyer Agent / MCP client Gateway or server Slack (AE queue) | | | | |-- "500 seats?" --->| | | | |-- tools/call --------->| | | | request_quote |-- evaluate policy | | | |-- post claim card ---->| | | |<-- AE clicks "Claim" --| | |<-- result: handoff ----| | |<============== AE continues the conversation ========================| Step 1: Define the policy The rules should be simple, explicit and auditable. These thresholds are examples: HIGH_INTENT_TOOLS = {"request_enterprise_quote", "request_security_docs", "book_executive_demo"} SEAT_THRESHOLD = 100 # illustrative INTENT_THRESHOLD = 0.85 # illustrative; produced by your own scoring model def needs_human(tool: str, args: dict) -> bool: return ( tool in HIGH_INTENT_TOOLS and (args.get("seat_count", 0) > SEAT_THRESHOLD or args.get("intent_score", 0) > INTENT_THRESHOLD) ) Step 2: Post an actionable Slack card Slack’s Block Kit supports interactive buttons in messages. Incoming webhooks can post Block Kit layouts, but they cannot receive button clicks. To handle clicks, create a Slack app with interactivity enabled and either a public Request URL or Socket Mode. Slack expects your app to acknowledge each interaction within 3 seconds. Do the slow work, such as resuming the workflow, asynchronously. from slack_sdk import WebClient slack = WebClient(token="xoxb-...") # load from a secret manager def post_claim_card(channel: str, session_id: str, summary: str): slack.chat_postMessage( channel=channel, text="High-intent request needs an AE", # notification fallback blocks=[ {"type": "section", "text": {"type": "mrkdwn", "text": f"*High-intent request detected*\n{summary}"}}, {"type": "actions", "elements": [ {"type": "button", "action_id": "claim_deal", "style": "primary", "text": {"type": "plain_text", "text": "Claim deal"}, "value": session_id}, {"type": "button", "action_id": "allow_agent", "text": {"type": "plain_text", "text": "Let the agent continue"}, "value": session_id}, ]}, ], ) +-----------------------------------------------------------+ | High-intent request detected | | Account: Acme Corp | 450 seats | Enterprise tier | | Ask: dedicated VPC, 24/7 phone SLA | | Agent state: paused, waiting for a decision | +-----------------------------------------------------------+ | [ Claim deal ] [ Let the agent continue ] [ View thread ]| +-----------------------------------------------------------+ Step 3: Handle the click and resume from slack_bolt import App app = App(token="xoxb-...", signing_secret="...") @app.action("claim_deal") def on_claim(ack, body, client): ack() # must happen within 3 seconds session_id = body["actions"][0]["value"] ae_id = body["user"]["id"] # Record the claim, notify the pending tool call, and hand the thread to the AE. resolve_pending(session_id, {"status": "claimed", "ae": ae_id}) Step 4: Gate the tool itself This sketch uses the official Python MCP SDK’s FastMCP helper. The server pauses the tool call until an AE decides or a timeout expires. import asyncio from mcp.server.fastmcp import FastMCP mcp = FastMCP("revenue-tools") PENDING: dict[str, asyncio.Future] = {} # use a durable store in production def resolve_pending(session_id: str, decision: dict): fut = PENDING.get(session_id) if fut and not fut.done(): fut.set_result(decision) @mcp.tool() async def request_enterprise_quote(session_id: str, account: str, seat_count: int, intent_score: float = 0.0) -> str: """Generate an enterprise quote, routing high-intent requests to an AE first.""" args = {"seat_count": seat_count, "intent_score": intent_score} if needs_human("request_enterprise_quote", args): fut = asyncio.get_running_loop().create_future() PENDING[session_id] = fut post_claim_card("#ae-queue", session_id, f"{account}: {seat_count} seats, intent {intent_score:.2f}") try: decision = await asyncio.wait_for(fut, timeout=180) # SLA window except asyncio.TimeoutError: return "An account executive has been notified and will follow up shortly." finally: PENDING.pop(session_id, None) if decision["status"] == "claimed": return "Your request has been passed to a senior team member who will join shortly." return f"Draft quote prepared for {account} ({seat_count} seats)." Treat this as a starting point. A production version needs these additions: - Slack request-signature verification, which Bolt handles for you. - Idempotent claims, so two AEs cannot claim the same deal. - Persistent state, so a restart does not lose pending approvals. - An audit log of every decision. - Authentication and per-tool authorization on the MCP side. Comparing Approaches | Concern | Unmanaged multi-agent pipeline | Single LLM with tool calling | Pipeline with HITL control layer | | --- | --- | --- | --- | | Handoff errors | Can compound across agents; no built-in check | Fewer handoffs, but limited scope | Policy rules and review points catch selected cases | | Escalation | Usually discovered afterward in logs | Often a static fallback | Explicit, rule-based, routed to a named queue | | Tool interface | Framework-specific functions | Provider-specific function schemas | MCP tools, usable across clients | | Human role | Post-hoc debugging | Hard-coded approvals | Approve, take over, or correct, with state attached | | Main cost | Silent failures | Limited capability | Added latency and operational overhead | The last row matters. A human checkpoint adds delay and requires staffing. It pays off only when the rules are narrow enough that AEs see few, valuable cards. Measuring Whether It Works Avoid adopting benchmark claims from vendors, including this one. Measure your own pipeline against a baseline: - Time to claim: median and 90th-percentile time from card posted to AE claim. - Claim rate and timeout rate: a high timeout rate means the queue is under-staffed or the rules fire too often. - Override rate: how often AEs reject or correct the agent’s proposed action. This is your best signal of agent quality. - Loop and timeout incidents: conversations ending in a buyer drop-off after exceeding turn limits. - Conversion and cycle time for escalated versus non-escalated opportunities, with a control group where possible. Practical Guidance - Start narrow. Gate one or two irreversible or high-value actions, then widen based on override data. - Keep policies deterministic. Rules like “seat count over N” or “more than N turns” are testable. Model-confidence signals are less reliable, so treat them as supplements. - Snapshot what the human needs. Include the transcript, tool-call log, CRM facts and the agent’s proposed next step, so the AE doesn’t rebuild context. - Design for timeouts. Define what the buyer sees if no AE responds, and make that path graceful. - Secure the boundary. Verify Slack signatures, scope tool permissions, and treat tool inputs and outputs as untrusted, since prompt injection is a known risk for agents that call tools. - Plan for framework churn. AutoGen’s move to maintenance mode shows that framework choices age quickly. Keep your policy and handoff layer independent of any one agent framework. Conclusion Multi-agent pipelines can speed up research and qualification, but research on multi-agent systems shows that failures cluster around specification, coordination between agents, and missing verification. A narrow, rule-based human checkpoint at high-value or irreversible moments addresses those failures directly. MCP gives tool calls a common interface that such a checkpoint can sit in front of. Slack gives AEs a place where they already work. The aim is a pipeline where agents handle volume and people handle the decisions that decide deals. Sources - Cemri et al., “Why Do Multi-Agent LLM Systems Fail?”, NeurIPS 2025 - Model Context Protocol specification: Tools - CrewAI documentation: Human-in-the-Loop and Human Feedback in Flows - microsoft/autogen on GitHub (maintenance-mode notice) - IT Brief, “Anthropic donates MCP to new Agentic AI Foundation” - Slack API documentation: Handling user interaction --- Originally published at instachime.com

Top 10 AI GitHub Repos Going Viral RIGHT NOW (Oct 8, 2026) #Shorts Today's fastest-rising AI repositories on GitHub, ranked by real momentum from the last 24-48 hours rather than all-time size. Every repository was checked against the GitHub API on 8 October 2026, and the list is dominated by agent infrastructure: orchestration runtimes, control planes, memory layers, security skills and fast decision engines. Ranked list (the video counts down 10 → 1): 1. addyosmani/agent-skills — addyosmani/agent-skills 2. paperclipai/paperclip — paperclipai/paperclip 3. tt-a1i/archify — tt-a1i/archify 4. usestrix/strix — usestrix/strix 5. mvanhorn/last30days-skill — mvanhorn/last30days-skill 6. microsoft/autogen — microsoft/autogen 7. heygen-com/hyperframes — heygen-com/hyperframes 8. khoj-ai/khoj — khoj-ai/khoj 9. VoltAgent/awesome-agent-skills — VoltAgent/awesome-agent-skills 10. google/skills — google/skills Disclaimer: rankings are based on GitHub trending and star-velocity snapshots for 8 October 2026 and change daily. Star counts are approximate and move fast — they were read from the GitHub API on the day of recording. Licences are mentioned only where a repository clearly states one. New AI GitHub Top 10 every day — subscribe for tomorrow's list. #GitHub #AI #Agents #OpenSource #LLM #MachineLearning --- More AI content --- ⚡ AI in 60 Seconds: youtube.com 🤖 Hermes Agent News: youtube.com 🔬 Top 10 HF Models: youtube.com 💬 Join our Discord community: discord.gg