Moonshot AI’s Kimi K2.5 puts a provocative idea back on the table with its Agent Swarms capability. The promise is not just another multi-agent demo. It is a system where the model acts as its own orchestrator, decomposing a goal into sub-tasks, spinning up specialist agents on demand, running them in parallel, and merging results into a coherent outcome. 

For enterprise leaders who have been watching CCaaS and CXA vendors build increasingly elaborate flow graphs and node-based Agent Builders, this raises an obvious strategic tension. If the model can orchestrate itself, why are we still drawing workflows? 

What Agent Swarms Appears to Be 

Agent swarms are basically the system thinking through the job as it goes, repeatedly deciding what to do next and spinning up helper agents in real time, rather than following a prebuilt flowchart. You provide a goal, and a supervising instance of the model generates a plan, allocates work to sub-agents, and coordinates tool use. The system creates roles dynamically, such as policy researcher, account history analyzer, fact checker, and exception handler. Sub-agents work in parallel, and the supervisor resolves conflicts and decides whether to branch further or converge. 

Moonshot frames the orchestration as learned behavior, not hard-coded role templates. In other words, the model is trained to decide in real time how to break a goal into sub tasks and delegate them to helper agents, then combine the results, rather than following a pre-scripted handoff pattern.  

Why This Collides with Today’s Agent Builder Approach 

Most CXA agent builders reflect a philosophy of pre-definition. You define an orchestrator, define specialist sub-agents, and wire them through a flow graph mixing deterministic procedures and generative steps. This is legible, testable, and explainable to compliance. But it is also rigid. The flow expresses what you thought the world would look like. Unfortunately, customers often don’t cooperate and getting a problem resolved is often messier than predicted.  

Agent swarms assume the world is messy and that the best response is dynamic decomposition and adaptive exception handling. In certain categories of work, swarms will likely replace flow graphs. 

Where Swarms Will Win First 

Expect swarms to dominate in work that is tool-heavy, long-horizon, and naturally parallel. This type of work includes complex back-office resolution, returns requiring policy interpretation and shipment traces, claims reconciliation across multiple systems, travel rebooking with multiple constraints, and fraud triage pulling signals from different places. 

In these cases, the customer interaction is not the work, but rather the trigger. The work is gathering evidence, validating constraints, and assembling a defensible next best action. Swarms will also appeal for rapid prototyping, letting teams skip weeks of workflow authoring. 

Why Flow Graphs Are Not Going Away 

Enterprises need control, audit, and liability containment. Three friction points will slow a full shift to self-directed swarms. These points of friction are latency and cost in real-time voice (spinning up dozens of sub-agents mid-call risks slow responses), governance and defensibility (a flow graph is a compliance artifact that teams can review and approve), and change management (enterprises need stable boundaries for what is allowed and how incidents are replayed). 

Swarm workloads can also get expensive if unconstrained. In enterprise CX, the platform layer will likely become the cost governor, enforcing max steps, max tokens, and allowed actions, so the swarm’s autonomy shows up as better planning inside a bounded action space rather than open-ended, and potentially costly, exploration. 

The likely future is not simple replacement, but a shift in what the platform optimizes for. 

From Workflow Designer to Action Space Designer 

If swarms are good planners, the differentiator moves from how you author the plan to how you define the allowed actions. Action space design is the menu of things an agent is permitted to do, plus the rules governing that menu, such as the tool catalog, data access boundaries, permissions and preconditions, typed contracts, safety constraints, and escalation rules. 

In a swarm world, the model plans freely inside this action space. The enterprise still determines the perimeter and guardrails. Autonomy becomes better planning and faster parallel investigation, not freelancing. The platform that owns action space governance owns the enterprise relationship. 

Implications for CCaaS and CXA Roadmaps 

Expect two possible architectural moves. First, platforms may gradually decouple planning from execution, supporting multiple planners including external foundation model orchestrators.  

The clearest way to understand the shift is to imagine a single UI change. In the agent configuration screen, there is now a dropdown called “Planner.” You might choose Flow Graph (the existing node builder), Vendor Orchestrator (the platform’s own LLM planner), or External Swarm (a foundation model endpoint that does dynamic decomposition). Everything else in the product is organized around controlling what any of those planners can do. 

Second, Agent Builder will evolve from authoring flows to curating the action space, enforcing contracts, and measuring outcomes. Flow graphs will remain as policy constraints and safety rails rather than the primary expression of intelligence. 

What to Watch 

The real question is not whether swarms are clever, but whether they can be made dependable under enterprise constraints. Watch for competition on observability, evaluation harnesses that test autonomy against policy, permissioning that maps to enterprise roles, and interoperable tool contracts. 

Dynamically generated swarms of agents offer flexibility, but they also raise the premium on control. The future may be less about drawing the whole path and more about defining the safe action perimeter inside which the system can find its own way. 

Categories: Articles