Paper deep dive
HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols
Farzad Habibi, Juncheng Fang, Faisal Nawab
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 90%
Last extracted: 10/2/2026, 8:21:51 AM
Summary
The paper introduces HakiCC, an LLM-driven multi-agent pipeline that automatically designs, verifies, and optimizes application-specific concurrency control (CC) protocols. The system operates in two stages: Stage 1 uses a multi-agent system to generate and verify conflict-serializable protocols based on workload descriptions, while Stage 2 employs an LLM-driven evolutionary loop to optimize throughput. Evaluated on TPC-C and AuctionMark workloads, HakiCC produced ten protocols, all of which were conflict-serializable, with Stage 2 yielding average throughput gains of +50.6% for TPC-C and +92.2% for AuctionMark.
Entities (20)
Relation Signals (27)
HakiCC → ensuresproperty → Conflict-Serializability
confidence 95% · All ten are conflict-serializable after Stage 1
HakiCC → evaluatedon → TPC-C
confidence 95% · We evaluate HakiCC on TPC-C and AuctionMark as target workloads
HakiCC → evaluatedon → AuctionMark
confidence 95% · We evaluate HakiCC on TPC-C and AuctionMark as target workloads
HakiCC → hascomponent → Novelty Evaluator Agent
confidence 95% · the Novelty Evaluator Agent ( 4 ○ ) scores and packages the verified protocolP.
HakiCC → hascomponent → Proposer Agent
confidence 95% · Stage 1 (top): the Proposer Agent ( 1 ○ ) generates a design specification Sfrom workload inputW
HakiCC → hascomponent → Generator agent
confidence 95% · the Generator Agent ( 2 ○ ) translatesSinto an executable implementation
HakiCC → hascomponent → Serializability Verifier
confidence 95% · the Serializability Verifier ( 3 ○ ) checks correctness and returns failure traces to the Generator via a debug loop
HakiCC → uses → LLM
confidence 95% · HakiCC, an LLM-driven multi-agent pipeline that automatically designs, verifies, and optimizes concurrency control protocols
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Large language models (LLMs) have recently been applied in systems research as a tool to reduce human-intensive engineering effort through cost-efficient automation. Decades of research have produced a rich landscape of concurrency control (CC) protocols, each encoding distinct trade-offs in correctness, throughput, and abort behavior. However, most applications in practice default to 2PL or OCC, because selecting and adapting a protocol to a specific application requires expert knowledge that is rarely available to application designers. This is a wasted opportunity, as an application-specific CC protocol can yield significant performance advantages over a generic baseline, but designing one requires deep expertise in CC protocol design. In this paper, we propose HakiCC, an LLM-driven multi-agent pipeline that automatically designs, verifies, and optimizes concurrency control protocols tailored to a given target application. HakiCC provides a two-stage pipeline. In Stage 1, a multi-agent system takes a workload description as input and generates an application-specific CC protocol implementation, which is iteratively repaired and verified for conflict-serializability. In Stage 2, the verified protocol is further optimized for that application through an LLM-driven evolutionary loop targeting correctness and throughput. We evaluate HakiCC on TPC-C and AuctionMark as target workloads, producing and reporting ten application-specific CC protocols. All ten are conflict-serializable after Stage 1; Stage 2 improves throughput for every protocol, with average gains of +50.6% for TPC-C protocols and +92.2% for AuctionMark protocols.
Tags
Links
- Source: https://arxiv.org/abs/2610.00889v1
- Canonical: https://arxiv.org/abs/2610.00889v1
Trouble viewing inline? Open PDF directly →
Full Text
88,864 characters extracted from source content.
Expand or collapse full text
HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control Protocols Farzad Habibi University of California, Irvine habibif@uci.edu Juncheng Fang University of California, Irvine junchf1@uci.edu Faisal Nawab University of California, Irvine nawabf@uci.edu Abstract Large language models (LLMs) have recently been applied in sys- tems research as a tool to reduce human-intensive engineering effort through cost-efficient automation. Decades of research have produced a rich landscape of concurrency control (C) protocols, each encoding distinct trade-offs in correctness, throughput, and abort behavior. However, most applications in practice default to 2PL or OCC, because selecting and adapting a protocol to a specific application requires expert knowledge that is rarely available to ap- plication designers. This is a wasted opportunity, as an application- specific C protocol can yield significant performance advantages over a generic baseline, but designing one requires deep expertise in C protocol design. In this paper, we propose HakiCC, an LLM-driven multi-agent pipeline that automatically designs, verifies, and optimizes con- currency control protocols tailored to a given target application. HakiCC provides a two-stage pipeline. In Stage 1, a multi-agent system takes a workload description as input and generates an application-specific C protocol implementation, which is itera- tively repaired and verified for conflict-serializability. In Stage 2, the verified protocol is further optimized for that application through an LLM-driven evolutionary loop targeting correctness and through- put. We evaluate HakiCC on TPC-C and AuctionMark as target workloads, producing and reporting ten application-specific C protocols. All ten are conflict-serializable after Stage 1; Stage 2 im- proves throughput for nine out of the ten protocols, with average gains of +50.6% for TPC-C protocols and +92.2% for AuctionMark protocols. Keywords Concurrency Control, LLM, OLTP 1 Introduction Concurrency control (C) is a foundational component of On- line Transaction Processing (OLTP) systems, defining how con- current transactions access shared data while preserving correct- ness and maximizing performance [5]. Decades of research have produced a rich landscape of protocol classes, each with hundreds of variants, including Two-Phase Locking (2PL) [5], Optimistic Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. SIGMOD ’27, Huntington Beach, CA, USA © 2027 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-X-X/2018/06 https://doi.org/X.X Concurrency Control (OCC) [27], Multi-Version Concurrency Con- trol (MVCC) [4,31], and Serializable Snapshot Isolation (SSI) [6], each encoding a distinct trade-off between blocking behavior, vali- dation overhead, abort rate, and correctness guarantees [64]. De- spite this variety, designing a new application-specific C protocol remains expert-driven and labor-intensive, since engineers must reason simultaneously about correctness under concurrency, per- formance under target workloads, and implementation correctness, all without automated assistance. Protocol optimizations such as commutativity-aware conflict resolution [38], static transaction analysis [17,19,58], and deterministic pre-ordering [16,53] all re- quire deep knowledge of both the application’s transaction logic and the underlying C mechanism, making them difficult to scale without domain expertise. LLM-driven agents have recently demonstrated the ability to reason about workloads and protocols, generate executable imple- mentations, and iteratively repair them under feedback [8, 47, 60]. LLM-driven evolutionary frameworks extend this capability by maintaining a population of candidate programs, using the LLM to propose mutations, and selecting survivors via a benchmark harness, enabling automated exploration of complex design spaces that are too large for exhaustive search [2,37,43,46]. These de- velopments raise a question. Can an LLM-driven pipeline design an application-specific concurrency control protocol from scratch, ver- ify its correctness, and optimize it for performance without human feedback in the loop? We answer this question with HakiCC, a two-stage multi-agent pipeline for automated application-specific C protocol design and optimization. In Stage 1, a multi-agent system takes a target workload as input, designs a protocol tailored to it, generates an exe- cutable implementation, and iteratively repairs the implementation until it passes correctness verification. In Stage 2, an LLM-driven evolutionary optimizer refines the verified protocol through re- peated cycles of mutation and benchmark evaluation, resulting in an optimized protocol. We instantiate HakiCC on two standard OLTP benchmarks— TPC-C [52] and AuctionMark [14]—producing and reporting five protocols per workload. All ten generated protocols are conflict- serializable. Structural analysis across 150 binary design criteria shows that the generated protocols span multiple design families: the five TPC-C protocols generated by HakiCC (SALVO, LP-OCC, PESC, DCOV, SADL) mostly cluster around the OCC/Silo [27,54] family, with SADL being the exception by combining deterministic pre-ordering with commutative escrow locking. The five Auction- Mark protocols generated by HakiCC (TREAD, WGC, HSL, PVL, SAPL) include an MVCC-based design (TREAD), a deterministic partitioned-scheduling design (WGC), two OCC-family designs 1 arXiv:2610.00889v1 [cs.DB] 1 Oct 2026 SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USAFarzad Habibi, Juncheng Fang, and Faisal Nawab (HSL, PVL), and a 2PL-OCC-Escrow hybrid (SAPL). Stage 2 opti- mization improves throughput for most of the ten protocols, with average gains of +50.6% for TPC-C protocols and +92.2% for Auc- tionMark protocols, while maintaining correctness. This paper makes the following contributions. • We introduce HakiCC, the first end-to-end two-stage LLM-driven pipeline that designs, implements, verifies, and optimizes application- specific concurrency control protocols. • We demonstrate that the pipeline produces correct protocols. All ten generated implementations pass our conflict-serializability verifier, and Stage 2 optimization improves performance without sacrificing correctness in nine out of the ten cases. •We show that application-conditioned design induces structural diversity across generated protocols, spanning pessimistic, opti- mistic, versioned, deterministic, and semantic design paradigms, as confirmed by pairwise Jaccard similarity analysis over 150 design criteria. • We describe ten C protocols generated by HakiCC and catalog the concrete improvements discovered by Stage 2 evolution. Section 2 provides background, Section 3 presents the HakiCC design, Section 4 reports the evaluation, Section 5 describes the ten generated protocols, Section 6 discusses related work, and Section 7 concludes the paper. 2 Background and Motivation 2.1 Database Transactions A database transaction is a sequence of operations executed as a single unit of work, ensuring the ACID properties (atomicity, con- sistency, isolation, and durability). A concurrent schedule is serial- izable if it is equivalent to some serial execution of its transactions; conflict-serializability is a stricter form that requires preserving the relative order of all conflicting operations [5]. Concurrency Control Protocols. Concurrency control proto- cols govern the interleaving of concurrent transactions, ensuring conflict-serializability [5]. Prior work has produced a diverse pro- tocol landscape. Two-Phase Locking (2PL) prevents conflicts by acquiring locks before releasing them; Optimistic Concurrency Control (OCC) [27] defers conflict detection to commit time; Multi- Version Concurrency Control (MVCC) [4] maintains multiple data versions to allow readers to proceed without blocking writers; and Serializable Snapshot Isolation (SSI) [6] extends snapshot isolation to full serializability via anti-dependency tracking. More recent hybrid designs combine primitives from multiple families, for ex- ample, pairing optimistic validation with commutative-operation escrow [38] to reduce abort rates on counter-heavy workloads. Despite this variety, designing a new C protocol remains a fundamentally human-driven process, requiring simultaneous deci- sions about conflict detection timing, version management, abort policy, and application-specific optimizations that interact in non- obvious ways. Correctness Verification. A candidate C protocol must be eval- uated not only for performance but also for correctness under concurrent execution. For conflict-serializability, correctness can be checked by constructing a precedence graph퐺 퐻 =(T,퐸)over an execution trace, where each node is a committed transaction and each edge(푇 푖 ,푇 푗 )represents a conflicting operation pair in execution order [5,40]. An execution is conflict-serializable if and only if퐺 퐻 is acyclic; a detected cycle constitutes a serializability violation. HakiCC uses precedence-graph cycle detection as its correctness verification mechanism. This check is empirical and schedule-dependent, so passing it certifies serializability on the observed interleavings rather than all of them; we mitigate this with a heavily concurrent verification suite designed to surface unserializable behavior. 2.2 LLM-Driven Agentic Optimization Agentic Workflows. Machine learning has long been used in systems research to guide design choices, tune configuration pa- rameters, and model workload behavior [22,26,35,39,55,56,61]. More recently, LLM-based coding agents have demonstrated an ability to rapidly prototype implementations, propose algorithmic variations, and repair code under structured feedback, substantially reducing the manual engineering effort required for complex soft- ware tasks [1,7,8,28,47,60]. These capabilities extend naturally to multi-step agentic workflows, where LLM calls are composed into pipelines that handle tasks requiring iterative reasoning, code generation, and feedback-driven repair. Systems algorithms in general, and C protocols in particular, are well-suited for automated design because their quality can be eval- uated against objective, well-defined metrics such as throughput for performance and conflict-serializability for correctness [10–12]. This closed evaluation loop eliminates the need for human judg- ment when scoring a candidate, making the labor-intensive process of proposing, implementing, and refining protocols a natural fit for LLM-driven agentic workflows. Evolutionary Frameworks. Beyond code generation, recent work has begun to automate portions of the research process itself, iter- atively proposing hypotheses, running experiments, and refining designs through feedback-driven agentic loops. A particularly powerful instantiation of this idea is the LLM- driven evolutionary framework [2,37,43], in which an LLM main- tains a population of candidate solutions (code, designs, or algo- rithms) and iteratively improves them through an evolutionary loop. In each iteration, the LLM generates and mutates candidates; an evaluator scores them via tests, benchmarks, or formal verifi- cation; and the highest-scoring candidates seed the next round. This loop combines the generative capabilities of LLMs with the systematic coverage of evolutionary search, enabling exploration of design spaces that are too large for exhaustive enumeration and too structured for purely random search. HakiCC builds on this paradigm, applying it to C protocol optimization rather than initial design. The C protocols’ design space is structured by design principles; however, it is too large for exhaustive search, making LLM-driven evolutionary refinement a better fit for improving existing protocol implementations against performance benchmarks. Rather than designing protocols from scratch, this evolutionary optimization takes a protocol produced by HakiCC’s agentic design workflow as its starting point and evolves that implementation for performance. 2 HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control ProtocolsSIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA User Concurrency Control Implementation Concurrency Control Protocol Proposer 1 Larger Models Proposer Agent Workload Specification Concurrency Control Design Specification Concurrency Control Protocol Developer Broken Implementation 2 Generator Agent Serializability Verification 3 Runnable Implementation Unserializable Implementation [+Feedback ] Debug Loop Serializable Implementation Stage 1 Stage 2 4 Optimized Concurrency Control Implementation Novelty Evaluator Agent Cheaper and smaller models OpenEvolve Evolutionary Coding Agent 5 Benchmarks Check for performance 6 Figure 1: Overview of the HakiCC two-stage pipeline. Stage 1 (top): the Proposer Agent ( 1 ○ ) generates a design specification Sfrom workload inputW; the Generator Agent ( 2 ○ ) translatesSinto an executable implementation; the Serializability Verifier ( 3 ○ ) checks correctness and returns failure traces to the Generator via a debug loop; and the Novelty Evaluator Agent ( 4 ○ ) scores and packages the verified protocolP. Stage 2 (bottom): OpenEvolve ( 5 ○ ) iteratively optimizesPagainst performance benchmarks ( 6 ○ ), yielding the final optimized protocolP ∗ returned to the user. 3 HakiCC Design We present HakiCC, an LLM-driven multi-agent pipeline that cre- ates, implements, and iteratively improves concurrency control protocols with minimal human intervention. Figure 1 shows the HakiCC pipeline, which operates in two stages: the first designs and implements a correct concurrency control protocol based on application specification; the second optimizes it for performance using an agentic evolutionary framework. While we focus on con- currency control as a concrete and well-scoped target, the pipeline can be adapted to other distributed data management protocols. With minimal modifications to workloads and correctness checks, the same framework supports AI-assisted protocol discovery and refinement more broadly. 3.1 Stage 1: Proposal Pipeline Stage 1 designs and implements a correct concurrency control pro- tocol tailored to a given workload specification—a set of transaction types and a target database schema. The stage takes as input the workload specification and produces as output a verified, conflict- serializable protocol ready to serve as an input for the evolutionary optimization in Stage 2. To maximize design quality, Stage 1 em- ploys larger LLMs and typically completes within minutes. 3.1.1Workflow. Stage 1 takes as input an application specification W—a set of transaction types and stored procedures—and produces as output a verified, executable C protocol implementationPthat is conflict-serializable under the verification suite. We model the pipeline as a stateful directed graph퐺= (푉,퐸)[28], where each node is either an LLM invocation or a program execution. The pipeline consists of four components: a Proposer agent (labeled 1 ○ in Figure 1) that generates a protocol specification, a Generator agent ( 2 ○ ) that translates it into executable code, a Serializability Verifier ( 3 ○ ) that checks correctness and routes failures back to the Generator agent, and a Novelty Evaluator agent ( 4 ○ ) that scores the verified protocol. Step 1. The Proposer ( 1 ○ ) agent takesW(application-specific work- load) as input and generates a protocol specificationS, which de- fines read/write visibility rules, commit logic, expected correctness guarantees, and required metadata. The agent is prompted as an expert in database concurrency control research and design and is givenWalongside instructions to design a C protocol optimized for the given application, in the required output format. The for- mat mandates a protocol name, a core design idea, a performance rationale tied to the target transactions, a correctness justification, and a step-by-step execution description covering transaction be- gin, read/write operations, conflict handling, and commit/rollback logic. Requiring the Proposer to justify correctness pushes it toward designs it can defend as serializable, leading to more serializable designs. The Proposer is additionally given the protocols HakiCC has already produced for the application and instructed to differ from them, steering generation toward unexplored design space rather than re-generating prior solutions. Step 2. The Generator ( 2 ○ ) agent takesSas input and generates an executable implementationP. The Generator is prompted as an expert software engineer specializing in database concurrency control protocols, with instructions to implement the protocol specification 3 SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USAFarzad Habibi, Juncheng Fang, and Faisal Nawab Protocol Summary Report (S) Class <C_NAME > extends ConcurrencyControl: State: // protocol -specific (locks , versions , timestamps , ...) @Override begin(database) → Transaction: // initialize transaction context @Override read(txn , key , database) → Value: // acquire read permission; return value @Override write(txn , key , value , database ): // acquire write permission; buffer updates; apply updates @Override commit(txn , database) → CommitResult: // validate; apply buffered writes; release state return success | abort @Override rollback(txn , database ): // undo writes; release state Figure 2: Template for the Stage 1 output: a concrete subclass of theConcurrencyControlabstract class. The LLM fills in the State block and all method bodies according to the protocol specification 푆 produced by the Proposer. Sas a concrete subclass of the provided concurrency control inter- face in the codebase. The interface defines five abstract methods— begin,read,write,commit, androllback(see Figure 2, discussed in Section 3.1.2). If no syntactically valid implementation is extracted, the Gen- erator re-invokes the LLM and iterates until one is produced. The implementationPis then passed to the next step, Serializability Verifier 3 ○ . Failures are returned to the Generator for repair. Separating proposal from implementation allows each compo- nent to use an LLM suited to its demands: the Proposer can invoke a frontier-class model to maximize design quality, while the Gener- ator can use a model optimized for code synthesis and repair. This decoupling also allows the Proposer to reason about protocol logic without being constrained by implementation details, fostering more structurally diverse designs. Step 3. The Serializability Verifier ( 3 ○ ) receivesPand evaluates it against a verification suite of concurrent workloads (detailed in Section 4.1), each executed by푁parallel worker threads for a duration of 휏 . Correctness is checked by constructing a precedence graph 퐺 퐻 =(T,퐸)over the operation trace, whereTis the set of com- mitted transactions and(푇 푖 ,푇 푗 ) ∈ 퐸if and only if푇 푖 and푇 푗 have a conflicting operation pair in execution order [5]. An execution is conflict-serializable if and only if퐺 퐻 is acyclic; a detected cycle constitutes a serializability violation. If any workload produces a cycle or a runtime failure, a structured error report—including the trace and cycle description—is fed back to the Generator agent ( 2 ○ ), which retakes control and attempts a repair. This generate-and- verify loop continues until all workloads pass, at which point the verifiedP is forwarded to the next step. Step 4. In the next step, the Novelty Evaluator ( 4 ○ ) agent serves as the final quality check in Stage 1. This agent scores the verified protocolPby prompting an LLM as an expert database researcher ...Textual Protocol Design Initial C Code Verification Feedback Debugged C Code N Verification Feedback Debugged C Code N+1 Textual Protocol Design Initial C Code Debug Summary Debugged C Code N+1 Initial Context Message History Context After Compaction Figure 3: HakiCC context compaction strategy. and judge to evaluate it against both established C designs and the protocols HakiCC has already generated for the application, so that redundancy with either is penalized and the accepted protocols stay diverse. The judge independently scores four dimensions and assigns one penalty, each on a [0, 1] scale, which are accumulated into the final novelty scoreN(P): N(P)= 0.40푛 orig + 0.30푛 dist + 0.15푛 impl + 0.15푛 arg − 0.15푝 rebrand (1) where푛 orig is conceptual originality,푛 dist is distance from known protocol families,푛 impl is implementation distinctiveness,푛 arg is originality of the correctness argument, and푝 rebrand ∈ [0,1]is a penalty assigned if the design merely renames or marginally tunes an existing scheme. The accumulated scoreN(P)informs termination and restart decisions (discussed in Section 3.1.5). 3.1.2 Final Stage 1 Output. Figure 2 shows the template of the Stage 1 output in HakiCC. The output is a complete, runnable con- currency control protocol ready to deploy in our transactional sys- tem for verification and benchmarking. It begins with the protocol summary specificationSfollowed by the generated code as a con- crete subclass of an abstract class. Enforcing a fixedbegin/read /write/commit/rollbackinterface keeps the output coherent. It simplifies benchmarking and verification, reduces the tokens the LLM must generate, and accelerates the repair loop by confining the task to implementing a single class. 3.1.3Shared Conversation History. All nodes communicate through a shared conversation history퐻. Each node appends its output to 퐻; every subsequent node receives the full accumulated context from all prior steps. This makes all prior outputs visible to every downstream component without explicit routing. Sharing퐻lets each agent consult the reasoning behind earlier outputs rather than only the artifact they produced, so the Generator agent can resolve ambiguities inSagainst the Proposer’s stated intent and avoid retrying repairs that have already failed. 3.1.4 LLM Context Management. Each repair iteration appends error traces to퐻, causing the Generator’s effective context to grow with the number of iterations. We bound this growth with a context compaction strategy (Figure 3): once|퐻|exceeds a configurable token threshold, older debug entries are summarized and dropped, retaining only the original specification푆and the most recent error feedback. This keeps the Generator’s context size complexity to be 푂(1) in the number of repair iterations. 4 HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control ProtocolsSIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA 3.1.5 Termination and Restart. The repair loop is bounded by a maximum iteration limit푘 max . If the Generator agent fails to pro- duce a passing implementation within푘 max iterations, the pipeline discardsPand restarts from the Proposer agent with a fresh invo- cation. A restart is also triggered if the novelty scoreN(P)falls below a configurable threshold휃 N , enforcing a minimum quality bar on the generated design before it advances to Stage 2. 3.2 Stage 2: Agentic Optimization Pipeline Given the verified protocolP 0 from Stage 1, Stage 2 solves the optimization problem: P ∗ = arg max P∈Π score(P)(2) whereΠis the space of conforming C implementations (i.e., sub- classes of the C interface that compile and run) andscoreis defined in Equation 3. This score combines two objectives, the correctness of the protocol and its throughput, so that the search rewards imple- mentations that are both serializable and fast. Rather than treating correctness as a hard constraint onΠ, we keep it as a graded term of the score, so partially correct candidates are retained during the search and can still guide it toward a correct, high-performance design; as we detail below, the protocol HakiCC ultimately returns is filtered to be fully conflict-serializable. We implement this search using OpenEvolve [46], an open-source LLM-driven evolutionary framework. The optimizer iteratively proposes mutations of candi- date implementations, evaluates them under controlled workloads, and selects high-performing variants to seed the next generation. Evolutionary Search. OpenEvolve agent (labeled 5 ○ in Figure 1) optimizes the Stage 1 protocol through an iterative LLM-driven evolutionary loop. The search maintains a diverse population of candidate implementations using MAP-Elites (Multidimensional Archive of Phenotypic Elites) [36], a quality-diversity algorithm that maps programs to behavioral cells and retains diverse high- performing variants rather than converging on a single local opti- mum. To prevent premature convergence, the population is split into multiple isolated islands that evolve independently, with pe- riodic migration to propagate discoveries across the population. Within each island, selection balances exploitation of currently high-performing programs against exploration of novel variants. Evolution is diff-based, meaning the LLM proposes targeted, lo- calized edits to the current best program rather than full rewrites. Restricting mutations to diffs preserves the core algorithmic struc- ture established in Stage 1 and confines the search to the neighbor- hood of a known-correct protocol, directing optimization toward performance improvements rather than rediscovering correctness from scratch. Evaluation Benchmark Suite. Each candidate is evaluated against a benchmark suite of concurrent workloads ( 6 ○ ) that tests both correctness and performance. The correctness workloads check that the protocol remains conflict-serializable and makes progress under different scenarios. The performance workloads use stan- dard OLTP benchmarks—TPC-C [52] and AuctionMark from OLTP- Bench [14]—each run at multiple contention levels ranging from uniform random access to extreme hotspot scenarios, ensuring that optimized protocols generalize across typical and stress-test con- ditions. The correctness suite additionally includes three targeted synthetic workloads: a banking workload (concurrent fund trans- fers), a counter workload (read-modify-write increments on a shared counter), and a deadlock workload (cyclic resource-acquisition pat- terns). The full benchmark configuration is detailed in Section 4. Optimization Objective. Each candidate is scored on two primary dimensions: correctness, which measures the fraction of workload scenarios in which the protocol is conflict-serializable, stall-free, and makes measurable progress over the duration of each run; and throughput, which captures the committed transaction rate across scenarios. The primary optimization target is a combined score: score= 0.5· correctness+ 0.5· ˆ 푇(3) where ˆ 푇is a weighted average of per-scenario throughputs, each normalized by a fixed throughput ceiling. This ceiling is the same for all workloads and set to the system’s throughput capacity for a normal workload, so a protocol that reaches the maximum attain- able throughput under a normal workload scores ˆ 푇= 1. Scenar- ios involving the pre-known target application (i.e., the application transaction mix the protocol is being optimized for) receive twice the weight in ˆ 푇 , biasing the search toward protocols that perform well on the intended use case rather than incidentally on other benchmarks. This joint objective lets the search improve throughput while keeping correctness in view at every step, rather than optimizing performance in isolation and checking correctness only afterward. Because correctness is measured over a small suite of adversarial scenarios, it behaves as a near-binary signal in practice, as a single non-serializable scenario sharply lowers the score and an imple- mentation bug typically breaks several scenarios at once. Starting from a correct Stage 1 protocol, any loss of correctness thus carries a penalty far larger than a plausible throughput gain, so the search is steered toward correct designs while still receiving a gradient from partially correct intermediates. At the end of the run, we filter the population by correctness and return the best-scoring protocol among those that pass all scenarios, so the final design is always conflict-serializable. 4 Evaluation In this section, we evaluate HakiCC on two standard OLTP bench- marks, TPC-C and AuctionMark. We ran the full pipeline on each application and report the first ten protocols it produced, five per workload. For Stage 1, we examine the structural diversity of the generated protocols to assess whether application-conditioned de- sign produces a meaningful spread across the C design space. For Stage 2, we compare the performance of the generated protocols against each other and against 2PL and OCC baselines. 4.1 Experimental Setup We describe the evaluation configurations for each stage, the bench- mark suite used for both correctness checking and performance evaluation, and the hardware platform. Stage 1 Configuration. All Stage 1 agents (Proposer, Generator, and Novelty Evaluator) are backed by Gemini 2.5 Pro at temperature 0.7 with a context window of up to 120K tokens. The repair loop is capped at푘 max =50 iterations; if the Generator agent fails to produce a passing implementation within this budget, 5 SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USAFarzad Habibi, Juncheng Fang, and Faisal Nawab 2PL OCC MVCC SSI Silo H-Store Escrow Calvin TO TicToc Hekaton 20 40 60 80 SADL 2PL OCC MVCC SSI Silo H-Store Escrow Calvin TO TicToc Hekaton 20 40 60 80 SALVO 2PL OCC MVCC SSI Silo H-Store Escrow Calvin TO TicToc Hekaton 20 40 60 80 LPOCC 2PL OCC MVCC SSI Silo H-Store Escrow Calvin TO TicToc Hekaton 20 40 60 80 PESC 2PL OCC MVCC SSI Silo H-Store Escrow Calvin TO TicToc Hekaton 20 40 60 80 DCOV 2PL OCC MVCC SSI Silo H-Store Escrow Calvin TO TicToc Hekaton 20 40 60 80 HSL 2PL OCC MVCC SSI Silo H-Store Escrow Calvin TO TicToc Hekaton 20 40 60 80 TREAD 2PL OCC MVCC SSI Silo H-Store Escrow Calvin TO TicToc Hekaton 20 40 60 80 WGC 2PL OCC MVCC SSI Silo H-Store Escrow Calvin TO TicToc Hekaton 20 40 60 80 PVL 2PL OCC MVCC SSI Silo H-Store Escrow Calvin TO TicToc Hekaton 20 40 60 80 SAPL TPC-C Protocols AuctionMark Protocols Figure 4: Design similarity profiles of the ten generated C protocols against eleven reference C families. Each radial axis reports the Jaccard similarity (%) between a generated protocol’s design feature vector and that of the reference family. the pipeline discards the current proposal and restarts from the Proposer. A restart is also triggered if the novelty scoreN(P)falls below휃 N =0.25 (see Section 3.1.5 for the full termination and restart policy). Stage 2 Configuration. The evolutionary optimization in Stage 2 is configured as follows. We run OpenEvolve for 1000 iterations, evaluating candidates serially. The LLM backbone is Gemini 2.5 Flash (temperature 0.7, max 120K tokens per call), and evolution is strictly diff-based: only localized edits are proposed; full rewrites are disabled. The population is structured as 3 independent islands, each main- taining an archive of 100 MAP-Elites cells within a global population cap of 800 programs. Islands migrate periodically: every 50 genera- tions, 15% of each island’s programs are shared with neighboring islands. The exploration ratio (30%) and exploitation ratio (70%) gov- ern how each parent program is chosen, drawing either a random program from the island or an elite from the archive. Each parent is presented to the LLM alongside 2 inspiration programs sampled from the same island and the island’s 3 highest-scoring programs. Benchmark Suite. Both Stage 1 and Stage 2 use the same bench- mark suite, which includes TPC-C and AuctionMark applications, as well as three synthetic workloads targeting specific correctness scenarios: a banking workload (concurrent fund transfers), a counter workload (read-modify-write increments on a shared counter), and a deadlock workload (cyclic resource-acquisition patterns). In Stage 1, the Serializability Verifier runs the benchmark suite within the generate-and-verify loop, checking only for conflict-serializability. In Stage 2, the suite serves as the fitness function for evolution- ary optimization, scoring each candidate on both correctness and throughput as described in Section 3. TPC-C Application. TPC-C [52] benchmark simulates a whole- sale supplier executing five transaction types across multiple ware- houses. Following prior C evaluation practice [18,41,42], we focus on New Order and Payment, which together account for ap- proximately 88% of the benchmark mix (45% and 43%, respectively) and are short update transactions that place the greatest stress on concurrency control. We use a 50%/50% split between the two trans- action types, with 1% of transactions subject to random user aborts per the benchmark specification. We evaluate TPC-C along two independent contention axes. The first is a scalability benchmark: we vary the warehouse count across six levels (very low to extreme), from 64 warehouses (low inter-transaction conflict) down to 1 ware- house (all transactions share the same key space). The second is a hotspot benchmark: we fix the warehouse count at 8 and vary the hotspot intensity across four levels, concentrating accesses onto a small fraction of hot records to stress intra-warehouse contention independently of scale. AuctionMark Application. AuctionMark benchmark from OLTP- Bench [14] models an online auction platform with a mixed read- heavy and write-heavy transaction mix. Key contention points include high-bid records and item-status fields, which are accessed by multiple concurrent transaction types. We run AuctionMark at four contention levels by varying the Zipfian skew parameter ap- plied to item and user access patterns, ranging from low to extreme hotspot concentration. A higher skew concentrates a larger fraction of transactions onto a small set of hot item and user records that directly increases read-write conflict at those rows. Evaluation Environment. The experiments are conducted on cascadelake node of Chameleon Cloud [24]. This machine has 2 Intel Xeon Gold 6242 CPUs at 2.8 GHz with 96 virtual threads and is also equipped with 187 GB RAM and 10 Gigabit Ethernet. We implemented a transactional engine in Java with an in- memory key-value store, in the style of DBx1000 [64], that uses the generated HakiCC protocol as its concurrency control mechanism. Each candidate protocol is evaluated by a concurrent Java bench- mark running 64 parallel worker threads. Each scenario runs for 6 HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control ProtocolsSIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA SADL SALVO LP-OCC PESC DCOV HSL TREAD WGC PVL SAPL SADL SALVO LP-OCC PESC DCOV HSL TREAD WGC PVL SAPL 37 2457 338858 33675669 3154495857 254232484646 39452643433831 3489598666564841 445753614841352659 TPC-C AuctionMark 0 20 40 60 80 100 Design Similarity (%) Figure 5: Pairwise design similarity between the ten gener- ated C protocols. 30 seconds to collect throughput and correctness traces. Serializ- ability is checked after each scenario using precedence-graph cycle detection. 4.2 Stage 1 Results We ran Stage 1 on TPC-C and AuctionMark and collected the first five protocols produced for each application—SALVO, LP-OCC, PESC, DCOV, and SADL for TPC-C, and TREAD, WGC, HSL, PVL, and SAPL for AuctionMark (described in detail in Section 5). We evaluate two aspects of the ten generated protocols: how their designs align with known C families and how structurally similar the protocols are to each other. Protocol Diversity. To assess structural diversity, we describe each protocol as a binary feature vector, where each entry records whether the protocol uses a particular design technique (1) or not (0). We define 150 such features, grouped into 12 design dimensions— pessimistic locking [5], optimistic validation [27], conflict detection timing, multi-version storage [4], correctness guarantees, SSI-style anti-dependency tracking [6], timestamp ordering [3], interval- based commit timestamps [65], deterministic pre-ordering [16,53], partition-based execution [23], commutativity-aware conflict reso- lution [38], and implementation-level features. Pairwise similarity between two protocols is computed using a Jaccard-style metric [21] over positive criteria: sim(퐴,퐵)= |푐 : 퐴 푐 = 1∧ 퐵 푐 = 1| |푐 : 퐴 푐 = 1∨ 퐵 푐 = 1| × 100(4) The score is the fraction of techniques both protocols adopt (numer- ator) among all techniques used by either protocol (denominator), scaled to a percentage. Shared absences (both 0) are excluded, so similarity reflects genuine structural alignment rather than coinci- dental non-adoption of features. Figure 4 shows the design profile of each generated protocol as a radar chart, where each axis represents the Jaccard similarity to a reference C family (2PL [5], OCC [27], MVCC [4], SSI [6], Silo [54], H-Store [23], Escrow [38], Calvin [53], TO [3], TicToc [65], Heka- ton [30]). No generated protocol collapses onto a single reference: all ten exhibit a distinct multi-axis profile, borrowing selectively from two to four reference families without reproducing any one of them. Among TPC-C protocols (blue), SALVO, LP-OCC, PESC, and DCOV all cluster strongly around the OCC/Silo/TicToc family (47– 55% on those axes), consistent with optimistic validation designs tai- lored to short-update workloads. SADL diverges from the rest of the TPC-C protocols, with the highest Escrow (48%) and Calvin (45%) similarity of any generated protocol, which reflects a commutative- operation and reservation-based design rather than a conventional optimistic approach. Among AuctionMark protocols (orange), PVL is the most Silo- dominant (59%), while TREAD diverges sharply from the rest with its highest scores on Hekaton (52%) and SSI (48%), indicating a version-based, anti-dependency-tracking design. WGC stands out as the most H-Store-similar protocol (40%), the only partition-style design in the cohort, while SAPL combines a notable Escrow affinity (46%) with broad OCC and Silo characteristics. Protocol Similarity. Figure 5 shows the pairwise Jaccard similar- ity between all ten generated protocols. This heatmap reveals a tight structural cluster: SALVO (TPC-C), PESC (TPC-C), and PVL (AuctionMark) are nearly identical (≥86% pairwise), with DCOV and LP-OCC also closely related (56–69% to the cluster core). This cluster spans both target workloads, showing that the Proposer can independently converge on similar OCC/Silo-family designs when both workloads reward optimistic execution. Three protocols stand clearly apart from the rest, with SADL reaching at most 44% similarity to any peer, TREAD 48%, and WGC 45%—each representing a design family (Escrow/Calvin, Heka- ton/SSI, and H-Store partition, respectively) that no other generated protocol closely replicates. This combination of a tight optimistic cluster and three distinctly separated protocols confirms that Stage 1 produces genuine structural variety rather than uniformly sampling a single region of the protocol space, a spread the pipeline actively encourages by prompting against redundancy (Section 3). 4.3 Stage 2 Results Stage 2 evolutionary optimization improves throughput for the majority of generated protocols across both workloads. Figure 6 shows per-protocol throughput curves before and after optimiza- tion for both workloads, with throughput (K TPS) on the푦-axis and contention level on the푥-axis; each protocol is plotted as a Stage 1 and a Stage 2 curve, the shaded band between them marks the improvement, and the 2PL and OCC baselines are overlaid for reference. Figure 7 decomposes execution time into read, write, and commit phases to expose the source of each improvement, report- ing the mean per-phase duration (in휇s) for every protocol before and after Stage 2 across four hotspot intensity levels. 4.3.1TPC-C Protocols. Throughput Improvement. Among TPC- C protocols, Stage 2 produces the largest gains for SADL and PESC, moderate contention-dependent gains for SALVO, and marginal changes for LP-OCC and DCOV (Figure 6). SADL improves by 52−406% across all six contention levels, the largest absolute gains in the TPC-C cohort. SALVO shows a modest regression at very low contention (−7%) but strong gains at high and extreme con- tention (+85% and+145%), consistent with optimizations that pay off only when the commutative-write fast path is heavily exercised. PESC shows a−15% regression at very low contention but recovers to+77–203% at higher levels, reflecting commit-path optimization 7 SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USAFarzad Habibi, Juncheng Fang, and Faisal Nawab Very Low Low Medium High Very High Extreme 0 50 100 150 200 250 300 350 Throughput (K TPS) +196% +215% +52% +136% +373% +406% SADL (Stage 1) SADL+ (Stage 2) Very Low Low Medium High Very High Extreme 0 50 100 150 200 250 300 350 -7% +23% +99% +9% +85% +145% SALVO (Stage 1) SALVO+ (Stage 2) Very Low Low Medium High Very High Extreme 0 50 100 150 200 250 300 350 +12% -8% +6% +4% +6% +1% LP-OCC (Stage 1) LP-OCC+ (Stage 2) Very Low Low Medium High Very High Extreme 0 50 100 150 200 250 300 350 -15% +103% +203% +177% +77% +27% PESC (Stage 1) PESC+ (Stage 2) Very Low Low Medium High Very High Extreme 0 50 100 150 200 250 300 350 +13% -19% -10% -6% +9% +6% TPC-C DCOV (Stage 1) DCOV+ (Stage 2) Low Medium High Extreme 0 200 400 600 800 1000 1200 1400 Throughput (K TPS) -14% -8% -4% -7% HSL (Stage 1) HSL+ (Stage 2) Low Medium High Extreme 0 200 400 600 800 1000 1200 1400 -21% +480% +106% +91% TREAD (Stage 1) TREAD+ (Stage 2) Low Medium High Extreme 0 200 400 600 800 1000 1200 1400 +1% +24% +14% +11% WGC (Stage 1) WGC+ (Stage 2) Low Medium High Extreme 0 200 400 600 800 1000 1200 1400 +11% +30% +282% +435% PVL (Stage 1) PVL+ (Stage 2) Low Medium High Extreme 0 200 400 600 800 1000 1200 1400 +18% -2% -32% -1% AuctionMark SAPL (Stage 1) SAPL+ (Stage 2) ±% = throughput change (Stage 1 Stage 2) 2PLOCCImprovement range Figure 6: Throughput in thousands of transactions per second (K TPS) before (Stage 1) and after (Stage 2) evolutionary optimiza- tion across six contention levels for TPC-C protocols and four contention levels for AuctionMark protocols. Shaded area shows the improvement range; 2PL and OCC baselines shown for reference. Percentages denote the per-level throughput change from Stage 1 to Stage 2. Low Medium High Extreme Read Phase 2PL OCC SADL SADL+ SALVO SALVO+ LP-OCC LP-OCC+ PESC PESC+ DCOV DCOV+ 122538118 2.81.91.40.9 37333328 195989289 3.42.91.81.0 3.22.11.71.1 10.0234260 11223963 3.53.92.41.7 2.73.03.21.6 2.62.41.71.1 3.32.51.60.8 Low Medium High Extreme Write Phase 4.46.07.718 1.00.80.50.5 50792692,460 1.21.41.23.3 0.90.70.60.5 0.60.50.60.5 0.91.00.60.7 1.10.70.70.7 1.01.20.70.8 0.81.11.00.7 1.00.90.70.6 1.61.20.90.6 TPC-C Low Medium High Extreme Commit Phase 22212022 187405646507 372397539670 125172151279 791202451,899 6767230782 101197364543 104182348541 209553891750 2530180549 263400434995 257437488949 Low Medium High Extreme Read Phase 2PL OCC HSL HSL+ TREAD TREAD+ WGC WGC+ PVL PVL+ SAPL SAPL+ 1289123184 5.43.21.81.5 5.14.12.93.7 5.26.53.314 1.50.91.10.6 6.21.93.41.4 1.71.81.51.2 1.82.11.71.3 4.12.23.64.7 4.43.72.41.9 7.34.14.49.8 6.15.13.96.8 Low Medium High Extreme Write Phase 9.69.01217 4.52.91.71.4 2.52.82.22.4 3.24.62.44.2 1.30.71.10.6 3.21.31.31.1 0.80.90.90.8 0.90.80.80.7 1.91.61.73.1 1.81.91.41.3 7.75.05.05.3 6.35.04.23.8 AuctionMark Low Medium High Extreme Commit Phase 17162028 46125143306 144494143 202592127 761,2041,5862,412 77296367307 887987128 815977115 3157177239 23262822 22473072 252776103 10 0 10 1 10 2 Duration (μs, log) 10 0 10 1 10 2 10 3 Duration (μs, log) 10 2 10 3 Duration (μs, log) 10 0 10 1 10 2 Duration (μs, log) 10 0 10 1 Duration (μs, log) 10 2 10 3 Duration (μs, log) Figure 7: Mean read, write, and commit phase duration (휇s) for all protocols before and after Stage 2 optimization, at four hotspot intensity levels. A + suffix on a protocol name denotes its post-Stage 2 variant. that carries overhead at low concurrency. LP-OCC and DCOV show near-flat or slightly negative changes (−19% to+13%), indicating that Stage 1 already found a near-optimal implementation for these OCC-family designs. All five TPC-C protocols outperform both the 2PL and OCC baselines at medium and higher contention levels after Stage 2. Phase-Level Analysis. Figure 7 reveals that the large SADL im- provement originates from a critical write-phase defect: the Stage 1 SADL implementation exhibits a write phase of 50–2,460휇s across contention levels, growing catastrophically to over 2 ms at extreme hotspot contention. Stage 2 identifies and eliminates this write-path bottleneck, reducing the write phase to 1.2–3.3휇s, a 3 orders-of- magnitude improvement at extreme contention. PESC undergoes a similarly dramatic commit-phase transformation: the Stage 1 com- mit overhead of 209–891휇s is reduced to 25–549휇s after Stage 2, with the low-contention case dropping by 8×, reflecting the elimi- nation of redundant validation work on the conflict-free fast path. In contrast, LP-OCC and DCOV phase times are largely unchanged between Stage 1 and Stage 2, confirming that the small throughput deltas reflect implementation maturity rather than missed opti- mization opportunities. The OCC baseline exhibits a characteristic validation bottleneck in the commit phase (187–646휇s), while 2PL shows an escalating read phase (12–118휇s) under increasing con- tention due to lock-wait latency. 4.3.2 AuctionMark Protocols. Throughput Improvement. The AuctionMark cohort exhibits a wider range of Stage 2 outcomes than TPC-C (Figure 6). TREAD undergoes the most dramatic re- covery: a−21% regression at low contention is accompanied by +480%,+106%, and+91% gains at medium, high, and extreme con- tention, transforming a protocol that was barely functional at mod- erate contention into the highest-throughput design in the Auc- tionMark cohort at those levels. PVL improves monotonically with contention—+11% at low,+282% at high, and+435% at extreme— becoming the best-performing AuctionMark protocol at high and extreme contention after optimization. WGC shows consistent mod- est improvements of+1–24% across all levels, reflecting incremental refinements without any single dominant fix. HSL degrades slightly at all four levels (−4% to−14%), the only AuctionMark protocol 8 HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control ProtocolsSIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA where Stage 2 produces a net negative outcome. SAPL gains+18% at low contention but regresses by 32% at high contention, indicat- ing that Stage 2 mutations that benefited the low-contention case introduced a new bottleneck under high concurrency. Phase-Level Analysis. Figure 7 identifies the commit phase as the dominant bottleneck in the AuctionMark cohort, mirroring the TPC- C findings. TREAD’s Stage 1 commit phase grows from 76휇s at low contention to 2,412휇s at extreme—a super-linear growth in commit overhead under increasing contention. Stage 2 reduces this to a flat 77–367휇s profile, eliminating the super-linear scaling behavior and enabling the large throughput recovery observed in Figure 6. PVL shows a complementary pattern: its Stage 1 commit phase grows to 239휇s at extreme contention, while Stage 2 achieves near-constant commit overhead of 22–28휇s across all levels—comparable to the 2PL baseline—explaining the+435% throughput gain at extreme contention. HSL, WGC, and SAPL exhibit commit phases in the 14–143휇s range even at Stage 1, leaving little room for commit-path optimization; the modest throughput changes for these protocols are consistent with this observation. Read and write phase times remain below 10휇s for most AuctionMark protocols across all con- tention levels, confirming that the bottleneck is exclusively in the commit phase rather than in data access or buffer management. 5 Generated Concurrency Control Protocols In this section, we describe the ten concurrency control protocols generated by HakiCC: five targeting TPC-C and five targeting Auc- tionMark. Each protocol is described below with its design overview, read/write/commit strategy, and the improvements found by Stage 2. The correctness argument stated for each protocol is the conflict- serializability justification HakiCC produced during design and confirmed in Stage 1 verification. 5.1 TPC-C Specific Protocols 5.1.1SADL – Semantic-Aware Deterministic Locking. SADL 1 parti- tions the TPC-C key space by warehouse ID. Each partition is man- aged by a single-threaded scheduler that assigns each transaction a monotonic intra-partition sequence number (IPSN), establishing a pre-defined serial order. Concurrency is maximized through three lock modes: shared (S) for reads, exclusive (X) for non-commutative writes, and an ordered-commutative (OC) lock for arithmetic writes. OC-locks are mutually compatible, allowing concurrent commuta- tive updates to the same field while the commit queue enforces the IPSN order. SADL guarantees conflict-serializability, as the pre-assigned IPSN fixes a per-partition serial order and applying buffered writes in that order makes the committed state equivalent to a serial exe- cution. Its performance gains rely on a largely partition-friendly workload; cross-partition transactions remain correct but forgo the benefit of independent per-partition scheduling. Read/Write/Commit. Reads acquire an S-lock and return the store value. Writes to order-ID counter fields are non-commutative and acquire an X-lock; all other writes (year-to-date balance updates, stock quantity adjustments) are commutative arithmetic operations and acquire an OC-lock. All writes are buffered locally until commit. Commit places the transaction in a per-partition priority queue; the 1 All protocol names are generated by the HakiCC Proposer agent (an LLM), not chosen by the authors. scheduler drains this queue in strict IPSN order, applies buffered writes, and releases locks. Deadlocks are prevented because a trans- action may wait for a lock held by another only when its IPSN is larger, producing an acyclic waits-for graph. Stage 2 Improvements. The optimizer fixed an IPSN assignment race that allowed duplicate sequence numbers, an initialization er- ror that caused partitions to share a single scheduler, and a missing wake-up of waiting transactions in the per-partition commit sched- uler that produced head-of-line blocking under burst loads. All three are low-level concurrency defects that suppressed through- put rather than algorithmic changes; removing them unlocked the per-partition and OC-lock parallelism the design already intended, accounting for SADL’s large throughput gain. 5.1.2 SALVO – Semantic-Aware Latching and Optimistic Delta Ap- plication. SALVO is a hybrid OCC protocol that dispatches each read and write to one of three specialized modes selected by run- time key-pattern matching. District-level order counter fields are served by lock-free atomic increments. Customer balance reads that are unconditionally overwritten by the same transaction are excluded from validation (blind-read elimination). All remaining fields follow standard OCC versioned reads. Three write modes mirror this structure: new-order records are private inserts with version 0, year-to-date and balance fields accumulate commutative deltas, and all other writes are buffered as versioned values. SALVO provides conflict-serializability, combining OCC valida- tion on the optimistic path with order-independent commutative deltas and sorted-order commit locking for deadlock freedom. Read/Write/Commit. A read returns the requested value and records its version for later validation, except on the two fast paths, where counter reads use an atomic fetch-and-add and blind balance reads skip version tracking. A write is buffered locally in its mode— a versioned value, a commutative delta, or a private insert—and applied only at commit. Commit locks all written and delta keys in sorted order for deadlock freedom, validates that no read version has changed, and then installs the versioned writes, applies the deltas atomically, and adds the private inserts before releasing the locks. Stage 2 Improvements. The optimizer widened the commutative delta set from warehouse-level to district-level year-to-date and order-counter fields (the actual hot spots at low warehouse counts) and corrected a double-apply bug that re-applied deltas during checkpoint replay. 5.1.3 LP-OCC – Lock-Protected Optimistic Concurrency Control. LP-OCC is a classic OCC implementation that eliminates reader- writer races on value-version pairs by briefly locking each key during the read phase. Each record has a dedicated per-key lock in a global lock manager. Transactions execute optimistically, buffering all writes locally; the shared store is only modified at commit. LP-OCC provides conflict-serializability, since the read-phase lock makes each read observe a fully installed value and version, and holding locks over the whole read and write set at commit makes validation and installation atomic. Read/Write/Commit. A read briefly locks the key, captures the value and its version together, and releases the lock, so the trans- action always sees a consistent snapshot; repeat reads are served 9 SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USAFarzad Habibi, Juncheng Fang, and Faisal Nawab from a local cache. A write is buffered locally, and if the key was not already read, a consistent read is issued first so that every written key carries a version dependency and no update is lost. Commit locks the union of the read and write set in sorted order (keeping it deadlock-free), validates that no recorded version has changed, and, if validation passes, installs the buffered writes and bumps their versions before releasing the locks. Stage 2 Improvements. The optimizer stripped avoidable over- head from the commit path, removing synchronization from per- transaction data structures and redundant allocation when ordering keys for locking. It also routed each write to the store’s matching operation—insert, numeric increment/decrement, or overwrite. 5.1.4 PESC – Phased Execution and Semantic Commit. PESC is a hybrid concurrency control that routes each write to one of two paths based on key semantics. Year-to-date and balance fields are commutative and accumulate signed deltas; all other fields are non- commutative and buffer absolute values. A per-transaction flag tracks whether any non-commutative write has occurred, enabling a blind-read optimization that skips version tracking for customer balance reads in New Order transactions (which unconditionally overwrite those fields). PESC is conflict-serializable, as the non-commutative path vali- dates reads and then holds write locks through installation so no concurrent commit can interfere, while commutative delta writes are order-independent. Read/Write/Commit. Reads check a local snapshot cache; misses fetch the value and version stamp from the store. Commutative writes compute a delta against the snapshot and merge it into a delta set; non-commutative writes buffer the intended value in a write set. Commit acquires per-key locks in sorted order, validates the read set, re-reads current locked values for stock fields and recomputes their deltas relative to the snapshot (absorbing concurrent writes that committed between the read and the lock), installs all writes, and releases locks. Stage 2 Improvements. The optimizer removed a bypass that routed order-ID counter writes directly through an atomic variable outside the transaction protocol (leaving those writes untracked in version state), narrowed the locking scope to write keys only to reduce contention, and routed every write through the store’s typed insert, update, and increment operations. 5.1.5DCOV – Dual-Counter Optimistic Validation. DCOV is a se- mantic OCC protocol that replaces the conventional single version number per record with two monotonic counters: an Exclusive- Modification Counter (EMC) incremented by non-commutative writes and a Commutative-Modification Counter (CMC) incremented by delta writes. Each record is stored as a (value, EMC, CMC) triple. A per-warehouse commit lock serializes all commits within a parti- tion; validation confirms both counters match for every non-blind read key. DCOV is conflict-serializable, since the per-warehouse commit lock makes each transaction’s validation and installation atomic, and matching both counters confirms that no committer has modi- fied its non-blind reads since it observed them. Read/Write/Commit. Reads check the local write set, then a per- transaction cache, then the store. Writes to year-to-date and balance fields compute a signed delta; all other writes buffer an absolute value and mark the transaction as having an exclusive write. A read is classified as blind if the transaction has already performed at least one exclusive write and the key is a customer balance field that will be unconditionally overwritten; blind reads are cached but excluded from counter validation. Commit acquires the per- warehouse commit lock, validates all non-blind read-set entries against both EMC and CMC, installs each write (incrementing EMC for exclusive writes, CMC for delta writes), and releases the lock. Stage 2 Improvements. The optimizer removed synchronization from per-transaction data structures that are never shared across threads, added a validation-result cache to reuse fetched records across the validation and write phases, and fixed partition-key parsing to correctly route global item records. 5.2 AuctionMark Specific Protocols 5.2.1HSL – Hierarchical Speculative Locking. HSL groups records into coarse-grained logical entities and enforces concurrency at entity granularity. Transactions execute speculatively in parallel without acquiring any lock during execution; they register read and write intents on entity-level data structures. Concurrency con- trol is enforced entirely at commit through firm-lock acquisition and proactive invalidation of all concurrent speculators on written entities. HSL guarantees conflict-serializability, as a committing writer holds firm locks on every entity it touched and proactively aborts any transaction that speculatively read a written entity, so no transaction can commit on a stale read. Read/Write/Commit. Reads register the transaction in the entity’s speculative-reader map and fetch the value directly from the store without acquiring any lock. Writes register in the speculative-writer map and buffer the key-value pair locally. Read-only transactions (empty write set) skip locking entirely and commit immediately after deregistration. Writing transactions sort their read and written entity IDs lexicographically and acquire each entity’s firm lock in that order. Writes are applied atomically; every transaction that read from a written entity is then proactively aborted before locks are released. Stage 2 Improvements. The optimizer expanded entity-prefix coverage to the full AuctionMark schema (adding item-bid, item- purchase, user-item, and composite counter entity types), reducing false conflicts from unrecognized keys falling through to the single global lock entity, and fixed cleanup to remove transactions from the correct speculative map rather than cross-probing both maps for every entity. 5.2.2 TREAD – Transactional Read Epoch-based Abort & Deltas. TREAD is a multi-version protocol built on an MVCC backbone, where each key holds a version chain and reads are non-blocking, serving the latest version committed before the transaction’s start timestamp. Item-status reads additionally register the transaction in the read version’s dependency set, while high-contention counter fields—bid-count, rating, and per-item-user counters—bypass the version chain and accumulate as commutative signed deltas. These mechanisms lift MVCC’s snapshot isolation toward serializabil- ity, since a transaction that writes a status field aborts the depen- dents registered on the overwritten version before installing its 10 HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control ProtocolsSIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA own, breaking the anti-dependency cycles behind write-skew, while commutative deltas commit in any order. Read/Write/Commit. Reads walk the version chain for the latest visible version; item-status reads additionally register in the ver- sion’s dependency set. Commutative writes append a signed delta to a local buffer; all others buffer absolute values. At commit, each standard write acquires a hash-stripe latch—rather than a lock per record, keys are hashed onto a fixed-size array of latches, so only keys colliding on the same entry contend—then clears and processes the current version head’s dependency set (proactively aborting stale readers), installs a new version node, and immediately releases the latch. Deltas are applied atomically without acquiring any latch, so concurrent delta commits on the same counter field never block each other. Stage 2 Improvements. The optimizer narrowed dependency invalidation from a full version-chain scan to only the current version head (reducing cost from푂(푉)to푂(1)per key, where푉 is the key’s version-chain length), expanded the latch array from 128 to 1024 entries to reduce collision probability, and extended the commutative field set to cover order-ID counters, quantity, total, balance, and year-to-date fields. 5.2.3 WGC – Workflow-Aware Graph Coloring. WGC transforms concurrency control from runtime conflict detection into pre-execution scheduling. Transactions are classified into three semantic colors: GREEN (read-only), YELLOW (writes that touch no status field), or RED (writes that change an item’s status). A pool of 128 single- threaded Entity Execution Coordinators (EECs) partitions the entity space by hash. Each EEC enforces a color-compatibility matrix: multiple GREENs overlap freely; a single YELLOW may overlap with concurrent GREENs; REDs require the entity to be fully idle. Incompatible transactions are held in a hold-back queue and re- evaluated after each completion. WGC is conflict-serializable, since transactions that conflict on an entity are dispatched to the same single-threaded EEC and run one at a time, while the color rules let only non-conflicting transactions overlap. Read/Write/Commit. Reads are client-side and non-blocking. Bid- count, rating, and per-item-user counter writes compute and buffer a signed delta; all other writes buffer an absolute value. At commit, the transaction’s color is determined (GREEN if no writes exist, RED if any write touches an item-status field, YELLOW otherwise), it is submitted to its EEC, and the caller blocks until the EEC applies the writes and signals completion. Stage 2 Improvements. The optimizer replaced an푂(푛)scan over active transactions in the compatibility check with three run- ning per-color counts, and restructured the hold-back queue so that waiting transactions are re-evaluated in FIFO order after each completion. 5.2.4 PVL – Optimized Phased Validation Locking. PVL combines lock-free reads with a three-path commit strategy differentiated by write semantics. Each key carries a version counter. Reads record versioned snapshots; writes are classified as commutative deltas or standard absolute values, routing the commit to the lightest correct path for the transaction’s write footprint. PVL is conflict- serializable, since every commit path validates that no version in the read snapshot has changed, and the standard path additionally holds write locks across validation and installation so no concurrent writer can intervene. Read/Write/Commit. Reads sample the version counter and value, cache the result as a versioned snapshot, and return without acquir- ing any lock. Bid-count, rating, and per-item-user counter writes accumulate a signed delta; all other writes buffer absolute values. Commit takes one of three paths: (1) read-only validates version snapshots with no locks acquired; (2) delta-only validates versions and applies deltas atomically without acquiring any write lock, making high-frequency counter transactions nearly contention- free; (3) standard acquires write locks in sorted key order, validates, installs absolute writes, and applies deltas. Stage 2 Improvements. The optimizer fixed a type-handling bug in the read path that failed on certain numeric encodings and caused spurious aborts, normalizing all integer-valued fields to a common type; this repair simplified the write-key union computed at commit. 5.2.5 SAPL – State-Aware Phased Locking. SAPL combines pes- simistic entity latching with OCC version validation in two lay- ers. Transactions acquire shared or exclusive read/write latches on logical item entities throughout their lifetime, serializing state- transitioning operations. A version-validation layer at commit serves as a correctness backstop for remaining conflicts. Commu- tative counter updates are buffered as signed deltas and applied atomically at commit. SAPL is conflict-serializable through its two layers, with entity latches serializing state transitions on an item and commit-time version validation under sorted key locks aborting any transaction whose reads changed before its writes install. Read/Write/Commit. Reads to item-centric entity fields acquire a shared read latch with a non-blocking attempt that aborts on failure, and sample the version counter around the store fetch to detect torn reads. Bid-count, rating, and comment-counter writes accumulate a signed delta, while balance and year-to-date writes take the standard OCC path; item-status writes escalate the entity latch from shared to exclusive (with a version check between re- lease and re-acquire to detect intervening modifications). Commit acquires per-key locks in sorted order, validates all read dependen- cies, installs absolute writes and deltas, and releases all locks and latches. Stage 2 Improvements. The optimizer moved balance and year-to- date fields off the commutative delta path and back onto standard OCC validation, since treating their updates as blind commutative deltas violated per-record invariants; it also narrowed pessimistic latching to item records only and simplified how keys are mapped to entities. 6 Related Work HakiCC builds on decades of theoretical and practical research on concurrency control protocols. There has been extensive research on distinct families of concurrency control protocols, each tailored to a specific hardware paradigm or workload. Two-Phase Locking (2PL) [5] enforces conflict ordering through lock acquisition; Optimistic Concurrency Control (OCC) [27] de- fers validation to commit time; Multi-Version Concurrency Control (MVCC) [4] maintains version histories for non-blocking reads; and Serializable Snapshot Isolation (SSI) [6] extends snapshot iso- lation to full serializability via anti-dependency tracking. Modern 11 SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USAFarzad Habibi, Juncheng Fang, and Faisal Nawab in-memory systems such as Silo [54], Hekaton [30], TicToc [65], Cicada [32], and Bamboo [18] optimize these foundations for multi- core hardware, while deterministic protocols such as Calvin [53] and BOHM [16] achieve predictable performance through pre- ordered execution. Brook-2PL [19] targets high-contention hotspot workloads by statically analyzing a graph-based dependency struc- ture (SLW-Graph) to enable deadlock-free lock acquisition and partial transaction chopping for early lock release. IC3 [58] simi- larly exploits static transaction analysis to reduce conflict footprint through fine-grained chopping. Each of these families excels under specific workload conditions but none adapts to a new workload without manual re-engineering. Hybrid C Protocols. Prior work has explored combining mul- tiple concurrency control mechanisms to improve performance across varying workload conditions. Static and Dynamic OCC [63] switch from OCC to locking after the first retry. MOCC [57] and Hsync [45] propose hybrid 2PL–OCC protocols. ACC [51] goes further by adaptively selecting from a broader range of protocols at runtime. Tebaldi [48] groups transactions and assigns each group a different C protocol. CormCC [50] proposes a more general frame- work by formalizing C into four phases, allowing each operation to adopt any protocol’s policy as long as all protocols execute each phase in the same order. These approaches, however, are generally scoped to combina- tions of OCC and 2PL and require programmers to supply heuristics for choosing execution policies per operation. They are designed for dynamic workload adaptation rather than application-specific pro- tocol design, and they do not exploit application-level transaction semantics. HakiCC differs by generating a complete, application- specific protocol implementation. Learned C Protocols. The observation that a single protocol cannot satisfy all contention levels and workload patterns led to the development of learned concurrency control protocols. Polyjuice [56] models concurrency control as a dynamic policy ta- ble, defining the execution state as a high-dimensional combination of transaction type and data access patterns. The system searches a policy space of fine-grained actions to determine whether a trans- action should wait, expose a speculative write, or abort. However, it does not support general transactions and treats all transactions accessing the same data uniformly, which can produce suboptimal decisions with high abort rates. NeurCC [39] advances this direction by modeling the C mech- anism as a continuous learnable function that maps dynamic data- base states directly to conflict-handling actions, coupled with Bayesian optimization and a graph reduction search algorithm. Both systems, however, generalize to a fixed action space across all workload types and do not account for application-specific semantics. HakiCC takes a fundamentally different approach. Rather than learning a policy over a predefined action space, it uses LLM agents to generate application-specific protocol implementations from scratch, producing protocols whose structure and semantics are tailored to the target application. LLM-driven Agents. Large language models trained on code can generate executable programs from natural-language speci- fications [8], and recent work embeds them in agentic loops that reason, act, and repair their output under feedback [34,47,62]. SWE-agent [60] edits real codebases for automated software en- gineering, while multi-agent frameworks such as MetaGPT [20] and AutoGen [59] assign specialized roles to collaborating agents. These systems target general programming tasks and validate their output against unit tests, which cannot certify the correctness of a concurrency control protocol. HakiCC instantiates this agentic paradigm for C protocol design, pairing specialized proposal and generation agents with a serializability verifier that enforces a for- mal correctness criterion in the loop. Evolutionary Optimization. Evolutionary programming is a classical approach to program synthesis that uses mutation and crossover operators to evolve a population of candidate programs [25, 29]. Evolutionary algorithms have been applied to regression [33, 44], automated algorithm and scientific discovery [9,13], and sched- uling [66]. However, these methods rely on handcrafted evolution operators that are difficult to design and may fail to capture domain- specific properties. Recent work has improved on this by replacing traditional oper- ators with LLMs [2,37,43,46]. FunSearch [43] pairs a pretrained LLM with a systematic evaluator in an evolutionary loop, allow- ing the LLM to propose program mutations guided by feedback. AlphaEvolve [37] extends this by enabling evolution over entire codebases, supporting multi-objective optimization, and using fron- tier LLMs as mutation engines. HakiCC builds on OpenEvolve [46], an open-source implementation of AlphaEvolve, to drive Stage 2 optimization of C protocol implementations. Evolutionary optimization has recently been applied to systems research problems more broadly [10,12,15,49]. Authors in [11] present case studies across cloud scheduling, load balancing, SQL query optimization, and transaction scheduling. They argue that the key challenge for AI in systems is problem formulation and strategic guidance rather than low-level implementation. HakiCC extends this direction to C protocol design, applying LLM-driven evolutionary optimization with correctness and throughput as joint objectives. 7 Conclusion We presented HakiCC, a two-stage LLM-driven pipeline that auto- matically designs, verifies, and optimizes application-specific con- currency control protocols with minimal human intervention. Run- ning HakiCC on TPC-C and AuctionMark produced ten protocols, all of which are verified for conflict-serializability after Stage 1, with Stage 2 improving the combined correctness-throughput score for nine out of ten protocols, yielding average throughput gains of +50.6% for TPC-C and +92.2% for AuctionMark. The ten generated protocols span multiple design families, including pessimistic, opti- mistic, versioned, deterministic, and semantic designs, confirming that application-conditioned generation produces structural diver- sity rather than converging on a single template. HakiCC establishes correctness empirically rather than by formal proof, and integrat- ing formal verification while extending the pipeline to distributed protocols is a natural next step. HakiCC proves that LLM-driven agentic pipelines can serve as practical tools for C protocol design, producing correct and competitive protocols across diverse OLTP workloads. 12 HakiCC: LLM-Driven Multi-Agent Design and Optimization of Concurrency Control ProtocolsSIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USA References [1]Anthropic. 2025. Claude Code: Agentic Coding in the Terminal. https://w. anthropic.com/claude-code. [2]Henrique Assumpção, Diego Ferreira, Leandro Campos, and Fabricio Murai. 2025. Codeevolve: An open source evolutionary coding agent for algorithm discovery and optimization. arXiv preprint arXiv:2510.14150 (2025). [3] Philip A. Bernstein and Nathan Goodman. 1980. Timestamp-Based Algorithms for Concurrency Control in Distributed Database Systems. In Proceedings of the International Conference on Very Large Data Bases (VLDB). 285–300. [4]Philip A Bernstein and Nathan Goodman. 1983. Multiversion concurrency con- trol—theory and algorithms. ACM Transactions on Database Systems (TODS) 8, 4 (1983), 465–483. [5]Philip A Bernstein, Vassos Hadzilacos, Nathan Goodman, et al.1987. Concurrency control and recovery in database systems. Vol. 370. Addison-wesley Reading. [6]Michael J Cahill, Uwe Röhm, and Alan D Fekete. 2008. Serializable Isolation for Snapshot Databases. In Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data. 729–738. https://doi.org/10.1145/1376616. 1376690 [7] Harrison Chase. 2022. LangChain. https://github.com/langchain-ai/langchain. [8]Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al.2021. Evaluating Large Language Models Trained on Code. arXiv preprint arXiv:2107.03374 (2021). [9]Xiangning Chen, Chen Liang, Da Huang, Esteban Real, Kaiyuan Wang, Hieu Pham, Xuanyi Dong, Thang Luong, Cho-Jui Hsieh, Yifeng Lu, et al.2023. Symbolic discovery of optimization algorithms. Advances in neural information processing systems 36 (2023), 49205–49233. [10]Audrey Cheng, Shu Liu, Melissa Pan, Zhifei Li, Shubham Agarwal, Mert Cemri, Bowen Wang, Alexander Krentsel, Tian Xia, Jongseok Park, et al.2025. Let the Barbarians In: How AI Can Accelerate Systems Performance Research. arXiv preprint arXiv:2512.14806 (2025). [11] Audrey Cheng, Shu Liu, Melissa Pan, Zhifei Li, Bowen Wang, Alex Krentsel, Tian Xia, Mert Cemri, Jongseok Park, Shuo Yang, et al.2025. Barbarians at the gate: How ai is upending systems research. arXiv preprint arXiv:2510.06189 (2025). [12]Audrey Cheng, Harald Ng, Aaron Kabcenell, Peter Bailis, Matei Zaharia, Lin Ma, Xiao Shi, and Ion Stoica. 2026. AI-Driven Research for Databases. arXiv preprint arXiv:2604.06566 (2026). [13]Miles Cranmer. 2023. Interpretable machine learning for science with PySR and SymbolicRegression. jl. arXiv preprint arXiv:2305.01582 (2023). [14]Djellel Eddine Difallah, Andrew Pavlo, Carlo Curino, and Philippe Cudré- Mauroux. 2013. OLTP-Bench: An Extensible Testbed for Benchmarking Relational Databases. PVLDB 7, 4 (2013), 277–288. http://w.vldb.org/pvldb/vol7/p277- difallah.pdf [15]Mehmet Hamza Erol, Xiangpeng Hao, Federico Bianchi, Ciro Greco, Jacopo Tagliabue, and James Zou. 2026. Making Databases Faster with LLM Evolutionary Sampling. arXiv preprint arXiv:2602.10387 (2026). [16]Jose M Faleiro and Daniel J Abadi. 2014. Rethinking serializable multiversion concurrency control. arXiv preprint arXiv:1412.2324 (2014). [17]Juncheng Fang, Farzad Habibi, Binbin Gu, and Faisal Nawab. 2026. Immortal- Chopper: Real-Time and Resilient Distributed Transactions in the Edge-Cloud. In 2026 IEEE 42nd International Conference on Data Engineering (ICDE). IEEE, 2008–2020. [18]Zhihan Guo, Kan Wu, Cong Yan, and Xiangyao Yu. 2021. Releasing locks as early as you can: Reducing contention of hotspots by violating two-phase locking. In Proceedings of the 2021 International Conference on Management of Data. 658–670. [19]Farzad Habibi, Juncheng Fang, Tania Lorido-Botran, and Faisal Nawab. 2026. Brook-2PL: Tolerating High Contention Workloads with A Deadlock-Free Two- Phase Locking Protocol. Proceedings of the ACM on Management of Data (2026). https://doi.org/10.1145/3769767 [20]Sirui Hong, Mingchen Zhuge, Jiaqi Chen, Xiawu Zheng, Yuheng Cheng, Ceyao Zhang, Jinlin Wang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. 2024. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. In International Conference on Learning Representations (ICLR). [21]Paul Jaccard. 1912. The distribution of the flora in the alpine zone. New Phytologist 11, 2 (1912), 37–50. [22]Nathan Jay, Noga H Rotman, P Godfrey, Michael Schapira, and Aviv Tamar. 2018. Internet congestion control via deep reinforcement learning. arXiv preprint arXiv:1810.03259 (2018). [23]Robert Kallman, Hideaki Kimura, Jonathan Natkins, Andrew Pavlo, Alexander Rasin, Stanley Zdonik, Evan P. C. Jones, Samuel Madden, Michael Stonebraker, Yang Zhang, John Hugg, and Daniel J. Abadi. 2008. H-Store: A High-Performance, Distributed Main Memory Transaction Processing System. Proceedings of the VLDB Endowment 1, 2 (2008), 1496–1499. [24] Kate Keahey, Jason Anderson, Zhuo Zhen, Pierre Riteau, Paul Ruth, Dan Stanzione, Mert Cevik, Jacob Colleran, Haryadi S. Gunawi, Cody Hammock, Joe Mambretti, Alexander Barnes, François Halbach, Alex Rocha, and Joe Stubbs. 2020. Lessons Learned from the Chameleon Testbed. In Proceedings of the 2020 USENIX Annual Technical Conference (USENIX ATC ’20). USENIX Association. [25]John R Koza. 1994. Genetic programming as a means for programming computers by natural selection. Statistics and computing 4, 2 (1994), 87–112. [26]Tim Kraska, Alex Beutel, Ed H Chi, Jeffrey Dean, and Neoklis Polyzotis. 2018. The case for learned index structures. In Proceedings of the 2018 international conference on management of data. 489–504. [27]Hsiang-Tsung Kung and John T Robinson. 1981. On optimistic methods for concurrency control. ACM Transactions on Database Systems (TODS) 6, 2 (1981), 213–226. [28]LangChain Inc. 2024. LangGraph: Building Stateful, Multi-Agent Workflows. https://github.com/langchain-ai/langgraph. [29] William B Langdon and Riccardo Poli. 2002. Foundations of genetic programming. Vol. 90. Springer. [30]Per-Åke Larson, Spyros Blanas, Cristian Diaconu, Craig Freedman, Jignesh M Pa- tel, and Mike Zwilling. 2011. High-performance concurrency control mechanisms for main-memory databases. arXiv preprint arXiv:1201.0228 (2011). [31]Justin Levandoski, David Lomet, Sudipta Sengupta, Ryan Stutsman, and Rui Wang. 2015. Multi-version range concurrency control in deuteronomy. Proceedings of the VLDB Endowment 8, 13 (2015), 2146–2157. [32]Hyeontaek Lim, Michael Kaminsky, and David G Andersen. 2017. Cicada: De- pendably fast multi-core in-memory transactions. In Proceedings of the 2017 ACM International Conference on Management of Data. 21–35. [33]He Ma, Arunachalam Narayanaswamy, Patrick Riley, and Li Li. 2022. Evolving symbolic density functionals. Science Advances 8, 36 (2022), eabq0279. [34] Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, Shashank Gupta, Bodhisattwa Prasad Majumder, Katherine Hermann, Sean Welleck, Amir Yazdanbakhsh, and Peter Clark. 2023. Self-Refine: Iterative Refinement with Self-Feedback. In Advances in Neural Information Processing Systems, Vol. 36. [35] Ryan Marcus, Parimarjan Negi, Hongzi Mao, Chi Zhang, Mohammad Alizadeh, Tim Kraska, Olga Papaemmanouil, and Nesime Tatbul. 2019. Neo: A learned query optimizer. arXiv preprint arXiv:1904.03711 (2019). [36]Jean-Baptiste Mouret and Jeff Clune. 2015. Illuminating search spaces by mapping elites. arXiv preprint arXiv:1504.04909 (2015). [37] Alexander Novikov, Ngân V ̃ u, Marvin Eisenberger, Emilien Dupont, Po-Sen Huang, Adam Zsolt Wagner, Sergey Shirobokov, Borislav Kozlovskii, Francisco JR Ruiz, Abbas Mehrabian, et al.2025. Alphaevolve: A coding agent for scientific and algorithmic discovery. arXiv preprint arXiv:2506.13131 (2025). [38]Patrick E. O’Neil. 1986. The Escrow Transactional Method. ACM Transactions on Database Systems 11, 4 (1986), 405–430. [39]Hexiang Pan, Shaofeng Cai, Tien Tuan Anh Dinh, Yuncheng Wu, Yeow Meng Chee, Gang Chen, and Beng Chin Ooi. 2026. Modeling Concurrency Control as a Learnable Function. Proceedings of the ACM on Management of Data 4, 3 (SIGMOD (2026), 1–28. [40] Christos H Papadimitriou. 1979. The serializability of concurrent database up- dates. Journal of the ACM (JACM) 26, 4 (1979), 631–653. [41] Guna Prasaad, Alvin Cheung, and Dan Suciu. 2020. Handling highly contended OLTP workloads using fast dynamic partitioning. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data. 527–542. [42]Kun Ren, Jose M Faleiro, and Daniel J Abadi. 2016. Design principles for scaling multi-core oltp under high contention. In Proceedings of the 2016 International Conference on Management of Data. 1583–1598. [43]Bernardino Romera-Paredes, Mohammadamin Barekatain, Alexander Novikov, Matej Balog, M Pawan Kumar, Emilien Dupont, Francisco JR Ruiz, Jordan S Ellenberg, Pengming Wang, Omar Fawzi, et al.2024. Mathematical discoveries from program search with large language models. Nature 625, 7995 (2024), 468–475. [44] Michael Schmidt and Hod Lipson. 2009. Distilling free-form natural laws from experimental data. science 324, 5923 (2009), 81–85. [45]Zechao Shang, Feifei Li, Jeffrey Xu Yu, Zhiwei Zhang, and Hong Cheng. 2016. Graph analytics through fine-grained parallelism. In Proceedings of the 2016 International Conference on Management of Data. 463–478. [46]Asankhaya Sharma. 2025. OpenEvolve: an open-source evolutionary coding agent. https://github.com/algorithmicsuperintelligence/openevolve [47]Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2023. Reflexion: Language Agents with Verbal Reinforcement Learning. In Advances in Neural Information Processing Systems, Vol. 36. [48]Chunzhi Su, Natacha Crooks, Cong Ding, Lorenzo Alvisi, and Chao Xie. 2017. Bringing modular concurrency control to the next level. In Proceedings of the 2017 ACM International Conference on Management of Data. 283–297. [49]Jacopo Tagliabue. 2025. AI for Distributed Systems Design: Scalable Cloud Optimization Through Repeated LLMs Sampling And Simulators. arXiv preprint arXiv:2510.18897 (2025). [50]Dixin Tang and Aaron J Elmore. 2018. Toward coordination-free and reconfig- urable mixed concurrency control. In 2018 USENIX Annual Technical Conference (USENIX ATC 18). 809–822. 13 SIGMOD ’27, June 13-19, 2027, Huntington Beach, CA, USAFarzad Habibi, Juncheng Fang, and Faisal Nawab [51]Dixin Tang, Hao Jiang, and Aaron J Elmore. 2017. Adaptive Concurrency Control: Despite the Looking Glass, One Concurrency Control Does Not Fit All.. In CIDR, Vol. 2. 1. [52] The Transaction Processing Council. 2007. TPC-C Benchmark (Revision 5.9.0). [53]Alexander Thomson, Thaddeus Diamond, Shu-Chun Weng, Kun Ren, Philip Shao, and Daniel J Abadi. 2012. Calvin: fast distributed transactions for partitioned database systems. In Proceedings of the 2012 ACM SIGMOD international conference on management of data. 1–12. [54] Stephen Tu, Wenting Zheng, Eddie Kohler, Barbara Liskov, and Samuel Madden. 2013. Speedy transactions in multicore in-memory databases. In Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles. 18–32. [55]Dana Van Aken, Andrew Pavlo, Geoffrey J Gordon, and Bohan Zhang. 2017. Automatic database management system tuning through large-scale machine learning. In Proceedings of the 2017 ACM international conference on management of data. 1009–1024. [56]Jiachen Wang, Ding Ding, Huan Wang, Conrad Christensen, Zhaoguo Wang, Haibo Chen, and Jinyang Li. 2021. Polyjuice:High-Performancetransactions via learned concurrency control. In 15th USENIX Symposium on Operating Systems Design and Implementation (OSDI 21). 198–216. [57]Tianzheng Wang and Hideaki Kimura. 2016. Mostly-optimistic concurrency control for highly contended dynamic workloads on a thousand cores. Proceedings of the VLDB Endowment 10, 2 (2016), 49–60. [58]Zhaoguo Wang, Shuai Mu, Yang Cui, Han Yi, Haibo Chen, and Jinyang Li. 2016. Scaling multicore databases via constrained parallel execution. In Proceedings of the 2016 International Conference on Management of Data. 1643–1658. [59] Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W White, Doug Burger, and Chi Wang. 2023. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv preprint arXiv:2308.08155 (2023). [60] John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. In Advances in Neural Information Processing Systems, Vol. 37. [61]Zongheng Yang, Wei-Lin Chiang, Sifei Luan, Gautam Mittal, Michael Luo, and Ion Stoica. 2022. Balsa: Learning a query optimizer without expert demonstrations. In Proceedings of the 2022 International Conference on Management of Data. 931–944. [62]Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. In International Conference on Learning Representations (ICLR). [63]Philip S. Yu and Daniel M. Dias. 1992. Analysis of hybrid concurrency control schemes for a high data contention environment. IEEE Transactions on Software Engineering 18, 2 (1992), 118. [64]Xiangyao Yu, George Bezerra, Andrew Pavlo, Srinivas Devadas, and Michael Stonebraker. 2014. Staring into the abyss: An evaluation of concurrency control with one thousand cores. (2014). [65]Xiangyao Yu, Andrew Pavlo, Daniel Sanchez, and Srinivas Devadas. 2016. TicToc: Time Traveling Optimistic Concurrency Control. In Proceedings of the 2016 In- ternational Conference on Management of Data. https://doi.org/10.1145/2882903. 2882935 [66]Fangfang Zhang, Su Nguyen, Yi Mei, and Mengjie Zhang. 2021. Genetic Program- ming for Production Scheduling. Springer. 14