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
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.
Problem
Collider phenomenology workflows span heterogeneous tools and calculations, motivating an architecture that supports language-driven, end-to-end execution without package-specific code.
Method
ColliderAgent combines hierarchical multi-agent reasoning with Magnus Blueprints that expose identical, auditable execution through web, CLI, and SDK interfaces.
Results
ColliderAgent reproduced expected cross-section trends, resonance lineshapes, energy hierarchies, and future-muon-collider reach contours across representative benchmarks.
Takeaways & Limitations
The validated workflows support a portable architecture for automating and auditing collider-phenomenology calculations across agent frameworks and execution modes.
Takeaways & Limitations
Across three runs per benchmark, outputs were often consistent with targets, but occasional failed reproductions were observed.
Abstract
from arXiv · showhide
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.
- 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.
- 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.
- Sub-agent roles: The collider-simulator sub-agent writes MadGraph scripts and cards, then executes parton-level simulation, parton showering with Pythia, and detector simulation with Delphes.
- 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.
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.
- 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.
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.
- 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.
- Blueprints: 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.
- 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.
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.
- 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].
- 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].
- 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.
- 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].
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.
- Three independent reproduction runs were performed for each benchmark prompt using Claude Code with the skill-based multi-subagent framework and Claude Opus 4.6.
- Each run began from a clean sandbox containing only prompt.md and minimal runtime dependencies, preventing reuse of prior context.
- ColliderAgent often produced outputs consistent with target benchmark results across the independent runs.
- Occasional failed reproductions were also observed, alongside representative successful results in the main and supplemental figures.
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.
- ColliderAgent requires a coding agent, Docker, and uv; Node.js is optional but enables the Web UI for job monitoring.
- No HEP-specific software must be installed on the host, although Windows users need a Bash-compatible shell for the commands.
- Installation involves cloning the repository, installing the package, and automatically obtaining the magnus-sdk dependency.
- 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.
- The full multi-agent architecture currently requires Claude Code, while Codex and Cursor support a skills-only version.
- 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.
- Custom BSM models require one-time Wolfram Engine license activation inside the container, and cloud deployment supports Slurm-based HPC clusters.
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.
- Benchmark prompts were deliberately detailed to maximize reproduction success and make task specifications explicit.
- Some technical definitions, such as Standard Model field-strength tensors, can be omitted in practical prompts.
- Users can instead ask the agent to retrieve experimental data or identify selection cuts from specified ATLAS and CMS papers.
- The scalar-leptoquark example asks for the signal mej distribution, illustrating a prompt that specifies a concrete phenomenological output.
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.
- Scalar Leptoquark Model: Its signal is resonant single-leptoquark production through lepton–quark fusion, followed by decay to an electron and jet using the LUXlep PDF.
- Scalar Leptoquark Model: The scalar-leptoquark analysis applies Delphes ATLAS simulation, reconstructs events in LHCO format, and computes mej after lepton, jet, and missing-energy selections.
- Scalar Leptoquark Model: Because Pythia8 cannot backward-evolve leptons from proton PDFs, initial-state leptons are replaced by photons before showering and detector simulation.
- ALP EFT: The ALP workflow applies selection cuts and produces a normalized missing-transverse-momentum histogram using 50 bins from 0 to 1000 GeV.
- ALP EFT: 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.
- U1 Leptoquark Model: The U1 benchmark uses ATLAS and CMS detector simulations to construct mT signal templates from experiment-specific selections and binned data.
- U1 Leptoquark Model: 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.