Module 19 · Lesson 01

Production Deployment Patterns — Configuration, Versioning, and Environment Separation

Reading time: 19 minutes Track: Yungsten Tech Employee Curriculum · Implementation Engineering

Why deployment discipline matters for named agents

Named agents are deceptively simple to set up the first time. A claude_desktop_config.json, a couple of MCP server packages, a system prompt in Claude's project settings — it's running in 30 minutes. This speed is the hazard.

What breaks at 6 weeks isn't the AI. It's the surrounding infrastructure: a package that auto-updated and changed behavior, a credential that rotated without anyone knowing which file to update, an MCP server that silently stops returning data because an upstream API changed. The agent appears to work, but the outputs are degraded, and nobody knows why.

Production deployment discipline prevents this class of failure.

Environment separation: dev, staging, client-prod

Every Yungsten client agent that will be used for real work should exist in at least two environments:

Development (your machine) Where you build, test, and iterate. Uses test credentials, test data, and throwaway system prompts. Nothing here touches client production data.

Client production (client's machine) The running deployment the client's team uses daily. Locked configuration, documented credentials, change-controlled updates.

For larger engagements with higher change velocity, add a staging environment on a Yungsten-controlled machine that mirrors client-prod before any change goes live.

The practical implementation:

• Keep separate claude_desktop_config.json snapshots per environment (stored in the engagement repo, not just on the client machine)
• Use environment-specific credential sets — never share API keys across dev and prod
• Document which MCP server versions are pinned in each environment

Pinning MCP server versions

The default MCP server install pattern — npx -y @package/mcp-server-name — fetches the latest version every time Claude Desktop starts. This is convenient for development and dangerous for production.

Pin versions in production:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem@0.6.2", "/path/to/docs"]
    }
  }
}

The versioning checklist before client deployment:

1. Identify the current version of each MCP server you're deploying (npm show @package/mcp-server-name version)
2. Pin that version explicitly in the production config
3. Document the versions in the engagement wiki under the agent's entry
4. Set a quarterly reminder to evaluate version upgrades — don't upgrade automatically, upgrade deliberately

Configuration as code

The claude_desktop_config.json for each client deployment belongs in version control — not just on the client's machine. Reasons:

• When the client machine breaks or is replaced, you can restore in minutes
• You can diff what changed when something breaks
• You can review changes before applying them to client-prod

For each client engagement, maintain:

/engagements/[client-name]/
  config/
    claude_desktop_config.json     (production — no real credentials, use env var refs)
    claude_desktop_config.dev.json (dev environment)
  credentials/
    README.md                      (where credentials are stored, rotation schedule)
  system-prompts/
    [agent-name].md                (versioned system prompts)

Never commit real credentials. Store them in the client's chosen secrets system (macOS Keychain, 1Password, AWS SSM) and reference them via environment variables in the config.

Change control for production agents

Any change to a client's production agent deployment should follow a change control process, no matter how small. The process can be lightweight, but it must exist:

1. Document the change — what's changing and why (one sentence each)
2. Test in dev — verify the change works as expected
3. Client notification — inform the client contact before applying (even for minor changes)
4. Apply with a rollback plan — keep the previous config available so you can revert in under 5 minutes
5. Verify post-change — run the agent's test cases after applying the change
6. Update the wiki — the agent's wiki entry reflects the current state

Changes that require client approval before applying: system prompt changes, new MCP server connections, any change affecting data access.