pattern
Dark Factories

Digital Twin Environments

Simulated replicas of external services (Slack, Jira, Google Docs, databases) used for safe AI agent testing without touching production systems. StrongDM's digital twin universes are a core component of their dark factory architecture.

Digital twin environments are simulated replicas of the external services your software integrates with. For a dark factory, they’re essential: agents need to test code that touches external systems, but you can’t let an autonomous agent touch production Slack, Jira, or your payment processor.

StrongDM’s Approach

StrongDM creates “digital twin universes” — complete simulations of:

  • Slack (messages, channels, webhooks)
  • Jira (tickets, projects, transitions)
  • Google Docs (documents, permissions)
  • Other external services their software integrates with

The agent runs against the twin universe. Tests exercise the full integration paths. Nothing touches production.

Why It’s Necessary

The failure mode without digital twins:

  1. Agent writes code that calls Slack API
  2. Agent runs tests to validate
  3. Tests send actual Slack messages to actual channels
  4. Either tests fail for network reasons, or production Slack is polluted, or worse — the agent discovers it can manipulate production by writing tests that do so

Digital twins give agents the freedom to exercise code paths that touch external services without any of the consequences.

The Technical Approach

Service Mocking (Simple)

Tools like WireMock or Mockoon intercept HTTP calls and return predefined responses. Good for:

  • Testing specific API responses
  • Simulating error conditions
  • Isolated unit testing of integrations

Limitation: Static responses. The mock doesn’t actually process your requests — it just returns what you told it to return.

Contract Testing (Intermediate)

Define a contract describing what each API endpoint should accept and return. The digital twin validates that the agent’s code honors the contract.

Tools: Pact, Spring Cloud Contract.

Better than simple mocking because:

  • The contract is a living document
  • Both sides (your code, the external API) can be tested against it
  • The contract catches drift as the external API evolves

Full Simulation (StrongDM Approach)

Build a simulation of the external service that actually processes requests. This is:

  • More expensive to build
  • More realistic to test against
  • Can catch integration issues that mocking misses

Example: A simulated Jira that actually tracks ticket state, handles transitions, and validates workflow rules — not just returning hardcoded responses.

Combining with External Scenarios

The full StrongDM pipeline:

  1. Digital twin: Simulate all external services
  2. External scenarios: Test the code’s behavior from outside, against the twins
  3. Agent: Never sees the scenarios; only sees the spec and the twins during development

This gives you:

  • Safe execution (no production impact)
  • External validation (scenarios not visible to agent)
  • Full integration coverage (digital twins handle external services)

The Brownfield Problem

Digital twins are hardest for legacy systems. If your existing codebase has years of undocumented integrations with external services — idiosyncratic error handling, edge cases that evolved over time, undocumented rate limit behavior — building a digital twin requires understanding all of it first.

This is another reason brownfield dark-factoring requires extensive documentation work before automation.

Tools and Frameworks

  • WireMock: HTTP service mocking
  • Mockoon: GUI-based API mocking
  • LocalStack: AWS services locally
  • Testcontainers: Real database/service containers for testing
  • Docker Compose: Full environment simulation
  • MSW (Mock Service Worker): Browser-level API mocking for frontend