agentraffic

NAIC 2026 · 3rd ACM SIGCOMM Workshop on Networks for AI Computing

Towards Traffic Modelling of Multi-Agent Systems: The Role of Coordination Topology

What does the coordination topology do to the traffic an agent system sends?

Davide Lamagna, Albert Cabellos, Alberto Rodriguez-Natal, Gábor Rétvári, Berta Serracanta

Read the paper (ACM DL) View the code Read the blog post Open the AgentVerse runner

Every number and chart on this page comes from recorded runs of the paper's experiments.

Why agent traffic matters

Agents break the link between users and requests: one task triggers an unknown number of LLM calls, timed by how the agents coordinate. That coordination topology is a design choice, studied for answer quality and token cost but not for the traffic it sends.

Does the coordination topology of a multi-agent system shape the arrival process of its LLM calls?

Background and the longer story are in the blog post →

The set-up

Same tasks, model and backend; only the topology changes.

Workflow
AgentVerse: four expert agents discuss, execute and evaluate.
Tasks
Four fixed prompts: maths, research, consulting and coding.
Example: the maths prompt
A school is designing a small amusement park with three rides. The first ride costs $500 to build and makes $20 per ride. The second ride costs $700 and makes $25 per ride. The third ride costs $900 and makes $30 per ride. The school has a budget of $2000 and wants to maximize revenue in 1 day if 100 students ride each ride at most once. Determine which rides to build and calculate the expected total revenue.
Runs
500 Sequential, 481 Star and 500 Full mesh (1,481 in all).
Model
Llama-3.2-3B-Instruct on one vLLM server, on a single host.
What is an inter-arrival time?

An arrival is the start of one LLM call. The inter-arrival time (IAT) is the gap between two consecutive arrivals in a run's discussion stage, where the topology decides who talks when. IATs are what classical traffic models are built on (a Poisson process has exponential IATs), they do not depend on the average rate, and they show bursts directly: a gap under 50 ms counts as part of a burst.

Arrivals and inter-arrival times, schematic Top: agents taking turns produce evenly spaced arrivals, a few seconds apart. Bottom: agents fanning out produce clusters of arrivals milliseconds apart (bursts), separated by long gaps while the model reasons. Taking turns (Sequential) one IAT: seconds Fanning out (Star) ← burst: IATs < 50 ms reasoning gap: seconds
Schematic, not measured data. Each tick is an arrival.
Discussion-stage message pattern for four agents (force_structure values in brackets).

Bursty arrivals

Gaps between consecutive LLM calls, pooled over all runs, on a log axis. Sequential has one mode of a few seconds; Star and Full mesh add a burst mode under 50 ms. Fits and the linear axis on Traffic →

How it was measured

The agents share one vLLM backend. Traffic is measured at four layers that share agent identifiers and timestamps, so every run's metrics join across layers.

Testbed architecture The experiment runner posts tasks to Agent A, the orchestrator on port 8101. Agent A calls the Agent B workers on ports 8102 to 8104 (A to B traffic) and the LLM backend directly (A to LLM). The workers call the LLM backend, vLLM serving Llama-3.2-3B-Instruct on port 8000 (B to LLM). Monitoring covers the application, LLM backend, container and network layers. Experiment runner run_agentverse.sh Agent A · orchestrator :8101 · POST /agentverse recruit → discuss → execute → evaluate · 3 topologies Agent B :8102 worker Agent B :8103 worker Agent B :8104 worker LLM backend :8000 · vLLM AsyncLLMEngine Llama-3.2-3B-Instruct ≤ 8 concurrent requests tasks A→B B→LLM A→LLM · recruitment, synthesis, evaluation Measured at four layers Prometheus · Grafana · Jaeger · cAdvisor · passive TCP collector Applicationcall timing, IATs, tokens LLM backendin-flight, TTFT, tok/s ContainerCPU, memory, interfaces NetworkTCP bytes per service pair Testbed architecture Experiment runnerrun_agentverse.sh tasks Agent A · orchestrator:8101 · POST /agentverserecruit → discuss → execute → evaluate A→B Agent B:8102 Agent B:8103 Agent B:8104 B→LLM A→LLM LLM backend :8000vLLM AsyncLLMEngineLlama-3.2-3B-Instruct≤ 8 concurrent requests Measured at four layers Applicationtiming, IATs, tokens LLM backendin-flight, TTFT, tok/s ContainerCPU, memory NetworkTCP bytes per pair Prometheus · Grafana · Jaeger · cAdvisor passive TCP collector
Services as deployed for the paper (infra/docker-compose.yml); four recruited experts per run.

Table 2 · Discussion-stage metrics by topology

As published in the paper; percentages are relative to Sequential. The first rows are shown, and the button below opens the rest.

Loading…

Takeaways

Topology decides whether LLM calls arrive as a steady trickle or as bursts followed by waits, and the difference reaches the model server and the network.

What it means

  • Traffic shape is a design axis, next to answer quality and token cost.
  • Rate limits and autoscaling should know the topology. The same average rate can need very different headroom.
  • Report burst-sensitive metrics, not just mean rates.

Limitations

  • One framework, one small model, four task prompts.
  • A single host, so no real network delay.
  • Fixed topologies and no tool calls.

Future work

  • More models, frameworks and multi-host deployments.
  • Mixture models for bursts and reasoning gaps together.
  • A generative model for synthetic agent traffic.

Explore further: Traffic patterns → System load → Run explorer →

Citation

If you use the framework or these results, please cite the paper.