标签：#autogen

Approval workflows do not fail only at the model layer. In a production agent, the more common failure is losing the exact paused state that a reviewer was supposed to approve. Why can a saver decide LangGraph approvals? A saver can decide LangGraph approvals because approvals depend on persisted graph state, not just a chat transcript. LangGraph interrupts pause execution inside a node, store the current state, wait until a human decision arrives, and resume the intended checkpoint with Command(resume=...) ; without a saver tied to the same thread_id , the reviewer handoff can resume the wrong point or fail to resume at all . Quick Answer: LangGraph approvals work only when the paused run is checkpointed and resumed through the same thread_id . LangSmith adds the audit layer: each trace is capped at 25,000 runs, and SaaS trace retention is documented as 400 days from ingestion . The practical rule is simple: put the checkpoint before the irreversible action. That means email sends, file writes, deploys, database mutations, support-ticket edits, purchases, payments, outbound messages, and code execution should pause before the side effect. LangChain's HumanInTheLoopMiddleware follows the same shape: inspect tool calls after model output but before execution, then allow an approve, edit, or reject decision against a checkpointed run . "Interrupts are designed to pause graph execution and resume from the saved point," according to the official LangGraph interrupts documentation . For developers, the important part is operational: the approval gate is only trustworthy if the persisted checkpoint and reviewer decision refer to the same run. LangSmith then gives the team evidence that the gate is behaving correctly. Its observability model groups execution into projects, traces, runs, and threads, which lets teams audit latency, rejection reasons, retry count, tool failures, and reviewer decisions instead of debugging from logs alone . The seed video is useful background

AutoGen's hidden token tax: why a 3-agent chat costs 15× what you expect Cost-audit series, episode 2. This series began with an AI agent that burned 136M tokens overnight → . AutoGen is Microsoft's multi-agent framework. It's genuinely good at orchestrating agents that hand off work to each other. But its default memory model has a cost shape that surprises almost every team that hits it in production. This audit shows you exactly where the tokens go, with line numbers. The setup: a 3-agent RoundRobin chat The canonical AutoGen pattern is a RoundRobinGroupChat with N agents taking turns on a task. Here's the minimal version from the docs: from autogen_agentchat.agents import AssistantAgent from autogen_agentchat.teams import RoundRobinGroupChat from autogen_agentchat.conditions import MaxMessageTermination planner = AssistantAgent ( " planner " , model_client = client , system_message = " You plan. " ) coder = AssistantAgent ( " coder " , model_client = client , system_message = " You code. " ) reviewer = AssistantAgent ( " reviewer " , model_client = client , system_message = " You review. " ) team = RoundRobinGroupChat ( [ planner , coder , reviewer ], termination_condition = MaxMessageTermination ( max_messages = 10 ), ) await team . run ( task = " Build a web scraper for Hacker News. " ) Three agents, 10 turns total (~3–4 turns each). Seems cheap. It isn't. The default context: unbounded, per-agent Every AssistantAgent gets its own UnboundedChatCompletionContext by default: # autogen-agentchat/src/autogen_agentchat/agents/_assistant_agent.py, __init__ (L708) if model_context is not None : self . _model_context = model_context else : self . _model_context = UnboundedChatCompletionContext () source UnboundedChatCompletionContext.get_messages() returns self._messages — the full list, no cap, no truncation: # autogen-core/.../model_context/_unbounded_chat_completion_context.py (a ~20-line file) async def get_messages ( self ) -> List [ LLMMessage ]: """ Get at most