Digital twins of companies: how they are built

A digital twin of a company is a working simulation of a real organization: its people, its tools and its history, rebuilt so an AI agent can act inside it. Teams build these to train and test agents on work that looks like a real job rather than a puzzle. The quality of the twin depends almost entirely on the quality of the operational data underneath it.

A twin is not a chatbot that has read a company's documents. It is an environment. The agent can open a ticket, search the wiki, read a channel, send an email or review a pull request, and the environment responds the way the real tools would.

It is also not a perfect copy. A twin built from licensed data is anonymized, scoped and reconstructed from records rather than captured live. What it preserves is structure: who worked with whom, which tools held which parts of a project, and how work moved from one state to the next. For agent training and evaluation, structure is what matters most.

If the broader idea of an environment is new, what an RL environment actually is is a good primer. This post focuses on how the company version gets built, one layer at a time.

Everything starts with people and organizations, and with making sure each one is the same entity everywhere. In raw records, a single engineer might appear as a chat handle, two email addresses, a ticket-tracker username and a Git author name.

Anonymization handles the first part of this. Every person, company, address, email, phone number and account becomes a consistent token, so PERSON_014 is the same person in chat, email and tickets. The twin builder then uses those tokens to reconstruct the organization: teams, likely reporting lines inferred from who assigns work to whom, and the outside parties the company dealt with.

If the tokens were inconsistent across tools, this layer would fall apart. The agent would see a dozen strangers where there should be one colleague. That is why the same person must get the same token everywhere, and why it is a hard requirement rather than a nice-to-have.

Next, every event from every tool is placed on a single timeline. A message, a ticket status change, a commit, a document edit and an email reply each get a timestamp and links to the entities involved.

With a unified timeline, the builder can reconstruct the state of the company at any moment. What did the backlog look like on a given Tuesday? Which version of the spec was current? Who had replied to the customer, and who had not? This lets the twin present the company to an agent as it was at a specific point, without leaking what happened next.

This is also where cross-tool links pay off. A ticket that references a pull request, which references a chat thread, which references a customer email, gives the timeline a spine. Isolated exports produce a pile of events. Connected data produces a sequence an agent can step into.

The twin then exposes each source system as an interface the agent can call. Usually that means a simulated version of each tool: a chat service with channels and search, a ticket tracker with states and assignees, a code host with branches and reviews, a mailbox, a CRM.

Each simulated tool reads from and writes to the reconstructed state. When the agent posts a message or moves a ticket, the twin records it, and later observations reflect the change. Builders decide how much fidelity each tool needs. A twin aimed at engineering agents might model the code host in depth and keep email minimal, while one aimed at operations or finance agents might do the reverse.

The hard part here is the other people. Real colleagues reply, push back and go quiet. Some twins replay historical responses where the agent's actions match what happened, and use simulated colleagues, grounded in each token's past behavior, where they diverge.

A twin becomes useful once it has tasks. The richest source is the company's own history. A real ticket that a real team resolved becomes a task: here is the state of the company when the ticket was opened, now resolve it.

The historical outcome gives a reference for grading. Did the agent reach a result consistent with what the team actually shipped? Did it ask the right person, find the right document, avoid the dead end the team hit first? Grading can combine checks on final state with checks on process, and rewards from real outcomes tend to be harder to game than hand-written rubrics.

Long-horizon tasks, which span days or weeks and several tools, are the hardest to build and among the most valuable. They need the source data to cover the whole arc of a piece of work, from the first message to the final follow-up.

Working backward from those layers, a twin builder needs a few things from the data:

• Several systems from the same company, not fragments from many
• Consistent tokens across every tool and across years
• Enough history to show work starting, changing hands and finishing
• Enough headcount to show real handoffs and disagreements
• Removal of credentials, keys and sensitive folders, so the twin is safe to run
• A clear licence for training and evaluation use, with no right to re-identify anyone

That list is close to the opposite of what a large, shallow dataset offers. Imagine a 120-person logistics software company with five connected tools and six years of history. It can support a richer twin than a much larger pile of disconnected email, because every layer above has something to hold on to.

If your team is building company twins and needs a specific mix of sectors, sizes or tool stacks, send us a sourcing brief.