Collective Agents Raise the 11-Dimensional Kissing Number Bound to 604

James Zou centers his case for agent environments on a new construction for the 11-dimensional kissing number problem: agents in EinsteinArena produced a configuration of 604 non-overlapping spheres around a central sphere. The presentation identifies the prior displayed best lower bound as 593, attributed to DeepMind in 2023.

The kissing number problem asks how many equal spheres can touch a central equal sphere without overlapping. The answer is two in one dimension and six in two dimensions, but higher-dimensional cases become much harder. In 11 dimensions, the relevant achievement is a valid construction that improves the lower bound, not a proof of the exact optimum.

The history shown in the presentation puts the 604 construction in context. The bound rose from 582 to 592 in 2022 after roughly four decades at the earlier level, then to 593 the following year. Zou says agents in the arena reached 604 within a few days.

He does not describe this as a single model independently solving the problem. Individual agents, including what he calls GPT 5.5 and Claude models, could not solve it alone, he says. The important feature was that agents could take one another’s submissions, refine them, and exchange information about approaches through the arena.

A slide tracing the solution’s lineage depicts successive changes to the kissing-number construction. Alongside it, a forum exchange records one agent asking whether others had found different contact counts, attempted an SDP-based route, or identified algebraic structure that could guide an integer realization. Another agent reports that perturbation variants had converged on the same topology, identifies the SDP route as a high-value next step, and says the needed structure appeared unlike plus-or-minus-one coordinates.

The exchange illustrates the kind of shared search record Zou considers useful: agents could make attempted paths, stable observations, and plausible next directions visible to other participants. The arena’s verifier and leaderboard supplied the separate mechanism for checking submissions and scoring their quality.

Zou also connects stronger high-dimensional sphere constructions to coding systems, including error-correction methods for information transfer. The 604 result is presented not only as an advance on a longstanding mathematical problem, but as a construction with potential engineering relevance.

The arena design is not limited to mathematical constructions. In a GPU-kernel setting, Zou says, the collaboration and leaderboard remain, while the back end changes: agents submit kernels; the system compiles them in a sandbox, benchmarks them on service-owned GPUs with fresh inputs, and scores correctness and speed.

One leaderboard shown in the talk puts a submission called warp-tiled-v3 at 2.41x the prior baseline. Zou says the approach has produced speedups above 2x on some production kernels across multiple shapes and hardware types, and that the improved kernels are already in production at Together AI.

The kernel environment also initializes agents with different roles and priors. These include an occupancy and profiling role that uses Nsight Compute to identify warp stalls; a memory specialist focused on coalescing, shared memory, bank conflicts, and L2 reuse; and specialists in tiling and scheduling, tensor-core mapping and precision, correctness and numerics, and documentation and research.

Those roles direct agents toward different aspects of the same performance problem. Zou’s account is that specialized agents can collaborate and compete, while the common benchmark provides immediate feedback on whether a change is correct and faster.

The mathematical and kernel examples support Zou’s broader distinction between an agent workflow and an agent environment.

A workflow tells an agent how to work through a prescribed sequence of prompts, tools, instructions, and steps. Zou characterizes this approach as rigid, hard to adapt to unfamiliar situations, and limiting of exploration and creativity. An environment instead supplies the conditions in which agents act: information and tools, constraints and permissions, and incentives or rewards.

That does not mean removing structure. EinsteinArena is deliberately structured around public, checkable problem solving. It presents agents with curated open problems, a discussion forum, and a leaderboard. Each selected problem must, in Zou’s description, satisfy two conditions: it should matter to an existing community of human researchers, and it must allow a well-defined deterministic verifier to assess proposed solutions.

Within an individual problem, agents receive a precise problem statement and can submit a solution whenever they choose. The verifier returns a quality score in real time; the leaderboard updates accordingly. Agents can inspect and download other agents’ solutions, while the forum lets them ask questions, offer recommendations, and discuss routes through the problem.

EinsteinArena is designed to be agent-native in another sense: agents can access it through its software stack and documentation, but human accounts are prohibited. Entry requires solving a dynamic puzzle intended to establish that the participant is an AI agent. Zou says any agent can otherwise participate freely.

The point is not that the arena leaves agents unconstrained. Its constraints, resources, public solutions, and feedback rules are the environment. Rather than fixing a sequence of actions in advance, the system lets agents choose problems and approaches within those conditions.

Zou says that within weeks of the arena’s March launch, agents had found 11 new best solutions to open problems—results he describes as better than previous human solutions or solutions requiring more specialized AI tools. The 604-sphere construction is his principal example of the collective intelligence he believes this kind of environment can elicit.

DSGym, or Data Science Gym, applies the same environmental premise to evaluating and training data-science agents. Zou presents it as a unified execution environment rather than a single benchmark.

It aggregates heterogeneous datasets and tasks into a common task object and API. Agents interact with data through real code execution using a CodeAct-like interface. Docker workers mount input data read-only while agents write to separate workspaces, and the environment can run multiple containers in parallel.

The starting problem was benchmark shortcuts. Zou says his group initially sought to incorporate existing, widely used data-science benchmarks, but found that many tasks could be answered without analyzing the underlying data. A model could reason from prompts or other cues and still score well.

As Zou puts it, “sometimes up to 20 to 50% of the tasks can be solved without actually looking at any of the underlying data.”

The slides compare model performance with and without data access across QASData, DAEval, and DiscoveryBench. Models retain meaningful performance without access, which Zou treats as evidence that those tasks do not consistently test the data-science work they are meant to measure.

DSGym’s answer is task curation and shortcut filtering. For scientific analysis and discovery, the group works from recently published papers, curates corresponding data and tasks, and has human scientists and experts review each task. For predictive modeling, it looks through recent Kaggle competitions that remain open and have high-quality datasets and evaluations, then adapts selected competitions into the common environment.

The presentation distinguishes the wider environment from its curated task suite. One slide describes more than 18,000 tasks across fields including biology, geography, medicine, finance, ecology, chemistry, machine learning, and economics. A separate DSGym-Tasks slide describes more than 1,000 curated tasks spanning more than 10 scientific domains and more than 10 file types, including 90 DSBio bioinformatics tasks. Those tasks are audited to remove cases solvable without touching the data.

Zou says frontier models still achieve less than 50% accuracy on DSGym tasks. His conclusion is that the suite is not saturated, and that domain knowledge and scientific grounding—not coding ability alone—are a central bottleneck in real research tasks.

DSGym is also intended to generate training data. When an agent produces a trajectory of code-based actions, Zou explains, the environment can execute the code and verify the result. These execution-verified trajectories can then be used to fine-tune models.

The distinction is material in Zou’s account: the training examples are not merely saved model outputs. They are traces that have been run in the environment. Execution therefore evaluates the agent’s work and creates checked material for later training.

The slide characterizes the 4B model fine-tuned on 2,000 execution-verified trajectories as best in class among the open-source models shown. Zou emphasizes the practical implication of that scale: the resulting open-source models are small enough to run locally on a laptop or personal computer.