Deploying Into Customer Environments
On-prem, air-gapped, their cloud, their data. What changes when your code has to run in someone else's house, and why Anthropic now ships MCP servers as the unit of deployment.
Your environment is not the deployment target
A SaaS engineer's mental model is: I run the system, customers consume it. An FDE often inverts that. The customer runs the system; you ship something that lands inside their environment. That single change has cascading consequences. You don't have logs. You don't have observability. You may not have outbound internet. You can't push a hotfix at 3am because their change-management process takes six weeks. Updates require a release artifact, not a deploy. Every assumption you carry from web-scale SaaS, managed databases, autoscaling, a CDN, a vendored auth provider, even reliable DNS, needs to be questioned the moment your code stops running on infrastructure you control.
The four customer-environment archetypes
Most enterprise environments fall into one of four shapes, and the deployment pattern flows from which one you're in. (1) Their cloud account, your management. They give you AWS or GCP credentials; you deploy as if it were yours, with some IAM constraints. Easiest case. (2) Their cloud, their management. You deliver Terraform or Helm and a runbook; their platform team deploys. You need everything to be declarative and version-pinned. (3) Their on-prem, your installer. Often Kubernetes or bare VM. You ship a single artifact (a tarball, a Helm chart, an OVA) that installs end-to-end without internet. (4) Air-gapped. No outbound network at all. Every dependency, container image, and model weight must be bundled in the artifact. License servers, telemetry, dynamic feature flags, and online updates all need offline equivalents. Palantir built its entire FDE practice serving variants of (3) and (4) for intelligence and military customers. Knowing which archetype you're in before you write a line of code determines half your architectural choices.
MCP servers, sub-agents, agent skills
Anthropic's current 'Forward Deployed Engineer, Applied AI' job listing on Greenhouse names the production artifacts the FDE is expected to ship: MCP servers, sub-agents, and agent skills. The choice of those three is deliberate. MCP (Model Context Protocol) servers let an AI system talk to a customer's tools using a standardized interface; the FDE writes one per customer-specific tool. Sub-agents are scoped autonomous units that perform a task and return a result, and they fit cleanly inside the customer's existing job-queue infrastructure. Agent skills are reusable capabilities the model can compose. All three exist because they are the units of deployment most likely to slot into a customer's environment without forcing them to re-platform. If you're interviewing for an AI-lab FDE role, knowing what each of these is and when you'd reach for which is now table stakes.
Integration boundaries, not architecture diagrams
When an FDE drafts the architecture for a customer deployment, the boxes that matter most are the boundaries, not the internals. Where does data enter from their systems (Kafka topic? S3 bucket? SFTP drop?). Where does output land that other teams will consume (a database table they already query? a webhook? an exported file?). What's the auth boundary, do you use their SSO, their service mesh, their secret manager? These boundary decisions are usually made too late, often by the customer's team unilaterally, after your prototype is mostly built. Surface them in week one. A boundary you nail early is a contract that doesn't move; a boundary you defer is six weeks of rework when their security team weighs in.
Data: the constraint that breaks everything
The hardest constraint in enterprise environments is rarely compute or networking; it's data. Their data is in a warehouse you don't have full read access to. It's PII-coated. It can't leave the environment. It's of dubious quality, with three different definitions of 'customer' across systems. The Pragmatic Engineer's reporting on FDE work explicitly notes that FDEs spend significant time on 'data plumbing': integrations, cleaning, schema reconciliation, the unglamorous middle layer that determines whether the eventual model output is meaningful or garbage. As an FDE, your engineering on the data side will often dominate everything else: writing the SQL that joins three of their tables and excludes the rows the legal team flagged, building the ingestion that handles their daily 6am dump, defending why your model can't 'just learn from all the data' when a third of it is junk. Plan for data work to be the majority of the project, not a precursor to it.
What 'production' means here
In a SaaS company, 'production' is a deployment state. In a customer environment, 'production' is a political achievement. It usually requires: their security review (weeks), their architecture review (weeks), a successful UAT against their data (the slowest part), a runbook their on-call team will accept, a rollback plan, and, almost always, a quarterly governance committee sign-off you didn't know existed. None of this work is technical, but all of it is yours to drive. The FDE who treats 'we built it and it works' as the end of the project loses months waiting for the customer to move it through their machinery. The FDE who maps the path to production at the start, identifies the bottlenecks, and works them in parallel with the build, lands the deployment.
Key takeaways
- •Every assumption from SaaS infra (logs, hotfixes, autoscaling, internet) needs to be questioned in a customer environment.
- •Four archetypes (their-cloud-yours, their-cloud-theirs, on-prem, air-gapped) drive most architectural choices. Palantir's history was largely on-prem and air-gapped.
- •Anthropic's current FDE artifacts are MCP servers, sub-agents, and agent skills. These are deliberately chosen for clean fit into customer environments.
- •Get the integration boundaries (data in, data out, auth) defined in week one. Late boundaries cause weeks of rework.
- •Data plumbing (integrations, cleaning, schema reconciliation) dominates FDE engagements per Pragmatic Engineer reporting. Plan for it, not around it.
- •Production is a political achievement, not a deployment state. Map the path through reviews and sign-offs from day one.
Exercise
Pick a customer or enterprise product your company sells to. List what you'd actually need to know about their environment before you could ship code: network archetype, identity, data access, change-management process. Note which of those you currently have answers to. The gaps are the work you're avoiding.
Self-check
- 1.What changes about hotfixes and observability when the customer runs your system instead of you?
- 2.Name the four environment archetypes and one customer scenario for each.
- 3.What are MCP servers, sub-agents, and agent skills, and why has Anthropic chosen them as the FDE unit of deployment?
- 4.Why are integration boundaries more important to nail in week one than internal architecture?
Sources