AgentVerse

The workflow

An orchestrator (Agent A) runs the stages; worker agents (Agent B) carry out the experts' LLM calls against one shared model backend. A run can loop: a low evaluation score starts another iteration from recruitment.

1. Expert recruitment

   One orchestrator call reads the task and recruits experts, each with a role and a contract (what it is responsible for). The paper fixes the team at four subagents.

2. Collaborative decision-making measured

   The experts discuss the approach under one communication structure (below) for up to three rounds, or until they agree. A synthesis call condenses the discussion into a decision. The paper's traffic analysis uses the LLM calls of this stage.

3. Action execution

   Each expert carries out its part of the decision; the calls run in parallel, one per expert.

4. Evaluation

   The orchestrator scores the result from 0 to 100 and writes feedback. Below the acceptance threshold (70 by default) another iteration starts, up to the iteration limit (3 by default).

5. Final synthesis

   A last call writes the answer from the execution results.

Three topologies

Sequential and star are AgentVerse's horizontal and vertical decision-making structures; full mesh is added here as the densest case. The topology is chosen per request with force_structure.

How this repository instruments it

• Services. Agent A, the orchestrator, takes POST /agentverse on port 8101; Agent B workers on ports 8102–8104 forward subtasks to the vLLM backend on port 8000. Each runs in its own container on Docker bridge networks.
• Every LLM call is recorded in the run's response with a label that names its stage, role and round (for example vertical_reviewer_<role>_iter2 or full_mesh_message_round1_agent2_to_agent3), its UTC start time, duration and token counts, and the backend's own timing. A request ID (X-Request-ID) and the OpenTelemetry trace context travel with each call.
• Four layers, one time axis. Application: call records and traces (Jaeger). LLM backend: vLLM metrics such as in-flight requests, token throughput and queue wait (Prometheus). Container: CPU, memory and interface counters (cAdvisor). Network: a passive collector on the Docker bridge reconstructs TCP flows and exports bytes and packets per directed service pair and connection events. The layers share agent identifiers and timestamps, so a run's metrics join across them.
• Controlled variables. Topology, team size and rounds are request parameters (force_structure, force_agent_count, full_mesh_max_rounds); the task source, prompts, model and monitoring stay the same.

curl -X POST http://localhost:8101/agentverse -H "Content-Type: application/json" \
  -d '{"task": "Explain gradient descent.", "force_structure": "full_mesh", "force_agent_count": 4}'

Code: agents/agent_a/orchestrator.py (the workflow), llm/serve_llm.py (the backend and its metrics), scripts/monitoring/tcp_metrics_collector.py (the network layer).

Try it