The Copy Button Is Missing

We gave computers language and somehow forgot to give the language model a copy button.

That sounds like a joke about artificial intelligence, but it reveals something uncomfortable about the products we are building. A computer can copy a file containing several billion characters without needing to understand any of them. A language model can explain advanced mathematics, write functional software and interpret a complicated contract, yet still quietly change one digit while transferring a number from one place to another.

A recent paper, *Frontier Language Models Struggle to Copy*, tests this directly. The researchers asked leading models to reproduce strings exactly and to convert sequences of sensor readings into Python lists. The tasks were deliberately simple. No reasoning was required. The input fitted comfortably inside the models' context windows. Still, accuracy deteriorated as the strings became longer, especially when they contained repeated patterns.

The model was not confused about the instruction. It understood that it had been asked to copy.

It just did not copy in the way a computer copies.

Copying as performance

When I select a line of text and press Command-C, the computer does not read the line, remember its meaning and generate an equivalent line. It preserves a sequence of values.

An LLM usually does something closer to reconstruction. The original information enters the model as context. The model then predicts the tokens that should appear in the answer. Even when the answer is supposed to be identical to the input, it is still being generated.

This means the apparent copy operation is actually a performance of copying.

Most of the time, the performance looks convincing. A sentence remains a sentence. A familiar name remains recognizable. A list of numbers still looks like a list of numbers. The failure can be almost invisible because the output retains the shape of the original.

That is exactly what makes it dangerous.

A typo in an AI-written paragraph may be embarrassing. A typo in an account number, API parameter, medication dose, legal clause or database identifier belongs to a different category of failure. The output does not merely become worse. It may begin referring to something else.

The unsettling part is not that an advanced model cannot always copy. The unsettling part is how easily a system can conceal the fact that copying never happened.

The wrong machine for the operation

The paper offers a technical explanation involving positional encoding. The researchers argue that standard Transformer architectures may learn to copy by looking for a previous local pattern resembling the current output and then continuing from there. Repeated patterns create several plausible matches, allowing the model to jump to the wrong occurrence.

Their proposed alternative, 2D-RoPE, gives tokens row and column positions so that an output token can retrieve the input token from the corresponding column rather than rediscovering it through textual similarity.

In one of the paper's larger experiments, a standard RoPE model fell from 21.6 percent exact-copy accuracy at a sequence length of 1K to zero at 4K and 8K. The comparable 2D-RoPE model remained at 100 percent at 1K, 92.6 percent at 4K and 87.3 percent at 8K.

The architectural proposal is interesting. The product lesson may be even more immediate.

We keep asking a probabilistic machine to perform deterministic operations, then adding increasingly emotional instructions when it fails.

Copy this exactly.

Do not change anything.

Preserve every character.

Double-check your answer.

These instructions feel precise to a human, but they do not alter the nature of the operation. We are still asking the model to generate the value again. We are just expressing our anxiety more forcefully inside the prompt.

This is not prompt engineering. It is using the wrong machine.

The agent is not one thing

AI products are often presented as if the agent were a single coherent worker. It reads, understands, decides, remembers, calculates, copies, submits and verifies. The chat interface encourages this impression because every operation appears through the same conversational surface.

But the system underneath should not be one undifferentiated intelligence.

It should contain at least two kinds of machinery.

One machine interprets ambiguity. It reads a messy request, infers intent, compares possibilities and proposes an action. Its uncertainty is useful because the world is uncertain.

The other machine preserves exactness. It retrieves records, moves values, performs calculations, checks constraints and verifies that nothing changed. Its lack of imagination is useful because the operation should not be creative.

The mistake is not allowing a probabilistic model into the system. The mistake is allowing probability to leak into operations that already have exact solutions.

An agent may need to decide which account number belongs in a form. That can require interpretation. Once the correct number has been selected, however, the model should not retype it. The value should travel through the system as data.

The model can choose the object.

The system should move the object.

Your agent is retyping the database

A surprising amount of current agent design works like giving an employee a database record on one screen and asking them to manually type it into another.

Except the employee has no fingers, sees everything as tokens and is rewarded for producing plausible continuations.

This architecture appears everywhere. A document is converted into text. The text is placed inside a prompt. The model is asked to extract several fields. It responds with new text. That text is parsed back into structured data and sent into another system.

At each stage, information moves from structure into language and then gets reconstructed as structure again.

Sometimes that conversion is necessary. A model is useful precisely because it can interpret information that was never structured properly. But once a value has been located, we should stop making the model reproduce it.

A trustworthy system would preserve a reference to the source span, the original bytes or the database field. It would distinguish between a value that the model inferred and a value that the system transferred unchanged.

Right now, most interfaces flatten both into the same answer.

The user sees:

Account number: 123456789

But the interface does not explain whether the number was copied directly from a verified field, extracted from an image, reconstructed by a language model or inferred from nearby text. These routes can produce identical-looking output while carrying radically different levels of confidence.

This is a provenance problem disguised as a text field.

Verified copy

Browsers taught us to look for a lock icon. The icon did not prove that a website was honest, but it represented a specific technical property of the connection. It gave an invisible system state a visible interface.

AI products may need a similar language for data integrity.

Imagine an agent filling out a payment form. Some fields have been inferred from an email. Some have been selected from saved records. Some have been calculated. Some have been transferred directly from an authenticated source.

Those distinctions should not disappear into one confident-looking form.

A field could carry a visible state:

Source-linked means the value remains connected to its origin.

Transferred exactly means the system moved the value without model regeneration.

AI-extracted means the model interpreted unstructured material.

AI-inferred means the value was not explicitly present and requires confirmation.

Validated means a deterministic rule checked its format or relationship to another field.

The interface would not merely display an answer. It would display how the answer came into existence.

This is what trust engineering looks like at the level of a copy operation. Not another disclaimer under the chat box. Not a vague warning that AI can make mistakes. A specific boundary between generation and preservation.

Generation should leave fingerprints

We currently make generated information look too much like retrieved information.

A search result, database value, mathematical output and model inference can all arrive as the same black text in the same white rectangle. Once rendered, their histories disappear.

That creates a strange asymmetry. The system knows whether it called a database, ran a calculation or asked the model to predict an answer. The user usually does not.

Perhaps generated information should leave fingerprints.

Not because generation is inherently untrustworthy, but because its trust conditions are different. A drafted email can be reviewed semantically. A copied identifier requires character-level identity. A diagnosis may require clinical evidence. A price may require freshness. A calculation requires reproducibility.

"Accurate" is not one property.

It depends on the operation.

The copy test exposes this clearly because copying has an unusually strict definition. The output is either identical or it is not. There is no partial credit for preserving the overall vibe of a bank account number.

The harness around the model

This connects to a larger problem I keep returning to: the prompt is not the product.

A prompt can tell the model to be careful, but it cannot supply the guarantees that the surrounding system refuses to implement. Reliability has to come from the harness around the model: structured references, typed tools, validation rules, source tracking, comparison checks, permission boundaries and recovery paths.

If an agent is asked to update a configuration file, the system can compare the untouched fields before and after the edit.

If it moves financial details, the interface can display the original and destination values side by side.

If it extracts a contractual clause, the answer can remain linked to the exact source passage.

If it submits a form, the system can validate identifiers rather than trusting that they look identifier-shaped.

The model still matters. It may be the component capable of understanding what the user is trying to accomplish. But intelligence does not remove the need for ordinary software. It makes the separation of responsibilities more important.

The probabilistic system proposes.

The deterministic system preserves, tests and commits.

We replaced certainty with theatre

The history of computing has largely been a history of making exact operations cheap. Copying, calculating, sorting, comparing and storing became reliable primitives. We did not have to negotiate with the computer about whether it felt confident enough to preserve a string.

The agent boom is quietly reversing this.

Operations that were once deterministic are being translated into language, performed probabilistically and translated back into data. The resulting interface may feel more natural, but the underlying guarantees become weaker.

We replaced certainty with a performance of certainty.

This does not mean LLMs should be removed from consequential systems. It means they should be placed where interpretation is actually required. The model should handle ambiguity without being allowed to contaminate exactness.

A trustworthy agent does not need to be deterministic everywhere. That would remove much of what makes it useful.

It needs to know where determinism begins.

The model can read the database.

It can reason about the database.

It can decide what should change in the database.

But please stop letting it retype the database.

Connected reading

• The Product Needs a Harness
• The Most Dangerous Interface Is the One That Says Everything Worked
• The Interface Is Now Part of the Answer
• The Prototype Has Become Too Cheap to Trust
• The Data Warehouse Is Becoming an Operator

AI authorship note

This essay began with Kris Haamer reading *Frontier Language Models Struggle to Copy*, asking for the Raw Drafts angle and choosing the argument that AI reliability fails when probabilistic generation is used for deterministic data movement. AI supported the paper summary, drafting, editing, metadata and publishing workflow. Kris selected the title, the trust-engineering framing and the final publication decision.