PaperlayerView exact revision on arXiv

Source-linked AI summary

An End-to-end Architecture for Collider Physics and Beyond

Shi Qiu, Zeyu Cai, Jiashen Wei, Zeyu Li, Yixuan Yin, Qing-Hong Cao, Chang Liu, Ming-xing Luo, Xing-Bo Yuan, Hua Xing Zhu

arXiv:2603.14553v1hep-phcs.AIcs.MAhep-ex

TL;DR

ColliderAgent addresses end-to-end collider phenomenology through a portable, language-driven multi-agent architecture coupled to the Magnus execution backend. It reproduces representative collider benchmarks across energies, models, and collider environments, though occasional failed reproductions occur.

Abstract

from arXiv · show

We present, to our knowledge, the first language-driven agent system capable of executing end-to-end collider phenomenology tasks, instantiated within a decoupled, domain-agnostic architecture for autonomous High-Energy Physics phenomenology. Guided only by natural-language prompts supplemented with standard physics notation, ColliderAgent carries out workflows from a theoretical Lagrangian to final phenomenological outputs without relying on package-specific code. In this framework, a hierarchical multi-agent reasoning layer is coupled to Magnus, a unified execution backend for phenomenological calculations and simulation toolchains. We validate the system on representative literature reproductions spanning leptoquark and axion-like-particle scenarios, higher-dimensional effective operators, parton-level and detector-level analyses, and large-scale parameter scans leading to exclusion limits. These results point to a route toward more automated, scalable, and reproducible research in collider physics, cosmology, and physics more broadly.

Skill-Based Multi-Agent Implementation

The implementation realizes ColliderAgent as a skill-based multi-agent system in which specialized sub-agents execute separate phenomenological stages with task-specific context and shared progress records.

Portability

  • Portable Agent Skills package workflow guidance, parameter conventions, references, templates, and example invocations for each task.The skill structure is designed to support reuse across agent frameworks.Source: Skill-Based Multi-Agent Implementation · p. 7

Architecture

  • ColliderAgent decomposes user requests into specialized phenomenological stages handled by separate sub-agents with task-specific context.This operationalizes the multi-agent architecture rather than assigning the entire pipeline to one agent.Source: Skill-Based Multi-Agent Implementation · p. 7

Sub-agent roles

  • The model-generator sub-agent translates LaTeX Lagrangians into FeynRules model files, validates them, and generates UFO output for downstream tools.Validation includes syntax checks, FeynRules consistency tests such as Hermiticity, and test loading in MadGraph.Source: Skill-Based Multi-Agent Implementation · p. 7
  • The collider-simulator sub-agent writes MadGraph scripts and cards, then executes parton-level simulation, parton showering with Pythia, and detector simulation with Delphes.Source: Skill-Based Multi-Agent Implementation · p. 7

Coordination

  • Each sub-agent operates with an independent local context, while structured Markdown progress records preserve essential information for subsequent stages.The records coordinate sub-agents while minimizing context overhead.Source: Skill-Based Multi-Agent Implementation · pp. 7–8

ADK-based Reference Implementation

A Python implementation using Google ADK provides a reference system for orchestrating collider-phenomenology workflows and demonstrates portability of the skill-based architecture.

Purpose

  • The Google ADK reference system provides a partially reproducible baseline for tool use, staged execution, and intermediate-result management.It complements the Claude-Code-based implementation used in the work.Source: ADK-based Reference Implementation · p. 8

Tooling

  • Filesystem tools manage instructions, reference documents, intermediate artifacts, and structured outputs, while MCP tools connect the agent to Magnus for environment setup and remote execution.This combination lets the agent traverse the workflow from model construction through domain-specific computation.Source: ADK-based Reference Implementation · p. 8

The Magnus Execution Backend

Magnus is a unified execution backend that packages phenomenological jobs into auditable, reusable workflows accessible to both researchers and agents through common interfaces.

Platform structure

  • Magnus combines an execution layer for containerized jobs, a sedimentation layer for reusable knowledge, and a collaboration layer for shared governance.The platform is described as open-source infrastructure for human and AI job submission.Source: The Magnus Execution Backend · p. 8

Blueprints

  • A Blueprint is a typed Python function whose signature defines parameters and whose body specifies job submission.Magnus introspects the function to generate a web form, validate CLI inputs, and expose a programmatic API.Source: The Magnus Execution Backend · p. 8
  • The same Blueprint can run through the web UI, terminal, or SDK with identical execution semantics and full auditability.This implements deliberate human-agent symmetry in the execution platform.Source: The Magnus Execution Backend · p. 8

Workflow refinement

  • Agents can create, execute, evaluate, and refine Blueprints, turning one-off experiments into reusable workflows guided by Skills.The five ColliderAgent Blueprints in this work were authored by domain experts and bundled with the Magnus SDK.Source: The Magnus Execution Backend · p. 8

Additional Benchmarks

Additional literature reproductions extend ColliderAgent validation across hadron- and lepton-collider settings, multiple interaction structures, resonance phenomena, and sensitivity projections.

Validation scope

  • Across three independent runs per benchmark, outputs were often consistent with targets, although occasional failed reproductions occurred.Representative successful reproductions appear in the main text and supplemental material.Source: Additional Benchmarks · p. 8

Heavy Majorana Neutrino

  • The heavy Majorana neutrino benchmark reproduced cross-section curves at 7, 8, and 14 TeV, including the expected energy hierarchy and mass dependence.The reproduction agreed with Ref. [42].Source: Additional Benchmarks · p. 8

General Z′ Benchmark

  • The general Z′ benchmark reproduced mass-dependent cross sections and the normalization difference between the Sequential SM and Z′ψ scenarios.The result was consistent with Ref. [47].Source: Additional Benchmarks · p. 8

KK Graviton at a Lepton Collider

  • The KK graviton benchmark at a lepton collider reproduced the resonant lineshape of the Kaluza-Klein graviton tower across scanned energies.This tested higher-rank tensor interactions and multiple massive resonances in an e+e− environment.Source: Additional Benchmarks · pp. 8–9

U1 Leptoquark at a Muon Collider

  • The U1 leptoquark benchmark at a muon collider targeted 95% CL exclusion and 5σ discovery contours in the (mU1, β32L) plane at √s = 3 and 14 TeV.The agent successfully reproduced reach contours consistent with Ref. [50].Source: Additional Benchmarks · p. 9

Details on Physics Validation

Physics validation used three independent reproduction runs per benchmark prompt in an isolated environment. ColliderAgent often matched target benchmark results, but occasional failures occurred.

III. INSTALLATION AND USAGE

ColliderAgent is installed with a coding agent, Docker, and Python tooling, while Magnus supplies the backend and containerized HEP software. The full multi-agent architecture currently requires Claude Code.

  • Magnus dispatches workflows through collider and mma-het container images containing the MadGraph, Pythia, Delphes, MadAnalysis, Mathematica, and FeynRules toolchains.Source: §III · p. 9
  • ColliderAgent requires a coding agent, Docker, and uv; Node.js is optional but enables the Web UI for job monitoring.Source: §III · p. 9
  • No HEP-specific software must be installed on the host, although Windows users need a Bash-compatible shell for the commands.Source: §III · p. 9
  • Installation involves cloning the repository, installing the package, and automatically obtaining the magnus-sdk dependency.Source: §III · p. 9
  • Launching Magnus starts the backend server, creates a local database and user account, and registers bundled blueprints; Node.js can also launch a Web UI.Source: §III · p. 9
  • The full multi-agent architecture currently requires Claude Code, while Codex and Cursor support a skills-only version.Source: §III · p. 10
  • A minimal end-to-end test plots the parton-level dilepton invariant-mass distribution for pp → l+l− at the 14 TeV LHC in the Standard Model.Source: §III · p. 10
  • Custom BSM models require one-time Wolfram Engine license activation inside the container, and cloud deployment supports Slurm-based HPC clusters.Source: §III · pp. 10–11

Example Natural-Language Prompts

The benchmark prompts explicitly specify literature-reproduction tasks and their technical inputs, but routine use can omit some details or ask the agent to retrieve information from cited papers.

2. Scalar Leptoquark Model

The examples define scalar-leptoquark, ALP EFT, and U1-leptoquark workflows spanning detector-level distributions, parton-level histograms, and exclusion contours. They specify model inputs, simulation settings, selections, and statistical procedures.

Scalar Leptoquark Model

  • The scalar leptoquark LQeu is a scalar SU(2)L-singlet color triplet with electric charge Q = −1/3 and real Yukawa coupling λeu.Source: §2 · p. 11
  • Its signal is resonant single-leptoquark production through lepton–quark fusion, followed by decay to an electron and jet using the LUXlep PDF.Source: §2 · p. 12
  • The scalar-leptoquark analysis applies Delphes ATLAS simulation, reconstructs events in LHCO format, and computes mej after lepton, jet, and missing-energy selections.Source: §2 · p. 12, §4.1 · p. 12
  • Because Pythia8 cannot backward-evolve leptons from proton PDFs, initial-state leptons are replaced by photons before showering and detector simulation.Source: §3.3 · p. 12

ALP EFT

  • The ALP workflow applies selection cuts and produces a normalized missing-transverse-momentum histogram using 50 bins from 0 to 1000 GeV.Source: §4.2 · pp. 12–13, §4.1 · p. 13
  • The ALP EFT benchmark fixes fa = 1000 GeV, ma = 0.001 GeV, and c̃W = 1, with parton-level analysis at the 13 TeV LHC.Source: §2 · p. 13

U1 Leptoquark Model

  • The U1 benchmark uses ATLAS and CMS detector simulations to construct mT signal templates from experiment-specific selections and binned data.Source: §2 · p. 14, §3.1 · p. 14
  • The exclusion analysis scales signal events with the coupling, profiles nuisance parameters, combines ATLAS and CMS likelihoods, and plots the excluded region above the curve.Source: CMS selection · p. 15, §3.3 · p. 15

Related papers

Loading 2603.14553v1…