Where LLM Agents Get Stuck Debugging Databases: Access More Than Reasoning

Where LLM Agents Get Stuck Debugging Databases: Access More Than Reasoning Gustavo Pintoa,∗

arXiv:2611.17304v1 [cs.SE] 12 Nov 2026

a Federal University of Pará (UFPA), Belém, Pará, Brazil

ARTICLE INFO

ABSTRACT

Keywords: AI coding agents database performance incident management root cause analysis observability

Large language model (LLM) coding agents are increasingly asked not only to write code but to debug running systems from live runtime data. We report a field observation of one such agent (Claude Code) as it diagnosed eight database incidents in a production message-dispatch engine. In every incident whose root cause depended on runtime concurrency, the agent announced a cause, shipped a fix, and later walked it back, and each wrong guess cost a deploy-and-observe cycle. Mapping each incident to what the agent lacked, we find that access to production state was the most pervasive bottleneck. The missing access included live lock views, untruncated deadlock reports, read-only execution, and an explicit environment context. An access gap was present in all five concurrency-dependent incidents: alone in one, and in four combined with a reasoning error such as anchoring on an early cause, incomplete exploration of the configuration, or a misreading of the code’s transaction semantics. The three incidents that did not depend on concurrency needed nothing beyond what the agent already had. Within the incidents, the agent’s wrong hypotheses were consistent with the evidence it could see; they were not fabrications. We argue that the next step for production-debugging agents is a forensics layer that gives the agent the access it lacks inside existing security controls. Such a layer would combine a safe interrogation API, a lock-and-deadlock flight recorder, and a production replay harness.

1. Introduction Large language model (LLM) coding agents are widely used to write and review code (Yang, Jimenez, Wettig, Lieret, Yao, Narasimhan and Press, 2024; Watanabe, Li, Kashiwa, Reid, Iida and Hassan, 2026). A harder use is now emerging: teams give these agents live runtime data, such as logs, database state, and transient failures, and ask them to debug production systems. Unlike code completion, this requires acting on a live system under time pressure, with real consequences. Industry has started building LLM agents for incident management (Chen, Xie, Ma, Kang, Gao, Shi, Cao, Gao, Fan, Wen, Zeng, Ghosh, Zhang, Zhang, Lin, Rajmohan, Zhang and Xu, 2024; Roy, Zhang, Bhave, Bansal, LasCasas, Fonseca and Rajmohan, 2024; Wang, Liu, Zhang, Zhong, Wang, Yin, Fan, Wu and Wen, 2024b), and the database community has proposed agents specialized in database diagnosis (Zhou, Li, Sun, Liu, Chen, Wu, Liu, Feng and Zeng, 2024; Singh, Vaidya, Bannihatti, Khosla, Narayanaswamy, Gangadharaiah and Kraska, 2024). Among the systems these agents are asked to debug, databases are a particularly difficult class. Failures such as lock contention, deadlocks, and race conditions emerge from the interaction of concurrent workloads, and they are shortlived: by the time the agent looks at the logs, the lock may already be gone. The agent must therefore diagnose the failure from after-the-fact evidence rather than from a reproducible state. Getting the diagnosis wrong is costly. A missed root cause means a deploy that does not fix the problem, or a second incident, and each redeploy runs through a slow delivery pipeline (Section 6). The cost is also human: while ∗ Corresponding author

gpinto@ufpa.br (G. Pinto)

ORCID (s): 0000-0001-7598-2799 (G. Pinto)

Gustavo Pinto: Preprint submitted to Elsevier

the failure persists, the developers on call are under pressure to restore service, and every fix that does not hold sends them back to waiting on the pipeline. An agent that converges in one attempt rather than several is worth a great deal. We know surprisingly little about where such agents get stuck. Most of the research focuses on how well agents write code (Jimenez, Yang, Wettig, Yao, Pei, Press and Narasimhan, 2024; Xia, Deng, Dunn and Zhang, 2025), not on how well they debug running systems. Where operations agents are evaluated, it is mostly on benchmarks that inject faults into controlled environments with complete telemetry (Chen, Shetty, Somashekar, Ma, Simmhan, Mace, Bansal, Wang and Rajmohan, 2025; Jha, Arora, Watanabe, Yanagawa, Chen, Clark, Bhavya, Verma, Kumar, Kitahara, Zheutlin, Takano, Pathak, George, Wu, Turkkan, Vanloo, Nidd, Dai, Chatterjee, Gupta, Samanta, Aggarwal, Lee, Ahn, Kar, Paradkar, Deng, Moogi, Mohapatra, Abe, Narayanaswami, Xu, Varshney, Mahindru, Sailer, Shwartz, Sow, Fuller and Puri, 2025; Xu, Zhang, Zhong, He, Zhang, Lin, Pei, He, Zhang and Zhang, 2025). As a result, the natural assumption that the limit is the model’s reasoning has gone largely untested in the field. The assumption matters because it determines where effort goes. If the agent’s mistakes are reasoning failures, or hallucinations in the sense of confident fabrications (Zhang, Wang, Wang, Shi, Ma, Zhong, Chen, Mao and Zheng, 2025), then the answer is a more capable, better-grounded model. If instead the limit is access to logs, to the database, or to a way of reproducing the failure, then investment in larger models addresses the wrong problem. Access is also hard to grant. Companies wrap production in layers of security, such as VPNs, identity management, and read-only proxies, that an agent cannot cross directly. In practice, a human

Page 1 of 12

Access More Than Reasoning

engineer still does the manual work the agent would otherwise automate: searching logs, running read-only SQL against production, and reading raw output to reconstruct what happened. This paper studies that question in the field. We follow an LLM agent (Claude Code) as it diagnosed and fixed a series of real database incidents in a production messagedispatch engine at a large technology company. We combine the agent’s session transcripts, which contain its private reasoning and its public answers, with the repository’s commit history, which independently records each fix that was made and each fix that was undone. Our research question is: RQ. What limits an LLM coding agent’s diagnosis of production database incidents: its reasoning or its access? Our answer is a qualified one: mostly access. An access gap was present in all five incidents whose root cause depended on runtime concurrency. In one of them it was the only limit. In the other four it combined with a reasoning error, and in each of those the error was corrected only through production evidence that the agent could not obtain directly. Within the incidents, the agent’s wrong guesses were reasonable inferences from incomplete information rather than fabrications. This paper makes the following contributions: • to our knowledge, the first field report of an LLM agent debugging database incidents in a live system, using the agent’s own transcripts and the commit history as primary evidence, including a record of how it converged by serial self-correction at the cost of a deploy cycle per wrong guess; • a reasoning × access matrix, derived from the eight incidents, that separates the gaps in the agent’s access from its reasoning errors and shows where the two interact; • a concrete agenda for tool builders, made of a safe database forensics API, a lock-and-deadlock flight recorder, and a production replay harness, that restores the agent’s access without lowering the security controls already in place.

2. Background 2.1. The System and Its Workload The system under study is a message-dispatch engine (WhatsApp, SMS, and e-mail) for B2B marketing campaigns, operated by a large technology company. The stack is Python and SQLAlchemy (asyncpg) behind PgBouncer, on Kubernetes, with Datadog observability. The engine follows a three-stage pipeline: • Compile. A trigger (a scheduler tick, a manual action, or an event) invokes the journey compiler. The compiler resolves the audience from a customer data Gustavo Pinto: Preprint submitted to Elsevier

platform (CDP), materializes per-customer attributes from an entity–attribute–value (EAV) store of about 38.5 million rows across 369 dynamic columns, and applies capping and routing rules. • Orchestration. The engine selects eligible customers, enforcing one message per customer per day, a phonenumber cascade, and coverage constraints. It materializes them as rows in the dispatch-queue table, which is the single source of truth. This stage has produced 3,089 journey executions. • Dispatch. A worker claims queue rows in batches of one hundred under advisory locks and sends each message through the appropriate delivery provider. Webhooks then record the delivery status. The workload explains why the locking layer is under pressure. The CDP’s distinct-customer base grew from roughly 330,000 in July to about 587,000 by November (Figure 1b). Over its lifetime the dispatch queue has accumulated about 4.9 million rows and sent about 3.3 million messages. A single journey can materialize hundreds of thousands of queue rows; the largest execution held 331,000, and up to 22,000 rows were observed pending at once. Dispatch load is concentrated in the morning, with the heaviest sending window between 09:00 and 12:00 local time; in October, that three-hour window accumulated roughly 600,000 messages over the month. Figure 1 shows the ramp-up over time.

2.2. Development Context The repository holds roughly 406,000 lines of source code (Python, TypeScript, and SQL), about 182,000 of them tests, with 84% line coverage. Over four months it accumulated 1,019 commits by five developers, of which 293 (29%) carry an AI co-author trailer: 289 name Claude Code and four name Cursor. The trailer is used by only two of the five developers, so it understates the agent’s involvement. Production was deployed on most business days, with 232 production deployments over 126 days (Figure 2). The codebase did not start from scratch. It was first built with an AI coding agent on the Replit platform and was imported into the company’s infrastructure in a single commit of about 241,000 lines in July 2026. Many defects of that version surfaced only under production load and real data. We return to this origin as a threat to validity in Section 7. The engineer instructs Claude Code through naturallanguage prompts in a spec-first and test-first style: each non-trivial change starts with a short specification, is implemented against a failing test, and is verified with a regression test. The agent runs with elevated permissions (bypassPermissions) and commits under the engineer’s identity. A persistent memory directory (.memory/) records decisions, lessons, and, most relevant here, refuted hypotheses, so that a fresh session can resume without re-litigating settled questions. Every change passes through a merge request that a second developer must approve. Page 2 of 12

Access More Than Reasoning (a) throughput per week messages sent / week rows materialized / week

800k

600k

customers

rows / week

800k

400k 200k 0

(b) CDP customers (cumulative)

600k 400k 200k

Aug 2026

Sep 2026

Oct 2026

Nov 2026

0

Jul 2026

Aug 2026

Sep 2026

Oct 2026

Nov 2026

Figure 1: Dispatch workload over time: (a) messages sent and queue rows materialized per week; (b) cumulative distinct customers in the CDP.

Commits and production deployments per day 70 60

commits / day production deployments / day

count / day

50 40 30 20 10 0

Aug 2026

Sep 2026

Oct 2026

Nov 2026

Figure 2: Commits and production deployments per day over the project lifetime (July–November 2026): blue bars are production deployments, the black line with markers is commits.

3. Method This study is a field observation conducted through participant observation (Ko, 2017). The author was employed at the company under study while the incidents occurred and directed the agent as part of ordinary work. The analysis is retrospective: it reconstructs the agent’s behavior from artifacts produced during that work, not from a controlled experiment. The company requested anonymity, so we refer to it only as “a large technology company.” The unit of analysis is the incident. We study eight database incidents that occurred over a ten-day window, each a distinct failure the agent was asked to diagnose and fix. We also draw on sessions from the preceding two weeks when they bear on the same failure surface. We lack both a controlled comparison, since we cannot vary the agent’s access or its reasoning, and ground truth about what would

Gustavo Pinto: Preprint submitted to Elsevier

have happened otherwise. We therefore triangulate three independent artifacts: session transcripts, commit history, and deployment and workload records. Each captures a different facet of the agent’s behavior, and we treat agreement across them as the evidence. The study spans 27 agent sessions and about 410 hours of cumulative session time, during which the agent issued about 3,000 tool calls. The session time is the sum, per session, of the last event timestamp minus the first; sessions stayed open across working days rather than running continuously. Roughly two thirds of the tool calls were shell commands; the rest were file edits, task tracking, and platform API calls. Claude Code’s model calls go through the company’s internal generative-AI platform, which exposes several models; the user selects the model in the tool’s configuration, and the session logs record the model that served each call. Most calls were served by an open-weights model Page 3 of 12

Access More Than Reasoning

(DeepSeek, about 79%), which the company encourages for cost, and a minority by a frontier model (Claude Opus, about 17%). We did not attribute individual hypotheses to models, so we make no claim about whether a different model would have avoided a given false start (Section 7).

3.1. Study Setting and Access The agent’s access was asymmetric: broad in the development environment and narrow in production. In development it had everything a developer has: • Repository: read and write access to the local clone, and access to the remote repository through a GitLab MCP server, including merge requests and history; • Local execution: the logs of the application running locally; • Tests: the output of the unit tests and of the integration tests, which run against a local database. This access let the agent read any line of code and reproduce any failure that a single local process with a local database can produce. The incidents we study are the ones it cannot: their failures emerge only under production’s concurrent load and data. For this class of runtime failures, access to the code is necessary but not sufficient. The code says what can happen; resolving the incident requires knowing what did happen, and that knowledge lives in production. Into production, by contrast, the agent has three partial channels, all incomplete: • Logs via skills: log search over Datadog and Kubernetes. Indexed datasets require browser authentication, which the agent does not have. • Read-only database: the agent writes the SQL, but a human runs it through a read-only productiondatabase proxy, which cannot execute, scale, or restart anything. A human could therefore run a pg_locks query for the agent, but each query took a round trip through a person and returned a snapshot taken after the agent asked, by which time a transient lock could already be gone. • kubectl: cluster access, but without exec into the database, without the ability to restart or scale pods, and with an environment context that must be switched manually.

3.2. Data Sources and Analysis We draw on three artifacts. First, the agent’s session transcripts (JSONL), which record both its private reasoning (thinking) and its public answers (text). This trajectorylevel view follows recent studies of coding-agent behavior (Bouzenia and Pradel, 2025), but applies it to a production setting rather than a benchmark. Second, the repository’s commit history, which records each fix the agent shipped and each fix it later corrected or reverted. Third, deployment and workload records: production deployments from the Gustavo Pinto: Preprint submitted to Elsevier

platform’s API, and read-only database queries covering the customer base and the hourly dispatch volume. Incident selection. We included every database incident in the window that the team worked on with the agent. Five of the eight began with a false start, two did not, and in one the first fix only mitigated the symptom. We analyzed the data in two passes: • Qualitative. We read the transcripts incident by incident and reconstructed the sequence of hypotheses and fixes. We coded each hypothesis as held or retracted using two independent signals: the agent’s own later statements (“The fix did NOT resolve the slowness”) and the commit history (a later commit that corrects an earlier one). A false start is a hypothesis or fix that at least one of these signals marks as retracted. For each retracted hypothesis we then coded its source using two operational criteria. A hypothesis is evidence-consistent if it agreed with everything the agent had observed up to that point in the session; it is a fabrication if it asserted a fact contradicted by evidence already in the agent’s context. We also recorded whether the information that eventually refuted it was available to the agent (in the repository, the documentation, or its tools) or out of its reach. The sessions are mostly in Portuguese, with some agent turns in English; quotations from Portuguese turns are the author’s translations, and all quotations are otherwise unedited except that system- and companyidentifying names are replaced with generic descriptors. • Quantitative. We measured, per incident, the number of fix commits, whether the first attempt held, and the number of production deployments on the incident’s day (Table 1). Commits and lines of code come from git; code size at a revision is the number of newline characters in all tracked .py, .ts, .tsx, and .sql files. Deployments come from the platform’s deployment API, filtered to production environments.

4. Database Incidents and the Agent’s False Starts Eight incidents occurred over ten days, and six of them converged on a single failure surface: the locking and transactional-consistency layer of the dispatch engine. Table 1 lists them and quantifies the pattern they share: the agent was never wrong in the end, but it was often wrong serially: it announced a cause, shipped a fix, and walked it back, at the cost of a deploy cycle per wrong guess. The repository records the same churn from the outside: dispatch_service.py alone was touched fourteen times. The production deployment record shows the cost: on every incident day the team shipped between two and four production deployments. We trace each incident, and the evidence of its false start, below.

Page 4 of 12

Access More Than Reasoning Table 1 The eight incidents, their fix commits, the production deployments on the incident’s day, and whether the first attempt held. # #1

Day D2

Incident Memory exhaustion

#2

D3

Summary lock

#3

D4

Pair lock and ledger

#4

D5

Trigger committed early

#5 #6

D8 D9

Monitor card Throughput

Description OOM kills; stale read in the compile handler lock timeout; row lock held to commit unlock returned false; one session per event double-send risk; pause on bad phone journey canceled by orchestration the “tick” hypothesis refuted

Conc. —

Fixes 2

Deploys 2

First attempt held? Partly—symptom only



3

3

No—failure continued

6

3

No—corrected by next

—

2

2

Yes

— 

1 0

1 0



Yes No—six hypotheses refuted #7 D10 Race exposed a purge × orchestration race  5 2 No—wrong cause #8 D10 Deadlock retry retry rolled back between attempts  3 1 No—rollback was wrong Note:  marks the incidents whose root cause depended on runtime concurrency (locks, races, or concurrent throughput); all five began with a false start. Day is relative to the ten-day incident window (D1–D10). Fixes counts fix commits. Deploys counts the production deployments that carried each incident’s fixes. The throughput incident has no fix commit: its fix was a configuration change, raising the retry-sweep cap from five to eight pairs per tick in the deployment values, not a code change; its six hypotheses were refuted by measurement before that change. On the shared day of #7 and #8, eight fix commits crossed two merge requests: five belong to the race and three to the deadlock retry.

4.1. Memory exhaustion (—) The segmentation step loaded an entire audience into memory in one go, and the pod ran out of memory and was killed by the operating system (OOMKilled, exit 137), again and again, across all five pods. At the same time, the compile error handler read an object after its database transaction had already been rolled back, raising MissingGreenlet. The quick fix was to throw resources at the problem: the pod’s CPU request went from 50 m to 200 m, its CPU limit from 500 m to 1000 m, and its memory limit from 2 Gi to 4 Gi. This fix stopped the out-of-memory kills, so we code its first attempt as having held only in part. The underlying cause, materializing the whole audience instead of streaming it, was left open, and removing the memory pressure exposed the summary-lock timeout of incident #2: “The OOMKilled did not come back, good. But the lock timeout persists.”

4.2. Summary lock ()

Two parts of the engine were fighting over the same database row: the dispatch summary tried to write its result while holding a lock that its own next step then had to wait on, so it timed out waiting on itself. The agent’s first fix was an early commit: write the status sooner, so the lock is released. That was the false start: the logs show “summary_persist_failed continues (12 in 6min) . . . The fix did NOT resolve the slowness.” Only a third commit, which stopped the summary from holding that row lock at all, worked. Listing 1 shows the eventual fix: instead of flush(), which held the row lock until the final commit, the code now refresh()es after the separate summary session commits. +

execucao . exec_metadata = meta # marks the object dirty await self . db . flush () # flush holds the row lock until commit await self . db . refresh ( execucao ) # re - read after the summary session commits

Listing 1: The summary-lock fix, shown as a diff.

Gustavo Pinto: Preprint submitted to Elsevier

4.3. Pair lock and ledger ()

When the engine locked a pair of (journey, execution) to dispatch it, the unlock step silently failed—it returned false, and no one checked the return value. The agent’s first guess was to start checking that boolean; the real fix was the opposite—stop closing the transaction, so the lock stays on the same database connection under PgBouncer. The agent caught its own mistake mid-investigation: “But wait, line 1056 does await self.db.commit(), so there is a contradiction.” A second problem sat in the same area: the ledger opened one database session per event, about 600 roundtrips per batch, adding write contention; it was collapsed to one session per batch. Listing 2 shows the pair-lock fix: checking the boolean became keeping the transaction open. + + + +

res = await lock_conn . execute ( unlock_sql ) released = bool ( res . scalar () ) if got_lock : # do NOT rollback () : keep the PgBouncer # connection pinned to this client await self . _dispatch_impl (...)

Listing 2: The pair-lock fix, shown as a diff.

4.4. Trigger committed early (—) When a journey was triggered, the system saved (committed) the queue too early, before the orchestration step got a chance to run. If that step then failed, the orphaned rows were swept up and sent without any of the usual checks, risking the same message going out twice to one customer. The fix was to hold everything in a savepoint instead of committing, so a failure rolls the whole thing back rather than leaving the queue half-written. Listing 3 shows the change: the per-journey commit() became a begin_nested() savepoint. + + +

await self . db . commit () # queue persisted BEFORE orchestration async with self . db . begin_nested () : compile_journey ( journey ) run_for_day ( journey )

Page 5 of 12

Access More Than Reasoning +

# savepoint : one failure rolls back all

Listing 3: The trigger fix, shown as a diff.

4.5. Monitor card (—) One journey simply vanished from the operator’s screen. It had been canceled by the orchestration because another journey (same segment, same product, lower priority) had been paused since October; the execution closed with zero of 10,000 messages sent, and the card disappeared without explanation. The monitor was changed to keep recentlyfinished journeys visible for 24 hours and to show why they were blocked.

4.6. Throughput ()

An investigation that ran across sessions from D3 to D9 was one long false start: the agent proposed and discarded cause after cause before finding the real one. It began with the preflight query, guessing the per-message checks were the bottleneck, until a measurement put that at 0.34 s for 100 rows, far too cheap to explain the lag. It then blamed the scheduler tick, but raising the tick did not move throughput. Next the batch cap, but the effective rate was two batches per pass, below the cap of three. Then line eligibility, but the executions were terminating (11,476 sent, zero pending), so nothing was stuck. Then the volume throttle, but its value was NULL on every active journey. It even shortened the orphan grace period, and reverted it when it did not help. Only after all six did it find the real bottleneck: the retry sweep’s five-pairs-per-tick cap, which saturated during draining. The fix was a one-line configuration change that raised the cap, not a code change. We count this incident as concurrency-dependent because the bottleneck appeared only when many executions drained at once, a state that exists only under production’s concurrent load.

4.7. Race exposed ()

An optimization that read a batch of rows up front accidentally widened the gap between reading and writing, and another process (the compile purge) deleted rows in that gap, outside the lock. When the orchestration then tried to update those rows, it found zero, and the whole tick aborted before anything was sent. The agent first chased the wrong lead (“This is the smoking gun . . . the issue is [a frozen attribute store]”), a real but historical problem from late September, and even started in the wrong environment (“No, good catch. I was on sandbox . . . let me switch to the prod context”). The error it was chasing was this, raised when the per-day write found the row already deleted: StaleDataError: UPDATE statement on table ’dispatch_queue’ expected to update 1 row(s); 0 were matched

In plain terms: the code tried to update a row that another process had already deleted, and the database library, expecting exactly one row, aborted the whole tick before any message could be sent. Listing 4 shows the eventual fix.

Gustavo Pinto: Preprint submitted to Elsevier

+ + + + +

row = await self . db . get ( DispatchQueue , row_id ) row . status = CANCELLED # row may be purged stmt = ( update ( DispatchQueue ) . where ( DispatchQueue . id == row_id , DispatchQueue . status == PENDING ) . values ( status = CANCELLED )) await self . db . execute ( stmt ) # 0 rows : no op

Listing 4: The race fix, shown as a diff.

4.8. Deadlock retry ()

The agent’s own hotfix introduced a new bug. To make the orchestration survive a deadlock, it added a retry that called rollback() between attempts, and its own comment claimed this was safe (“rollback discards only the orchestration state”). It was not: the rollback wiped the trigger’s still-uncommitted work and expired every loaded object, so the next read raised MissingGreenlet, the same bug the hotfix had just fixed in the dispatch path. The fix was to retry inside a savepoint, never a rollback. Listing 5 shows the change. +

await db . rollback () # drops compiles , expires ORM objects async with db . begin_nested () : # retry in a nested transaction

Listing 5: The retry fix, shown as a diff.

4.9. Costly Convergence Seven of the eight incidents were resolved by a fix that held, and production recovered afterward. In the eighth (#1), the fix resolved the symptom and the underlying cause was deferred; the streaming rewrite of the segmentation step was not shipped during the study window. Every final fix was shipped by the team, and in the incidents covered by the transcripts it was the agent that wrote it. The pattern we report is therefore not one of failure but of costly convergence: the agent reached the right diagnosis every time, but often only after one or more wrong guesses. In our sample, the split follows concurrency. The two incidents with no false start (#4 and #5) and the one whose first fix only mitigated the symptom (#1) did not depend on runtime concurrency. All five concurrency-dependent incidents began with a false start; in them the root cause was hard to see without access to runtime state.

4.10. Why Database Bugs Are the Hard Case Most of these false starts are the cost of diagnosing from incomplete and transient signals, and none of them is a hallucination in our coding. A hallucination is a fabrication: it asserts a fact that the evidence already in view contradicts. A false start, as we use the term, is a hypothesis consistent with everything the agent had seen that turns out to be wrong. The two call for different remedies: hallucination calls for better grounding, and false starts call for better access. This reading is consistent with evidence that current LLMs detect data races and deadlocks reliably when the whole program is in view (Jain and Purandare, 2026). Our agent could Page 6 of 12

Access More Than Reasoning

also read the whole program, in the sense that every file of the repository was available to it, but two differences matter. First, those benchmark programs are small enough to fit in the model’s context, whereas our codebase has about 406,000 lines. The agent could read only the parts it chose to search, so a relevant fact could sit in the repository and still go unread, as the retry-sweep cap of incident #6 shows. Second, and more important for concurrency, the code describes which interleavings are possible, not which one occurred. That information lives in the runtime state, such as the locks held, the rows deleted, and the transactions left open, and the agent could not observe it. Not every error fits this reading, however. In four incidents the information that refuted the wrong hypothesis was within the agent’s reach. In the pair lock (#3), the agent’s first guess was contradicted by a line of code in the repository, and the agent caught the contradiction itself mid-investigation. In the throughput incident (#6), the retrysweep cap that turned out to be the bottleneck sat in the deployment values in the repository, and the agent explored six other causes before looking there. In the race (#7), the agent anchored on a real but historical cause from late September. In the deadlock retry (#8), the agent’s own comment claimed that rollback() was safe between attempts; SQLAlchemy’s documented semantics say otherwise. We code these as reasoning errors. In each case, though, an access gap was also present and shaped the error or delayed its correction: the missing live lock view in #3, the missing live metrics in #6, and the wrong environment in #7. In #8, the truncated deadlock report hid the deadlock cycle, so the agent could not remove the deadlock’s cause and chose to survive it with a retry; the retry’s rollback was the reasoning error. We therefore classify these four incidents as mixed in Section 5. We also observed one case close to a fabrication, outside the eight incidents: three days before the window (D-3), the agent reported a fix as done that had never reached the code, and it caught the discrepancy itself in a later turn (“The fix was NOT applied . . . the bug is still in app.py:51”). When the agent concluded that the preflight query was the bottleneck, it was not hallucinating; it was reasoning from the data it could see. It could read the retry-sweep cap in the deployment values, but it could not see that the cap was saturating during draining, which only live throughput metrics would have shown. The agent cannot run queries against the production database, so it must infer row-level state from logs: “I do not have access to the database nor exec in prod (I tried, no permission).” Locks and deadlocks are transient by nature: by the time the agent looks, the lock is gone, and the deadlock detail arrives truncated (“the DETAIL is STILL truncated . . . at the SOURCE”): DeadlockDetectedError: deadlock detected DETAIL: Process 3051747 waits for AccessExclusiveLock on tuple (128477,20) of relation 17528 . . . [truncated]

A deadlock happens when two transactions each hold a lock the other needs. The error’s DETAIL is the lock graph. It names which transaction is waiting for which lock and which transaction holds it, and it is precisely what identifies the Gustavo Pinto: Preprint submitted to Elsevier

deadlock cycle. Here the log was cut off at the source, so the agent could see that one process was waiting for a lock on a specific row, but not which process held that lock or what the rest of the cycle was. It knew a deadlock had happened, but not who was involved in it, and without that the root cause is a guess. The truncation itself is telling: the deadlock DETAIL is long, because it lists every process, what each waits for, and what blocks each. The application’s logging layer stores the exception in a fixed-length field that cuts it off partway. The full detail existed in the Postgres server’s own log—which has log_lock_waits enabled and logs the complete deadlock report—but the agent had access only to the application log. The information was not absent; it was out of reach. Even obtaining access cost a deploy. To see live lock state during the summary-lock incident, the agent had to write a pg_locks probe and ship it to production (“The pg_locks probe . . . will show the blocker_query”), turning a read into a release. Each wrong hypothesis then costs a full deploy–observe cycle before it can be refuted, and the indexed Datadog logs that would settle a diagnosis sit behind a login the agent cannot pass (“requires login”). For a bug class whose evidence is momentary and whose reproduction requires the concurrent load and external-system integration that a local replica cannot provide, the agent has no shortcut: it must guess, ship, and watch.

5. The Reasoning × Access Matrix For each incident we asked two questions. What did the agent lack in order to close the diagnosis? Was that missing piece a property of the environment (access) or of the agent (reasoning)? We coded an incident as access when the evidence that refuted the wrong hypothesis was out of the agent’s reach, as reasoning when it was available but went unused or was misread, and as mixed when both applied. Incidents without a wrong hypothesis are coded sufficient. Table 2 summarizes the result. The matrix splits cleanly along concurrency. The three incidents that did not depend on concurrency needed nothing the agent did not already have; in #1 the diagnosis was right and only the full fix was deferred. Every one of the five concurrency-dependent incidents had an access gap. In one (#2) it was the only limit. In the other four it combined with a reasoning error, and no incident was limited by reasoning alone. The mixed rows deserve a careful reading, because they are where a more capable model is most plausibly useful. In each of them, the reasoning error was retired by evidence rather than by reflection: a measurement refuted the throughput hypotheses, the historical cause was set aside once it was shown to date from September, and a renewed failure exposed the unsafe rollback. Better access would have shortened each of these loops, because it would have exposed the error before a deploy rather than after it. Whether a stronger model would have avoided the errors in the first place is a question our data cannot answer (Section 7).

Page 7 of 12

Access More Than Reasoning Table 2 What the agent lacked, by incident. # #1 #2 #3

Incident Memory exhaustion Summary lock Pair lock and ledger

#4 #5 #6

Trigger committed early Monitor card Throughput

#7 #8

Race exposed Deadlock retry

Conc. —   — —   

Access gap — Live pg_locks view Live pg_locks view — — Live throughput metrics to test each hypothesis Explicit environment context Full deadlock DETAIL (truncated)

We therefore state our central finding with that qualification: in our observation, access to production state was the most pervasive limit on the agent’s diagnosis, and where reasoning failed, it failed alongside an access gap that shaped the error or delayed its correction. The implication runs against the assumption that the model is the ceiling. In this setting, the instrumentation was at least as binding.

6. Discussion 6.1. Summary of Findings The paper’s main findings are threefold. First, the agent diagnosed by serial self-correction. It announced a cause, shipped a fix, and walked it back, at the cost of a deploy cycle per wrong guess. Across eight incidents it shipped twentytwo fix commits. All five concurrency-dependent incidents began with a false start, and the throughput investigation alone burned six hypotheses. Second, access was the most pervasive bottleneck. The reasoning × access matrix shows an access gap in all five concurrency-dependent incidents, alone in one and combined with a reasoning error in four, and no incident limited by reasoning alone. Third, this access is hard to grant by design, because production sits behind layers of security. The agent ran mostly on an efficient openweights model, with a frontier model as a minority. Because we did not attribute hypotheses to models, this mix neither supports nor undermines the access thesis; it is an open question that a controlled replay could settle (Section 9). A corollary follows for the engineers who operate these agents. The false starts were caught only because a human knew enough about concurrency to judge the hypothesis, demand the right evidence (a live lock view, an untruncated deadlock report), and verify that the fix held. The agent did not replace this expertise. It amplified its leverage, but only where a human could tell when the agent was wrong.

6.2. Implications for Tooling If access is the dominant bottleneck, the practical question for researchers and tool builders is how to give an agent better access for production database debugging. Our evidence suggests five concrete directions. The first three are the components of the forensics layer named in the abstract; the last two concern the agent’s workflow. Gustavo Pinto: Preprint submitted to Elsevier

Reasoning error — (cause identified; fix deferred) — First guess contradicted by the code — — Cap in deployment values not inspected Anchoring on a historical cause Misread rollback semantics

Limit Sufficient Access Mixed Sufficient Sufficient Mixed Mixed Mixed

One caveat frames what follows: this access cannot simply be granted. The target is a production database, and opening it to an agent is not a matter of toggling a permission. The environment sits behind a VPN and an identity-management layer, and every access to a service is brokered by a local access-control application that decides who may reach what. Any tooling must therefore live inside these layers, as a read-only, audited forensics surface rather than raw database credentials. This constraint is, in fact, why a purpose-built interrogation layer, and not a blanket grant of access, is the right shape for the problem. A safe interrogation layer for production databases. The agent’s largest gap is that it cannot ask the production database anything beyond a read-only projection: “I do not have access to the database nor exec in prod.” What it needs is a forensics API: a read-only surface exposing pg_locks, pg_stat_activity, query plans, and row-level state under the safety guarantees that already protect production, but rich enough to answer “which statement holds this lock?” This is the runtime counterpart of what SWE-agent calls the agent–computer interface (Yang et al., 2024), and of Panda’s grounding and affordance components (Singh et al., 2024), but it is exposed to an application-side agent under production security constraints rather than to a DBA tool. Standardizing such an API for agents is a concrete deliverable. Persistent capture of transient concurrency. Locks and deadlocks are momentary; the agent consistently arrived after the fact and found nothing (“the DETAIL is STILL truncated . . . at the SOURCE”). A “flight recorder” that continuously logs lock waits and full deadlock reports, instead of a log line that truncates at the interesting part, would turn an ephemeral failure into a queryable artifact. Reproducing production’s emergent behavior. The agent can replicate data volume locally, but not the concurrent workload and external-system integrations that produce the failure modes, so a local replica does not reproduce them. The transcripts make the gap concrete: the sandbox ran an older version than production, the agent could not query the sandbox database directly, external calls left transactions idle while holding locks, and deadlocks only emerged under the production cluster’s concurrent load. None of these is something a single local process reproduces. Fault-injection Page 8 of 12

Access More Than Reasoning

testbeds such as AIOpsLab (Chen et al., 2025) show that this kind of environment can be built for evaluation; a replay harness, built on traffic capture or a shadow environment fed by production traffic, applies the same idea to debugging, and is the missing piece between “I can read the logs” and “I can reproduce the bug.” Shortening the guess–ship–observe loop. Each wrong hypothesis cost a full deploy cycle, which is why the false starts in Section 4 were expensive. That cost is not just token spend and the engineer’s time to redo the work: a redeploy is slow here. The delivery pipeline runs roughly twelve minutes end to end across about twenty stages, and the unit-test stage alone takes about five and a half minutes, nearly half the pipeline. The mutation-testing stage, before it was disabled, added roughly an hour, about five times the rest of the pipeline combined. Fast fixes matter at this project’s scale of about 3.3 million messages and hundreds of thousands of customers, since a slow fix leaves customers unserved while the queue backs up. Tooling that lets an agent test a hypothesis against production before deploying, such as dry-run execution, EXPLAIN against a live replica, or a fast canary with fine-grained metrics, collapses the loop from “ship and watch” to “ask and answer.” Externalizing the hypothesis. The retract-and-retry pattern, a production analogue of the repetitive cycles observed in failing benchmark trajectories (Bouzenia and Pradel, 2025), suggests that agents should be forced to record each hypothesis and the evidence that retired it, rather than reasoning privately and correcting silently. The repository’s memory of refuted hypotheses already did this and is the cheapest intervention of all: a hypothesis ledger makes the false-start chain auditable and, over time, teaches the agent which classes of database failure to stop guessing about. Finally, these fixes are as much about the agent’s harness (the loop that grants tools, permissions, and context) as about the database. Harnesses today run a debugging task through the same loop as a code-generation task. A harness tuned for low-access debugging would treat a hypothesis as a firstclass object, persisted with its evidence across turns, and would prefer richer, safer read-only primitives, such as a forensics tool rather than raw log search.

7. Limitations This study is a retrospective field observation of a single agent on a single system, and its limitations follow from that design. Generalizability. The findings come from one messagedispatch engine with unusually heavy locking and concurrency, one team, and one agent, over a ten-day incident window. Whether the pattern holds for other systems, teams, or agents is open. Causality and model capability. We observed access gaps and false starts together, but without a controlled comparison we cannot show that the former caused the latter. The same limitation applies to model capability. Most calls were served by an open-weights model, we did not attribute Gustavo Pinto: Preprint submitted to Elsevier

individual hypotheses to the model that produced them, and the model mix reflects configuration choices made during ordinary work rather than a deliberate comparison. A frontier model might have avoided some of the reasoning errors in the mixed incidents. Selection. The eight incidents are those of a single tenday window, and only those the team worked on with the agent. With so few cases, the association between concurrency and false starts holds for our sample only. Construct validity and coding. The constructs, namely the false start, its source (evidence-consistent or fabrication), and the reasoning × access matrix, are our retrospective interpretation of eight incidents. A single author coded them, and that author was also the participant, so the matrix is a derived taxonomy rather than a validated measurement; we did not compute inter-rater agreement or perform member checking with the other developers. Quotations from Portuguese turns are the author’s translations. Confounds. The codebase was first built with an AI coding agent and inherited defects from that phase, so the density of concurrency bugs may be higher than in a conventionally developed system. A human ran the agent’s SQL through the read-only proxy. Over the ten-day window the agent wrote 28 such queries—25 of them in the single race incident—so this access was real but concentrated; we did not measure its round-trip latency.

8. Related Work Prior work on LLM agents for operations and debugging differs from ours along three axes: what evidence the agent is given, where the agent runs, and what counts as a failure. We organize the discussion around these axes rather than around individual systems. Evidence: curated bundles versus interrogation. Most incident-management systems assume the diagnostic evidence has already been collected, and they place the LLM at the end of that pipeline. RCACopilot (Chen et al., 2024) runs predefined incident handlers that gather diagnostic data, then asks the LLM to predict a root-cause category from that bundle and from similar historical incidents. The design is effective precisely because the expensive step, deciding what to collect, is encoded by engineers in advance. Roy et al. (Roy et al., 2024) move one step toward autonomy: a ReAct agent retrieves documents and, in a case study, calls the team’s own diagnostic services. RCAgent (Wang et al., 2024b) reaches a similar design from a different constraint: its tool-augmented agent runs on internally deployed models because company data cannot leave the organization. In all three systems the agent chooses among, or reads from, evidence channels that someone already built and authorized. In our setting no such channels existed for the decisive evidence: the lock graph, the full deadlock DETAIL, and the live row state. The agent’s false starts arose in that gap. Our contribution is to make that missing channel, rather than the reasoning step that consumes it, the object of study.

Page 9 of 12

Access More Than Reasoning

Databases and privileged telemetry. Database-specific agents make the same assumption, more strongly. D-Bot (Zhou et al., 2024) extracts diagnosis knowledge from documentation and coordinates several expert agents through tree-search reasoning over system metrics and statistics views. Panda (Singh et al., 2024) argues that ungrounded LLM answers are too generic for database engineers; it adds grounding in runtime context, verification through cited evidence, and an affordance component that flags the risk of a proposed action. Our observations support Panda’s diagnosis of the problem: our agent’s hypotheses were reasonable but ungrounded in runtime lock state. Both systems, however, treat access to pg_stat_activity, pg_locks, and metric histories as a given, which holds for a DBA tool running beside the database. Our agent worked as an application developer’s assistant, separated from those views by a VPN, an identity layer, and a read-only proxy that a human had to operate. In D-Bot’s and Panda’s terms, our incidents are cases where the grounding layer was simply absent. Our forensics-API proposal (Section 6.2) can be read as the minimal, security-compatible slice of that layer that an application-side agent needs. Environment: benchmarks versus production. A recent line of benchmarks evaluates operations agents in controlled environments. AIOpsLab (Chen et al., 2025) deploys microservice applications, injects faults, generates workloads, and exposes telemetry through a uniform agent–cloud interface. ITBench (Jha et al., 2025) spans site-reliability, compliance, and FinOps scenarios, and reports that state-ofthe-art agents resolve only a small fraction of the SRE tasks. OpenRCA (Xu et al., 2025) asks agents to locate root causes in 335 failures from enterprise systems, with over 68 GB of logs, metrics, and traces. The best model solves only about 11% of cases. These low scores are often read as evidence of a reasoning ceiling. Our field data suggest a complementary reading. Benchmarks give the agent complete observability by construction: every injected fault leaves its telemetry in the bundle. Their failures therefore isolate the cost of navigating abundant evidence. In production, the evidence for a concurrency failure may never be recorded at all, so the cost is incurred earlier, at collection time. Neither setting captures the other’s failure mode, which is why we argue that benchmarks should also vary what the agent can see, not only how hard the fault is to explain. Failure: final answers versus trajectories. Coding-agent research has shifted from end-to-end resolution rates toward the structure of agent behavior. SWE-bench (Jimenez et al., 2024) established issue resolution as the standard task. SWE-agent (Yang et al., 2024) showed that the design of the agent–computer interface, meaning the tools and the feedback they return, substantially changes performance with the model held fixed. Agentless (Xia et al., 2025) showed that a simple localize–repair–validate pipeline can match or outperform more autonomous agents. Bouzenia and Pradel (Bouzenia and Pradel, 2025) analyze thought– action–result trajectories and find that failing runs tend to fall into repetitive cycles, whereas successful runs balance Gustavo Pinto: Preprint submitted to Elsevier

exploration with validation. Our false starts are a production analogue of these cycles, with one important difference: in a benchmark, a failed validation costs a test run, whereas in our setting the only validation available was a deploy followed by observation of live traffic, which multiplied the cost of each cycle by the length of the delivery pipeline. Field studies of agentic coding, such as Watanabe et al. (Watanabe et al., 2026) on Claude Code pull requests, have so far focused on code-producing tasks and their acceptance. To our knowledge, the diagnosis of a running system has not been studied with the agent’s own transcripts as evidence. Reasoning about concurrency and the hallucination framing. Our claim that reasoning was not the dominant bottleneck is consistent with evidence that LLMs can reason about concurrency when the relevant facts are in view. Jain and Purandare (Jain and Purandare, 2026) find that frontier models reliably detect data races and deadlocks in concurrent programs under sequential consistency. That task gives the model a small program that fits in its context, with the bug visible in the code. Our agent could read the whole repository, but at about 406,000 lines it had to choose what to read, and the interleaving that actually occurred was recorded only in runtime state. Finally, Zhang et al. (Zhang et al., 2025) show that many of the hallucinations in repository-level code generation stem from missing context, such as unknown APIs or project-specific facts. We draw the same line between fabrication and missing information, but at runtime rather than in code. Within the incidents, our agent’s wrong hypotheses were not fabrications; they were explanations consistent with the evidence it could see. Within the standard architecture of LLM-based agents (planning, memory, tools, action) (Wang, Ma, Feng, Zhang, Yang, Zhang, Chen, Tang, Chen, Lin, Zhao, Wei and Wen, 2024a), all of these strands point to the tool and perception layer, at least as much as to the reasoning core, as the place where production-debugging agents currently fail.

9. Conclusion We asked what limits an LLM coding agent’s diagnosis of production database incidents: its reasoning or its access. Across eight incidents and twenty-two fix commits, the answer was mostly the latter. The agent’s diagnostic reasoning was largely sound: it formed plausible hypotheses, noticed its own contradictions, and retired wrong hypotheses through measurement. Yet every incident whose root cause depended on runtime concurrency began with a false start. The agent had the entire codebase, yet for these failures the code was not enough. In most of them, the evidence that would have settled the diagnosis existed but was out of reach: the live lock view, the full deadlock report, the row-level state, and the environment in which the failure appeared. Where the agent did reason badly, by anchoring early, missing a configuration value, or misreading rollback semantics, the error occurred alongside an access gap that delayed its correction. The reasoning × access matrix makes the pattern explicit: every concurrency-dependent incident Page 10 of 12

Access More Than Reasoning

had an access gap, and no incident was limited by reasoning alone. This finding changes where the next investment should go. For tool builders, the highest-leverage work is not a larger model but a forensics layer. It should be a read-only, audited interrogation surface, a recorder that preserves transient lock and deadlock state, and a way to reproduce production’s concurrent behavior. All of it must live inside the security controls that make production access hard to grant in the first place. For researchers who build benchmarks, the finding implies that agents should be evaluated under partial observability, and not only on how hard a fault is to explain. For practitioners, the finding is a caution: the agent amplified the leverage of an engineer who understood concurrency, but it did not replace the judgment needed to tell when a plausible hypothesis was wrong. In mission-critical systems, the first bottleneck of today’s debugging agents is access, and it is the one that tooling can remove. Future work. The most direct next step is to turn our observation into a controlled comparison, crossing model capability with access. Replaying the same incidents with and without a forensics layer, while holding the model fixed, would test whether access causes the false starts, a claim this study can only suggest. The comparison would also measure what each wrong hypothesis costs in deploy cycles and time to resolution. A second step is to build and evaluate the components we propose, including a lock-and-deadlock flight recorder for PostgreSQL and a read-only interrogation API brokered by the existing access layers. Third, our findings come from one system, one team, and a single coder; multisite replication across other database engines, workloads, and agents is needed, with independent coders and interrater agreement, to establish whether the “access more than reasoning” pattern generalizes and to refine the matrix into a validated taxonomy. Finally, we see room for benchmarks that vary the agent’s observability explicitly, for example by truncating logs or withholding lock views in testbeds such as AIOpsLab (Chen et al., 2025) or OpenRCA (Xu et al., 2025). Such benchmarks would let the community separate failures of reasoning from failures of access at scale, which our single field study could not do.

Data Availability The raw data (session transcripts, commit history, and production metrics) cannot be shared, because they contain the company’s proprietary information.

Declaration of Competing Interest The author was employed by the company under study during the period covered by the data and directed the agent as part of that employment. The author declares no other competing interests.

Gustavo Pinto: Preprint submitted to Elsevier

Declaration of Generative AI and AI-Assisted Technologies in the Manuscript Preparation Process During the preparation of this work the author used Claude Code (an AI coding agent) to support the analysis of the session transcripts and repository data and to assist with drafting the manuscript. Because the object of study is the same tool, its use is also discussed as a threat to validity in Section 7. After using this tool, the author reviewed and edited the content as needed and takes full responsibility for the content of the published article.

References Bouzenia, I., Pradel, M., 2025. Understanding software engineering agents: A study of thought-action-result trajectories, in: Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering (ASE), IEEE. pp. 2846–2857. doi:10.1109/ASE63991.2025.00234. Chen, Y., Shetty, M., Somashekar, G., Ma, M., Simmhan, Y., Mace, J., Bansal, C., Wang, R., Rajmohan, S., 2025. AIOpsLab: A holistic framework to evaluate AI agents for enabling autonomous clouds, in: Proceedings of the Eighth Conference on Machine Learning and Systems (MLSys). URL: https://proceedings.mlsys.org/paper_files/paper/2025/ hash/d1f9e4a9f109b6e8b75ed362736f22ec-Abstract-Conference.html. Chen, Y., Xie, H., Ma, M., Kang, Y., Gao, X., Shi, L., Cao, Y., Gao, X., Fan, H., Wen, M., Zeng, J., Ghosh, S., Zhang, X., Zhang, C., Lin, Q., Rajmohan, S., Zhang, D., Xu, T., 2024. Automatic root cause analysis via large language models for cloud incidents, in: Proceedings of the Nineteenth European Conference on Computer Systems (EuroSys), ACM. pp. 674–688. doi:10.1145/3627703.3629553. Jain, R., Purandare, R., 2026. Assessing large language models in verifying concurrent programs, in: Proceedings of the IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), IEEE. pp. 802–813. doi:10.1109/SANER67736.2026.00094. Jha, S., Arora, R.R., Watanabe, Y., Yanagawa, T., Chen, Y., Clark, J., Bhavya, B., Verma, M., Kumar, H., Kitahara, H., Zheutlin, N., Takano, S., Pathak, D., George, F., Wu, X., Turkkan, B.O., Vanloo, G., Nidd, M., Dai, T., Chatterjee, O., Gupta, P., Samanta, S., Aggarwal, P., Lee, R., Ahn, J.W., Kar, D., Paradkar, A., Deng, Y., Moogi, P., Mohapatra, P., Abe, N., Narayanaswami, C., Xu, T., Varshney, L.R., Mahindru, R., Sailer, A., Shwartz, L., Sow, D., Fuller, N.C.M., Puri, R., 2025. ITBench: Evaluating AI agents across diverse real-world IT automation tasks, in: Proceedings of the 42nd International Conference on Machine Learning (ICML), PMLR. pp. 27134–27197. URL: https://proceedings.mlr. press/v267/jha25a.html. Jimenez, C.E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., Narasimhan, K., 2024. SWE-bench: Can language models resolve real-world GitHub issues?, in: Proceedings of the Twelfth International Conference on Learning Representations (ICLR). URL: https://openreview.net/forum? id=VTF8yNQM66. Ko, A.J., 2017. A three-year participant observation of software startup software evolution, in: Proceedings of the 39th IEEE/ACM International Conference on Software Engineering: Software Engineering in Practice Track (ICSE-SEIP), IEEE. pp. 3–12. doi:10.1109/ICSE-SEIP.2017.29. Roy, D., Zhang, X., Bhave, R., Bansal, C., Las-Casas, P., Fonseca, R., Rajmohan, S., 2024. Exploring LLM-based agents for root cause analysis, in: Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering (FSE Companion), ACM. pp. 208–219. doi:10.1145/3663529.3663841. Singh, V., Vaidya, K.E., Bannihatti, V., Khosla, S., Narayanaswamy, B., Gangadharaiah, R., Kraska, T., 2024. Panda: Performance debugging for databases using LLM agents, in: Proceedings of the 14th Conference on Innovative Data Systems Research (CIDR). URL: https://www.cidrdb. org/cidr2024/papers/p6-singh.pdf.

Page 11 of 12

Access More Than Reasoning Wang, L., Ma, C., Feng, X., Zhang, Z., Yang, H., Zhang, J., Chen, Z., Tang, J., Chen, X., Lin, Y., Zhao, W.X., Wei, Z., Wen, J., 2024a. A survey on large language model based autonomous agents. Frontiers of Computer Science 18, 186345. doi:10.1007/s11704-024-40231-1. Wang, Z., Liu, Z., Zhang, Y., Zhong, A., Wang, J., Yin, F., Fan, L., Wu, L., Wen, Q., 2024b. RCAgent: Cloud root cause analysis by autonomous agents with tool-augmented large language models, in: Proceedings of the 33rd ACM International Conference on Information and Knowledge Management (CIKM), ACM. pp. 4966–4974. doi:10.1145/3627673. 3680016. Watanabe, M., Li, H., Kashiwa, Y., Reid, B., Iida, H., Hassan, A.E., 2026. On the use of agentic coding: An empirical study of pull requests on GitHub. ACM Transactions on Software Engineering and Methodology (TOSEM) 35, 1–24. doi:10.1145/3798166. Xia, C.S., Deng, Y., Dunn, S., Zhang, L., 2025. Demystifying LLM-based software engineering agents. Proceedings of the ACM on Software Engineering 2, 801–824. doi:10.1145/3715754. aCM International Conference on the Foundations of Software Engineering (FSE). Xu, J., Zhang, Q., Zhong, Z., He, S., Zhang, C., Lin, Q., Pei, D., He, P., Zhang, D., Zhang, Q., 2025. OpenRCA: Can large language models locate the root cause of software failures?, in: Proceedings of the Thirteenth International Conference on Learning Representations (ICLR). URL: https://openreview.net/forum?id=M4qNIzQYpd. Yang, J., Jimenez, C.E., Wettig, A., Lieret, K., Yao, S., Narasimhan, K., Press, O., 2024. SWE-agent: Agent-computer interfaces enable automated software engineering, in: Advances in Neural Information Processing Systems 37 (NeurIPS), pp. 50528–50652. doi:10.52202/ 079017-1601. Zhang, Z., Wang, C., Wang, Y., Shi, E., Ma, Y., Zhong, W., Chen, J., Mao, M., Zheng, Z., 2025. LLM hallucinations in practical code generation: Phenomena, mechanism, and mitigation. Proceedings of the ACM on Software Engineering 2, 481–503. doi:10.1145/3728894. aCM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). Zhou, X., Li, G., Sun, Z., Liu, Z., Chen, W., Wu, J., Liu, J., Feng, R., Zeng, G., 2024. D-Bot: Database diagnosis system using large language models. Proceedings of the VLDB Endowment (PVLDB) 17, 2514– 2527. doi:10.14778/3675034.3675043.

Gustavo Pinto: Preprint submitted to Elsevier

Page 12 of 12

Related documents

• Where LLM Agents Get Stuck Debugging Databases: Access More Than Reasoning#1661321
• Understanding Agent-Reactive Bugs at the Model-Harness Boundary: An Empirical Study of LLM Agent Issue Reports#381813
• Trace Integrity for LLM Data Agents: Auditing Structured-Data Computation Beyond Answer Accuracy in Real-World Systems#1455461
• Constraint Decay: The Fragility of LLM Agents in Backend Code Generation#1035486
• SWE-Shepherd: Advancing PRMs for Reinforcing Code Agents#10441