Amplifier Digital Twin Universe

Mock Services

Testing against the real world without the real world.

April 2026
The Problem

External services make testing painful

Most real software integrates with external services. Testing those integrations creates friction that kills velocity.

🔑

Account Overhead

Slack alone needs: an account, an app registration, a workspace, OAuth tokens. Multiply that for every environment.

⏱️

Rate Limits

Real APIs have quotas. In a software factory where agents constantly create and tear down environments, you burn through limits fast.

🔧

Manual Setup

Throwaway accounts, manual configuration, cleanup after every test run. Non-starter for agent-driven development.

The Solution

Mock services as sidecar containers with DNS rewriting

DTU Profile
Clone Mock Repo
Build Image
Start Sidecar
DNS Rewrite via mitmproxy
App Runs Unmodified
# digital-twin-mock.yaml — the standard manifest name: slack version: 0.1.0 description: Mock Slack service for DTU testing runtime: type: docker build: Dockerfile port: 3000 domains: - api.slack.com - slack.com
Design Principle

No code changes.

The mock is what changes, not the app. The application under test runs exactly as it would in production.

Traffic destined for a real API hostname gets transparently redirected to the mock container. The application under test is installed completely unmodified. It genuinely believes it's talking to the real service.

Traditional Mocking
DTU Mock Services
Modify app code with test doubles
App runs unmodified — production code
Swap SDK clients for fakes
DNS rewrite at the network layer
Test harness version of the app
Test the real thing
"Works in test" ≠ works in prod
What you test is what you ship
Sample Scenario

amplifier-hive-slack: a Slack bot that needs Slack

amplifier-hive-slack is a bot that integrates with Slack's APIs. To test it for real, you need a Slack account, an app registration, a workspace, OAuth tokens — and you're subject to rate limits. In a software factory where agents are constantly creating and tearing down environments, that's a non-starter. So we built a mock.

The Slack mock: 822 lines of Python, 11 API endpoints

🌐

Slack Web API

11 endpoints (GET + POST): auth.test, apps.connections.open, conversations.info, conversations.list, conversations.history, chat.postMessage, chat.update, reactions.add, users.info, bots.info, team.info

🔌

Socket Mode WebSocket

Full Socket Mode support: hello handshake, event envelopes, ack responses, ping/pong keepalive. mitmproxy rewrites the WebSocket URL so the bot connects via TLS transparently.

🎛️

Control API

Endpoints for simulation: /mock/state, /mock/send-message, /mock/add-reaction, /mock/create-user, /mock/create-channel. Full programmatic control.

🖥️

Web UI

Vanilla HTML/JS interface at / with channel list, message feed, and input. Interact with the mock directly from your browser.

Configuration

A DTU profile declares everything

The profile is the single source of truth: what to install, which mocks to wire up, which real APIs to allow through, and how to start the app.

# amplifier-hive-slack.yaml — DTU profile (86 lines) name: amplifier-hive-slack base: image: ubuntu:24.04 mock_services: # ← declare mocks here - source: ${MOCK_SLACK_PATH} config: workspace_name: "${WORKSPACE_NAME}" passthrough: # ← real APIs still work allow_external: true services: - name: anthropic key_env: ANTHROPIC_API_KEY provision: # ← install & launch setup_cmds: - uv tool install amplifier-hive-slack - nohup hive-slack config.yaml &
Workflow

Tell the agent what you want. It builds the rest.

"Look at amplifier-hive-slack and make me a Digital Twin Universe that will let me try it out with a mock Slack."

When the bot wasn't replying as expected, the next step was natural: "Amplifier, can you try x, y, z and simulate some users so I can see how it's working."

Capabilities

You own the mock. You control everything.

🎬

Prepopulate Scenarios

Seed channels, users, message history however you want. Create-user and create-channel endpoints let you build any workspace topology on demand.

🤖

Script Interactions

Send messages, trigger events, simulate multiple users — all through the Control API. Automate entire conversation flows with a shell script.

♾️

No Limits

No rate limits, no accounts to create, no cleanup. Run as many times as you want. Tear down and rebuild in seconds.

Demo

Four themed workspaces. Running simultaneously.

The multi-workspace demo launches 4 DTU environments, each with unique channels, users, and seeded conversations — including bot responses — with live message scripts firing in real time.

🚀

Startup Weekend

4 users, 3 channels (#general, #tech-stack, #pitch-prep). A team building a meal-prep app in 47 hours. The bot helps scope features and structure the pitch.

🎮

Moonlight Studios

4 users, 4 channels (#general, #bugs, #playtesting, #art-assets). An indie game studio preparing for Steam Next Fest. The bot helps debug gameplay and optimize shaders.

🔬

Patel Research Lab

4 users, 4 channels (#general, #paper-drafts, #experiment-results, #reading-group). A research team racing toward the ICML 2026 deadline. The bot reviews paper drafts and suggests experiments.

🏘️

Oakridge HOA

4 users, 4 channels (#general, #maintenance, #events, #lost-and-found). A neighborhood association managing everything from fence disputes to block party planning.

Integration

Close the loop: mocks + browser-tester = full automation

Combined with the browser-tester agent, mock services create a full verification loop — all without touching a single real external service.

Launch DTU
Mock Services Start
App Installs
Browser Agent Tests
Integration Verified

What this means

Vision

A catalog of reusable mocks for any external service

Once someone builds a mock, everyone can use it. The profile just declares what it needs and DTU handles the rest: clone, build, start, DNS rewrite, ready.

💬 Slack Available now
📧 Microsoft 365 Planned
📂 Google Workspace Planned
💳 Payment APIs Planned
🗂️ GitHub API Planned
📊 Any REST API Standard pattern

The framework is designed to be shared. Mocks are standalone repos with a standard digital-twin-mock.yaml definition. The same pattern extends to any external service.

Under the Hood

How DNS rewriting works

# Inside the Incus container, the DTU engine: # 1. Installs mitmproxy pip3 install mitmproxy # 2. Generates a rewrite addon that maps domains to mock containers # api.slack.com → mock container IP:3000 # slack.com → mock container IP:3000 # 3. Installs the mitmproxy CA certificate cp ~/.mitmproxy/mitmproxy-ca-cert.pem \ /usr/local/share/ca-certificates/mitmproxy.crt update-ca-certificates # 4. Sets proxy environment variables export HTTP_PROXY="http://localhost:8080" export HTTPS_PROXY="http://localhost:8080" # 5. Special handling: WebSocket URL rewriting # apps.connections.open returns ws://localhost:3000/ws # mitmproxy rewrites it to wss://api.slack.com/ws # so the bot connects via TLS through the proxy transparently
Get Started

Try it yourself

Tell Amplifier:
"Make me a DTU with a mock Slack so I can try amplifier-hive-slack."

📦

Use an existing mock

Add mock_services to any DTU profile and point it at a mock repo.

🔨

Build a new mock

Create a repo with a digital-twin-mock.yaml and a Dockerfile. That's the contract.

🔄

Run the demo

./demos/launch-multi-workspace.sh to see 4 workspaces come alive.

amplifier-bundle-digital-twin-universe digital-twin-mock-slack
More Amplifier Stories