1 Introduction↩︎

Large Language Model (LLM)-based agents are increasingly deployed in production software systems, from enterprise tooling (e.g., ServiceNow, Salesforce, Notion) to MCP integrations across a wide range of consumer applications.² Many of these applications are relied upon by a wide range of organizations and end-users, underpinning core business operations across large segments of the economy. Agent unreliability and errors — such as accidental deletion or overwriting of data, misuse of tooling, or incorrect changes to critical records — could have substantial ripple effects, yet are difficult to identify and prevent in practice, particularly when agent writes are interleaved with the prior database state.

Evaluating agents in software contexts remains an underdeveloped area. Benchmarks are the most common means of assessing performance, but strong benchmark results do not guarantee strong performance in real systems or on real-world tasks [1]–[4]. Existing benchmarks tend to have low construct validity [5] for the environments in which software agents are deployed.

Some benchmarks have attempted to close this gap by situating agents in replicas of common applications [6]–[8] or in simulated domains with API access yao-dollar-t-dollar-bench2024?. While these partly address the construct validity gap, two main limitations remain: (a) replicas and simulations are time- and resource-expensive to produce, and can quickly drift from the live state of the application; and (b) evaluating performance on a specific software is still not necessarily predictive of performance in others — for example, one with different tooling, system prompts, and workflows. Since no single benchmark can predict agent performance for arbitrary applications, teams need complementary evaluation methods that work directly in their application environment, on representative workflows.

We propose Copy-on-Write (CoW) Scoring, a framework to develop and safely conduct use-case-specific agent evaluations in software applications. The CoW mechanism allows agents to operate directly within the application environment, avoiding the cost and drift of replicas while keeping sessions isolated and setup easy to reuse across runs. This work assumes a PostgreSQL database, although the CoW pattern could similarly be extended to other data stores, which would enable scoring a broader range of agent operations. The scoring framework provides session- and operation-level scores that surface where agent writes succeed and fail when interacting with a given tool surface.

We demonstrate an evaluation loop on Plane,³ an open-source project-management platform, where scoring surfaces multiple failure modes specific to the deployed agents and tool surface, and a corresponding fix produces measurable improvement on the affected models. The same score-diagnose-fix procedure applies to any application using CoW Scoring, enabling low-cost iteration on the model, prompt, retrieval, or system prompt in a given deployment.

2 Copy-on-Write (CoW) Scoring↩︎

This section describes the CoW mechanism, which isolates agent database changes, and the CoW Scoring framework, which compares a ground-truth (GT) execution of a given workflow with a corresponding agent execution at the session and operation level. Both components are implemented in the open-source agent-cow library.

2.1 CoW Mechanism↩︎

Copy-on-Write (CoW) is a resource-management technique that lets processes share underlying data without creating copies upfront. Rather, reads go to the shared data and writes trigger creation of a copy such that only the writing process observes the change [9]. Applied to agent operations on databases, CoW prevents agents from writing directly to the underlying production data.

To enable CoW on a database, each original table is split into a base table (contains the underlying production data), changes table (contains agent writes), and corresponding view (defined by a query merging base and changes table data). All application operations are sent to the view, since it takes the name of the original table. View triggers redirect CoW write operations to the changes table, with associated CoW metadata columns (session_id, operation_id, _cow_updated_at, _cow_deleted) appended. Actions from a given session can then be queried using the respective session_id. The components are visualized in Figure 1, and more details are described in Appendix 7.

The agent-cow library handles database setup — creating base tables, changes tables, views, and deploying triggers (Algorithm 3, Appendix 7), and the application is responsible for passing session_id and operation_id with each agent operation. For Plane, CoW integration required \(\sim\)​250 lines of code for CoW functionality, and an additional \(\sim\)​540 lines specific to our recording infrastructure and portable to a testing harness (Appendix 9.1). We have separately integrated CoW Scoring into a closed-source production application, with comparable effort.

2.2 Scoring↩︎

Scoring takes two CoW sessions as input: a ground-truth (GT) session and an agent session. The GT session is recorded by a human performing the ideal sequence of actions for a given workflow with CoW enabled. The human also writes a prompt describing the workflow such that they would expect an agent to be able to reproduce their actions. The agent is then given this prompt and executes its own sequence of actions with CoW enabled.

CoW Scoring happens along two dimensions and at two levels of granularity. The two dimensions are structural (which tables, rows, columns, and relationships were written) and content (what values were written). The two levels of granularity are session-level (evaluates the session as a whole) and operation-level (evaluates each operation). Users can supply their own comparators and overall scoring functions; Appendix 8.1 describes the library architecture.

2.2.1 Session-level comparison↩︎

For session-level scoring, we keep the most recent written row state for each primary key. Changed rows are classified as: matched (\(N_\mathrm{matched}\) — rows present in both GT and agent sessions, under UUID mapping), missing (\(N_\mathrm{missing}\) — GT rows the agent never produced), or extra (\(N_\mathrm{extra}\) — agent rows with no GT counterpart).

2.2.1.1 Session-level structural score, \(s^{\mathrm{struct}}\):

The fraction of matched rows relative to the total number of rows changed. \[s^{\mathrm{struct}} = \frac{N_\mathrm{matched}}{N_\mathrm{matched} + N_\mathrm{missing} + N_\mathrm{extra}}\]

2.2.1.2 Session-level content score, \(s^{\mathrm{content}}\):

The mean per-field similarity over all matched rows. \[s^{\mathrm{content}} = \frac{1}{N_\mathrm{matched}} \sum_{(g, a) \in \text{matched}} \mathrm{sim}(g, a)\] where \(\mathrm{sim}(g, a) \in [0, 1]\) is the similarity calculation per row between \(g\) (GT) and \(a\) (agent). Each column has a default similarity comparator according to its data type, but custom comparators can be provided as described in Appendix 8.1.1.

Notably, CoW Scoring compares final database states rather than action sequences, so the session-level scores are invariant to the path the agent took.

2.2.2 Operation-level comparison↩︎

While the session-level scores evaluate whether the agent reached the desired GT world state, the operation-level scores quantify how useful each operation was in getting there. We first sort operations in topological order, then calculate the following for each operation.

2.2.2.1 Op-level structural utility, \(u^{\mathrm{struct}}(o_i)\):

The change in the session-level structural score before and after \(o_i\) is applied.

\[u^{\mathrm{struct}}(o_i) = s^{\mathrm{struct}}(G_{\leq i}) - s^{\mathrm{struct}}(G_{< i})\]

Where \(G_{< i}\) denotes the world state prior to applying \(o_i\), and \(G_{\leq i}\) denotes the state after \(o_i\) is applied.

2.2.2.2 Op-level content utility \(u^{\mathrm{content}}(o_i)\):

The mean per-field content similarity over operation rows.

\[u^{\mathrm{content}}(o_i) = \frac{1}{|M_i|} \sum_{(g, a) \in M_i} \mathrm{sim}(g, a)\] where \(M_i\) is the subset of matched rows whose agent-session write originated in \(o_i\).

3 Methods↩︎

Because the framework targets application-specific evaluation rather than a universal benchmark, our empirical validation will not compare against an external ground truth. The preliminary study below aims to show that (a) the CoW mechanism and scoring framework can be implemented in a PostgreSQL application, and (b) resulting scores surface useful information about agent behaviour, which can inform improvements to the tool surface in subsequent iterations.

3.1 Preliminary Study: Application in Plane↩︎

We apply CoW Scoring to Plane, an open-source project-management platform, as a concrete demonstration of the evaluation workflow. To produce a diverse set of ground-truth (GT) sessions without spending excessive author effort, Claude Opus 4.6 with access to the Plane codebase was prompted to execute realistic workflows against the seeded data, and each workflow manually reviewed and validated by the authors (details in Appendix 9). We developed a testing harness, which embeds Plane’s OpenAPI specification into a vector store, and exposes them to the agent through two tools: a discover tool for querying relevant endpoints, and an execute tool for making the corresponding requests.

Since CoW sessions are isolated, each GT and agent session started with the same application state. For each GT session, an agent was given the associated prompt and access to the Plane API via the harness execute and discover tools, with a 50-operation limit per session. Five language models were evaluated twice per prompt: GPT-5, GPT-4.1, Gemini-3.1-Pro, Gemini-3.1-Flash-Lite, and Gemini-2.5-Pro. In total, \(5 \times 2 \times 20 = 200\) agent sessions were scored against their corresponding GT sessions using CoW Scoring. A third trial per model was run after updating the tool surface (Section 4.3), for a total of 300 sessions.

4 Preliminary Results↩︎

4.1 Initial scores across models↩︎

Figure 2 shows CoW scores along each dimension, averaged between the two runs per (model, workflow) pair, with per-model summaries in Appendix 10 (Tables 5 and 6). These are early results from a single application and 20 workflows, with two trials per (model, workflow) pair, so broader claims would benefit from more samples.

Two initial observations serve as a sanity check on the scoring functions: within each model family, the ordering matches public benchmarks (Gemini-3.1-Pro \(>\) Gemini-3.1-Flash-Lite, GPT-5 \(>\) GPT-4.1), and per-model overall scores differ by at most 0.03 between trials, suggesting the means are representative rather than single-run artefacts.

4.2 Diagnosing failure modes↩︎

4.2.0.1 Vocabulary mismatch.

Plane uses “work item” to describe tasks within projects, while the session prompts use the term “issue”, which is also commonly used to describe these items (the database tables still use “issues”, suggesting an artefact of a previous naming convention), so an agent that searched for “issue” would not immediately find relevant operations. Gemini-2.5-Pro repeatedly gave up rather than rephrasing or reading endpoint descriptions closely enough to recognise the equivalence (Appendix 11, Figure 7). GPT-4.1 executed several discover calls before finding search_work_items. It executed one search using an incorrect search string, then wrongly concluded no relevant issues existed when several did (Appendix 11, Figure [fig:gpt-4951-security-incident-search]). It took Gemini-3.1-Flash-Lite fifteen discover calls to find the correct operation, causing it to ultimately exceed the 50-operation session limit (Appendix 11, Figure 8).

Importantly, this vocabulary mismatch challenge is well-known in information-retrieval [10] and not specific to Plane: any application is likely to have multiple terms in circulation for the same concept.

4.2.0.2 Hallucination and extra writes.

GPT-4.1 occasionally hallucinated incorrect parameters and operation names, by guessing operations before first calling the discover tool to ensure accuracy (Appendix 11, Figures [fig:gpt-4951-assign-backlog-by-specialty], 9, [fig:gpt-4951-in-progress-ownership-audit]). In these sessions, the hallucinations were benign: the invalid operations failed and left application state unchanged, but the same failure mode could be damaging if the agent invoked a valid operation with an incorrect name or parameters, leading to unintended side effects. Gemini-3.1-Flash-Lite hallucinated extra writes, producing label and assignee updates outside the scope of the prompted task (e.g., 47 extra rows in Campaign Push, 44 in Q3 Feature Prep). This is especially easy to miss outside a CoW session: an agent can satisfy the prompt while modifying unrelated application state in incorrect or harmful ways.

4.3 Improving the tool surface↩︎

We updated the tool surface to address the findings, in particular to ensure “issues” was also used to describe operations related to “work items”. We ran one additional trial per model; score deltas are reported in Table 1. Models most affected by the vocabulary mismatch saw the largest gains: Gemini-2.5-Pro improved by 54%, and GPT-4.1 by 47%. While Gemini-3.1-Flash-Lite improved by just 3%, it had no failed sessions in run 3 compared to at least one per iteration previously.

This loop — CoW Scoring, localising the points of failure, and iterating or flagging known weak areas to users — can be applied to analyze any tool surface using CoW Scoring.

5 Limitations↩︎

5.0.0.1 GT sessions are created manually.

This step takes time, but we believe the effort is comparable to building any application-specific dataset — some investment is needed to address the construct-validity gap that motivates this work.

5.0.0.2 Evaluation assumes prompts that fully specify the intended outcome.

Real users often send underspecified prompts where multiple final states are reasonable, which CoW Scoring would conflate with failure — custom comparators, vocabulary variation, and analyzing structural and content scores separately could partially mitigate this.

5.0.0.3 Scoring covers only write operations.

Agents also issue reads, and the volume and pattern of those reads carries diagnostic signal — failing models in our runs often issued many redundant discover calls without affecting structural or content scores, but these calls in fact surfaced the work-item/issue mismatch. Incorporating read-operation signals could help diagnose these failure modes directly.

6 Future Work↩︎

6.0.0.1 Input to optimization loops.

The low computational cost of CoW Scoring suggests it could also serve as a signal in optimization loops — for example, to iteratively improve tool interfaces via GEPA [11], or as a dense reward for model fine-tuning via GRPO-style approaches [12]. Operation-level scores are particularly well-suited to this: they assign credit to partial progress towards the final world state, so optimization need not depend on the discovery of complete, successful trajectories.

6.0.0.2 Automated GT generation and coverage.

GT sessions are manually generated, which is inherently limited in scale and may not give uniform coverage of the API surface. Automated discovery methods — e.g.MCTS-style [13], [14] exploration with LLM-guided candidate selection — could generate candidate sessions, with human review reserved for auditing.

Impact Statement↩︎

CoW Scoring aims to support safer agent deployments by making evaluations possible directly in application environments. The framework risks giving false confidence if GT sessions are unrepresentative of real usage: strong performance on a narrow set of evaluated workflows does not guarantee correct behaviour on others. Though not the focus of this paper, the CoW mechanism can also be used as a general runtime safeguard against unintended agent writes.

7 Copy-on-Write (CoW) Mechanism↩︎

This appendix expands on the CoW mechanism summarised in Section 2.1, detailing the four database-level components that together intercept and isolate agent writes without modifying production data:

1. Base tables: These tables contain the underlying (base) production data, and follow the schema definitions specified in the application.

2. Changes tables: Each base table has a corresponding changes table. Changes tables are structurally identical to base tables (with four additional columns: session_id, operation_id, _cow_updated_at, _cow_deleted) but only contain rows that were written to during the agent session.

3. Views [15]: A SQL view is a query stored under a name. A view can be queried in the same way as a table, although no physical table exists — querying a view instead executes the underlying query (the view definition) and returns its results, so it can be read from like a table. In the CoW mechanism, views are used to merge each base table with its corresponding changes table, so that reads during an agent session return rows from the base table, with any rows that the agent has modified in the current session replaced by their changes-table versions.

4. Triggers [15]: INSTEAD OF triggers can be defined on views, and define how a given operation (in this case, a database write) should be carried out. For CoW, writes should be forwarded to the changes table.

   1. Create copies of the affected row(s);

   2. Apply the write to the row(s);

   3. Append the session_id, operation_id, _cow_updated_at (the current time), and _cow_deleted (True if the write is a DELETE operation);

   4. Write the row(s) to the corresponding changes table.

   Notably, the handling of complex trigger configurations such as cascade triggers and PostgreSQL-specific triggers should be explored in future work to extend the real-world portability of the CoW mechanism.

Enabling CoW on a database creates each of these components, and deploys the necessary trigger functions – following Algorithm 3 below.

8 CoW Scoring↩︎

Figure 4 provides a worked example of the scoring procedure described in Section 2.2, illustrating how the session- and operation-level scores are computed from a paired GT and agent session. On the left, rows are colour-coded as matched, missing, and extra – which is used to compute \(s^{\mathrm{struct}}\) and \(s^{\mathrm{content}}\). On the right, each agent operation \(o_i\) is attributed a structural utility \(u^{\mathrm{struct}}(o_i)\) from the change in session-level structural score, and a content utility \(u^{\mathrm{content}}(o_i)\) from the similarity of the rows it wrote.

8.1 agent-cow Scoring Library↩︎

The agent-cow scoring module (visualized in Figure 5) scores an agent’s CoW session against a ground-truth recording via the API entry point score_cow_sessions. The pipeline has five stages:

1. Extraction (extraction.py) — rows are read from *_changes tables, grouped by operation_id, and sorted by _cow_updated_at.

2. Matching (matching.py) — both sides are reduced to one row per (table, pk) (last write wins). Each ground-truth entity greedily picks the best matching agent entity in the same table; a UUID mapping bridges the different primary keys created by each side.

3. Field comparison (compare.py) — each field is compared by SQL type: text uses SequenceMatcher.ratio(), JSON is deep-equal, everything else is exact. PKs, FKs (remapped via the UUID mapping), timestamps, and configured ignored_fields are excluded from content scoring.

4. Per-op scoring (scorer.py) — for each agent operation in topological order the cumulative agent rows are re-scored against ground truth, recording the delta in op_struct_scores. op_content_scores is computed independently from the final matching.

5. Reduce (scores.py) — registered score_fns reduce the ScoringResult to scalar entries on result.scores.

8.1.1 Scoring Customization↩︎

8.1.1.1 Comparators.

The default content similarity uses one comparator per SQL column data type. To override comparison for a specific table, callers can supply either a row-level function — which receives the GT and agent rows as plain dicts (with FK UUIDs already remapped into GT space), returns a bool or float in \([0, 1]\) — or a WriteComparator, which additionally exposes the row’s CoW metadata, the table’s column-type metadata, and the cross-session UUID mapping for full control. Additionally, passing collapse=True drops entities the agent created and later deleted within the session before scoring, reflecting only the agent’s net intent.

8.1.1.2 Score functions.

Any callable mapping the raw scoring terms to a float can be registered as an overall score. The agent-cow library includes sample scoring functions, each mapping a ScoringResult to a single float, which can be passed via the score_fns kwarg, and their outputs are written to result.scores under the names below.

8.1.1.3 Default overall score.

An average of the two session-level signals: \[s^{\mathrm{overall}} = 0.5 \cdot s^{\mathrm{struct}} + 0.5 \cdot s^{\mathrm{content}}\]

8.1.1.4 Precision.

Of the rows the agent wrote, the fraction that matched a GT entity: \[\mathrm{precision} = \frac{N_{\mathrm{matched}}}{N_{\mathrm{matched}} + N_{\mathrm{extra}}}\]

8.1.1.5 Recall.

Of the rows GT session wrote, the fraction the agent reproduced: \[\mathrm{recall} = \frac{N_{\mathrm{matched}}}{N_{\mathrm{matched}} + N_{\mathrm{missing}}}\]

8.1.1.6 F1.

Harmonic mean of precision and recall: \[F_1 = \frac{2 \cdot \mathrm{precision} \cdot \mathrm{recall}}{\mathrm{precision} + \mathrm{recall}}\]

9 Plane Integration and Experimental Setup↩︎

9.1 CoW Integration in Plane↩︎

The full implementation of CoW into Plane can be found in the following GitHub repository: Plane (with CoW), which also includes the raw scoring results (results.zip).

The breakdown of application-side additions is shown in Table 2. The far-right column indicates whether that portion of code could be ported to the harness if the user wanted to simplify their implementation. Notably, the recording API and CoW scoring metadata (session IDs, scores, API versions, prompts) were included in the Plane application for this experiment, but could be stored in the harness for a simpler, less-invasive implementation. Only the CoW mechanism (using the agent-cow-python library) and associated deployment commands are necessary.

9.2 Workspace Initial Data Seeding↩︎

The Plane workspace was seeded with the entities summarised in Table 3 prior to any agent runs. Ground-truth CoW recordings were then captured against this fixed initial state.

9.3 Ground-Truth Session Setup↩︎

To produce a realistic and diverse set of ground-truth (GT) workflows without spending excessive author effort, an LLM agent (Claude Opus 4.6) under human supervision was used. The agent was given read access to the plane-cow codebase — including the Plane data model, the seeded workspace dump (Appendix 9.2), and the CoW recording API — so it could ground its workflows in the actual entities present in the codebase and database.

We provided the agent with short workflow themes (e.g.sprint kickoff, security incident response, stale backlog cleanup) drawn from the kinds of bulk operations someone might be expected to perform in a project management tool. The agent then started a CoW recording, and executed the corresponding sequence of API writes against the seeded workspace, and drafted a natural-language prompt expressing the workflow.

Each candidate session was then reviewed. We checked that (i) the prompt was unambiguous and self-contained, (ii) every recorded operation was justified by the prompt, (iii) no operation was missing relative to a literal reading of the prompt.

In a real application, the product team would likely have some key workflows they would be interested in having the agent execute and perform well on, which would then be recorded manually.

10 Results Summary↩︎

This appendix collects per-model summaries from the preliminary study (Section 4). The raw scoring data for all 300 sessions is available at results.zip. Table 5 reports the overall score \(s^{\mathrm{overall}}\) (Appendix 8.1.1) for each model averaged across the first two trials, alongside per-trial scores and row-level precision, recall, and F1 derived from the matched/missing/extra counts. Table 6 lists the five lowest-scoring (model, workflow) pairs per model; these are the sessions inspected in Section 4 to surface the failure modes discussed in the main text and illustrated in Appendix 11.

11 Sample Sessions↩︎

This appendix contains tool-call traces from representative low-scoring sessions identified in Table 6, which illustrate the failure modes discussed in Section 4: vocabulary mismatch between prompt terminology and the API surface (Figures 7, [fig:gpt-4951-security-incident-search], and 8), and operations issued without a prior discover call to obtain the correct argument format (Figures [fig:gpt-4951-assign-backlog-by-specialty],  9 and [fig:gpt-4951-in-progress-ownership-audit]). Despite the overall improvement from runs 1 and 2 to run 3, two model-specific failure modes persisted across iterations:

• GPT-4.1: Occasionally executes an operation without first calling discover to obtain the correct argument format, producing API errors (Appendix 11, Figures [fig:gpt-4951-assign-backlog-by-specialty] and [fig:gpt-4951-in-progress-ownership-audit]) and one failed session in run 3.

• Gemini-3.1-Flash-Lite: Continued to write extra rows. For example, in the sessions: Sprint Kickoff (8 extra work items and assignees), Deprioritize Stale Medium Backlog (5 extra labels), and Infra Sprint Kickoff (18 extra labels and assignees), none of which were prompted.

References↩︎