The suggestion appeared in the Agate assessment log on a Monday morning. Not from a human. From an agent.
Agent agate-assess-01, during its routine convergence evaluation, had flagged a pattern across twelve scenarios: recurring failures at the boundary where the factory's internal services interacted with the external DNS infrastructure. The agent's assessment was precise. The scenarios assumed DNS resolution would behave as documented. In practice, DNS behaved as DNS behaved, which was to say: unpredictably, intermittently, and with a creative disregard for specifications that would be funny if it weren't load-bearing.
The assessment concluded with a recommendation: A DNS twin would allow scenario validation against realistic resolution behavior, including propagation delays, TTL edge cases, and NXDOMAIN responses for recently deleted records.
Justin read the assessment twice. Then he called Jay and Navan over.
"The agents want a seventh twin," he said.
The Digital Twin Universe had six members: Okta, Jira, Slack, Google Docs, Google Drive, Google Sheets. Each one was a behavioral clone of a real service, painstakingly modeled to replicate the service's actual behavior, including its quirks and failures and undocumented edge cases. Adding a new twin was not trivial. It required traffic captures, behavioral modeling, validation against the real service, and integration into the scenario suite.
"DNS," Jay said, reading the assessment. He laughed. Not a mocking laugh. An appreciative one. "Of course it's DNS. It's always DNS."
"I didn't expect the agents to suggest it," Navan said. "I expected us to decide what twins we needed."
"We decided the goals," Justin said. "The agents are working toward the goals. They identified a gap in the testing infrastructure that's blocking convergence. The suggestion is logical." He paused. "It's also right. We've been papering over DNS flakiness with retry logic and generous timeouts. A twin would let us model it properly."
They built the DNS twin in a week. Not from scratch—the agents built it, guided by scenarios that Navan wrote describing the DNS behaviors they needed to model. Propagation delays. TTL boundaries. The peculiar way that some resolvers cache NXDOMAIN responses longer than they should. The race condition between a record being created and the first successful resolution.
The DNS twin was different from the other six. It was smaller, simpler, less a clone of a specific service and more a model of a protocol. But it filled the gap the agents had identified, and the twelve scenarios that had been failing at the DNS boundary started passing within days.
"Seven twins," Navan said, updating his notebook's running catalog. "Okta, Jira, Slack, Google Docs, Google Drive, Google Sheets, DNS." He drew a line under the list and added a note: First twin suggested by agents, not humans.
Jay looked at the assessment log again. "If the agents can identify what tools they need," he said slowly, "then the factory isn't just building software. It's building itself."
Justin didn't disagree. He was already thinking about what the agents would suggest next.
"It's always DNS." The most universal truth in computing, and of course it's the agents who finally say it out loud. The detail about NXDOMAIN caching is painfully accurate. Whoever wrote this has debugged DNS at 2 AM.