Two agents edited the same document at the same time. This was the scenario that kept Navan up thinking about operational transformation at unreasonable hours.
Agent A inserted a paragraph at position 47. Agent B deleted a word at position 12. Both operations were valid independently. But when they arrived at the twin in rapid succession, the twin had to resolve them into a consistent document state. If it applied A's insert first, B's delete position was still correct. If it applied B's delete first, A's insert position shifted by the length of the deleted word. The twin had to get this right every time, regardless of arrival order.
"Operational transformation," Justin said when Navan described the problem. They were standing in the kitchen. Justin was making tea. "Google solved this twenty years ago for Docs. You're rebuilding their solution."
"Not exactly rebuilding. Approximating. We don't have access to Google's actual OT implementation. We only know the observable behavior. Two users type simultaneously, the document converges. We built our twin to produce the same convergent result."
"How do you verify convergence?"
Navan had thought about this. "We run the scenario a hundred times with randomized operation ordering. If all hundred runs produce the same final document state, we consider the twin convergent for that scenario. It's not a mathematical proof. It's a probabilistic assertion."
Justin poured the tea. "Satisfaction metrics. Probabilistic validation. You're using the factory's own methodology to validate the twin."
"The twin IS part of the factory. It has to follow the same rules."
The harder problem, Navan explained, was cursor tracking. When Agent A inserted text, Agent B's cursor position had to adjust. In real Google Docs, you could see other users' cursors moving in real time, adjusting as the document changed around them. The twin didn't render cursors visually—agents didn't have screens—but it tracked cursor positions via the API because some operations depended on knowing where each collaborator was in the document.
"Suggestions mode was another layer entirely," Navan continued. "An agent could propose an edit without committing it. The twin had to maintain both the actual document and a shadow document containing the suggestions. Accept a suggestion: the shadow merges into the actual. Reject it: the shadow drops that change. But if two agents are both making suggestions while a third agent is editing the actual document directly, the twin is maintaining three separate operational transformation streams."
Jay had joined them in the kitchen by now, drawn by the sound of someone explaining concurrency problems. "What happens if an agent tries to accept a suggestion that conflicts with a direct edit?"
"The twin resolves it the same way real Docs does. The suggestion gets modified to fit the current document state. If the suggestion was to delete a word that no longer exists, the accept operation becomes a no-op." Navan took a sip of tea he had not remembered pouring. "The Docs twin isn't a text editor. It's a conflict resolution engine that happens to store text."
Justin raised his mug. "Welcome to distributed systems."
Navan did not point out that Jay was the distributed systems enthusiast. He just drank his tea and thought about cursors.
Three simultaneous OT streams for suggestions + direct edits is genuinely nightmarish. The fact they're approximating this through behavioral capture rather than reimplementing Google's internals is fascinating.