FDEs don’t scale, but their context should.

The Forward Deployed Engineer (FDE) model has powered many of the most successful enterprise software companies. You embed a highly capable engineer inside a customer; they learn the customer’s world; they ship exactly what’s needed. It works. But it doesn’t scale, not because the engineers aren’t good enough, but because the context doesn’t move with them.

In this post, we reframe the FDE model as a context and memory problem, explain why most AI agent approaches don’t actually fix it, and describe how XTrace enables “private, portable context” so vendors can reliably ship seasoned, product‑aware agents into every enterprise.

The real FDE bottleneck: context, not talent

FDEs are effective because they sit at a unique intersection of knowledge. They understand the product, its architecture, and the internal constraints of their own company. They also learn the customer’s systems, workflows, constraints, and politics. Over time, they become a living bridge between “how our product works” and “how your business runs.”

This bridge is valuable but fragile. Each new enterprise engagement requires a fresh ramp‑up. An FDE must re‑learn a large amount of overlapping information, rebuild mental models that often look 80% like those from previous customers, and integrate a small but critical set of local nuances. None of this learning is captured in a form that can be reused systematically across customers.

The result is that the FDE becomes a single point of failure for the context they have accumulated. When they roll off, a substantial portion of that nuance disappears with them. The organization loses not only extra hands, but hard‑won understanding of how the product and the customer’s environment actually fit together in practice. This is the true scalability limit of the FDE model.

Why most AI agents don’t solve the FDE problem

On the surface, AI agents should be an ideal way to scale the FDE pattern. Agents can read documentation at scale, never get tired, and can be instantiated on demand. In practice, however, most agents deployed today are not true carriers of long‑lived context.

Typical agents are either stateless or tied to a narrow, short‑lived state such as a single chat history or session transcript. They may have access to ad‑hoc retrieval over scattered documents or a per‑customer vector store, but they lack a coherent, durable memory that spans many deployments and many enterprises. They also lack a governed, auditable way to separate what should be shared across customers from what must remain local and private.

Because of this, context remains non‑portable. Spinning up a new agent for Company B rarely means it arrives with the operational “intuition” accumulated from other deployments at Company A, C, or D. At best, teams replicate some subset of documents into another store and hope retrieval will surface the right fragments. In practice, the same discovery, integration, and troubleshooting work is repeated, just with an LLM in the loop.

To replace FDEs in a meaningful way, agents need more than tools and prompts; they need access to structured, long‑lived, portable memory that is fully private.

Reframing the solution: from people to portable context

If we treat the FDE bottleneck as a context problem rather than a staffing problem, the target architecture changes. Instead of asking “How do we get more FDEs?” or “How do we embed an LLM in the FDE workflow?”, the more fundamental question becomes: “How do we capture and move the context that makes FDEs effective?”

In a portable‑context model, the primary object we deploy to a new customer is not just an agent, but an agent backed by a memory layer that can move with it. This memory layer must be able to:

• Persist the accumulated experience of many FDE‑style engagements into a reusable, structured knowledge base.

• Compose vendor‑wide product knowledge with customer‑specific environment knowledge, while keeping clear boundaries between the two.

• Expose that combined context to agents in a way that is queryable, traceable, and governed.

XTrace provides this layer in the form of a Memory Hub: a persistent, structured memory substrate designed for agentic systems. Rather than encoding operational knowledge only in people and scattered documentation, XTrace turns it into durable, agent‑readable context.

Step 1: the vendor ships a product‑aware agent

Consider a SaaS vendor, Company A, that has deployed its product into many environments over several years. Its teams understand typical deployment topologies, common integration points, recurring misconfigurations, and the patterns that separate resilient setups from fragile ones. Historically, much of this understanding exists in individuals’ heads, long email threads, or internal documentation that is hard for automation to consume.

With XTrace, Company A can capture this experience in a vendor‑wide Memory Hub. The Memory Hub stores operational runbooks, incident resolutions, best‑practice designs, and anti‑patterns in a form that agents can use directly. This is not just a document index; it is a persistent memory of decisions, outcomes, and the contexts in which they occurred.

When Company A “ships an agent” to a new customer, it is effectively shipping two things: an AI agent configured to reason about the product and interact with relevant tools and APIs, and access to the vendor’s Memory Hub, which encodes global expertise from previous deployments. From the moment it is deployed, the agent can draw on years of accumulated product knowledge, rather than approaching each new environment as a blank slate.

Step 2: the customer attaches environment‑specific memory

Now consider Company B, the customer adopting Company A’s product. Company B’s environment contains its own complexity: internal services, data flows, deployment pipelines, security constraints, historical incidents, and local conventions for naming, alerting, and escalation. An FDE would typically learn this through onboarding sessions, reading internal documents, and participating in real incidents and changes.

Using XTrace, Company B can attach its environment context as a separate, customer‑owned memory layer. This layer can include architecture diagrams, internal runbooks, ticket histories, decision records, and domain‑specific vocabulary. It is governed by Company B’s own access policies and remains logically distinct from Company A’s global memory.

The same agent that carries Company A’s product knowledge can now also operate over Company B’s local memory. Through XTrace, it can understand how the product is supposed to behave in general and how Company B’s systems are actually configured. It can reason across both contexts when planning changes, diagnosing issues, or suggesting improvements, while XTrace enforces that data cannot cross organizational boundaries without explicit intent.

At this point, the agent stands at the same bridge point an FDE once occupied, but with significant differences. Its “experience” is explicit rather than implicit, persistent rather than fragile, and portable rather than tied to a single individual.

Step 3: every deployment makes the next one smarter

Once the agent is operating at the bridge point between Company A's product knowledge and Company B's environment, it doesn't just consume context; it creates it.

As incidents are diagnosed, changes are rolled out, and edge cases are discovered, those interactions are written back into memory in two distinct streams. Company-wide patterns, anti-patterns, and runbooks flow into the vendor's Memory Hub, where they can shape future agents and future customers. Meanwhile, environment-specific decisions, exceptions, and historical incidents are captured in Company B's own memory layer, where they become part of its operational fabric.

XTrace enforces what can generalize and what must remain local. The result is that each deployment is not a one-off project, but a contribution to a growing, governed body of experience—shared where it should be, isolated where it must be.

Preserving FDE leverage without the human bottleneck

This private, portable‑context approach keeps the benefits of the FDE model while removing its primary constraints.

The vendor’s experience is no longer lost when individuals leave or projects end. Patterns and lessons from each deployment are written into the Memory Hub, where they can inform future agents. Instead of relying on informal knowledge transfer, new engagements start with a baseline of accumulated, structured experience.

Onboarding in new environments is faster and more consistent. The agent brings deep product familiarity on day one and needs only to ingest the customer’s local memory layer to become effective. This reduces the time required to reach a stable, reliable deployment compared to spinning up a net‑new FDE for every customer.

There is no longer a single human point of failure for context. When a traditional FDE moves on, the nuanced understanding of how that specific environment behaves often goes with them. With XTrace, that understanding is stored as durable memory that can be queried and extended by future agents or humans.

Finally, context sharing becomes controlled and auditable. Vendor‑wide and customer‑specific memories are explicitly separated, and XTrace enforces which agents can access which segments. Access can be monitored, policies can be applied, and the flow of context between organizations is governed rather than implicit.

XTrace as memory infrastructure for agentic systems

Supporting portable context requires more than simply pointing an agent at a database. XTrace is built as memory infrastructure for agentic systems, with several design goals:

It provides persistent, user‑owned memory rather than ephemeral conversation logs. Knowledge is represented as long‑lived entities that can span many sessions and many agents, supporting longitudinal learning and operational history rather than one‑off interactions.

It offers a shared memory substrate for multiple agents. Different agents—focused on infrastructure, security, product configuration, or support, for example—can share and contribute to the same memory. This supports richer multi‑agent architectures where each specialized agent benefits from the context accumulated by others.

It is designed for privacy and multi‑tenancy from the start. Vendor‑level and customer‑level memories are isolated, with explicit controls for what can be combined or exposed. This enables organizations to trust that their data will not leak across tenants while still allowing agents to reason across the boundaries that are intentionally created—for example, between a vendor’s product knowledge and a customer’s local environment model.

What this unlocks

When FDEs are viewed through the lens of context and memory, the path to scaling them becomes clearer. The core idea can be summarized succinctly: FDEs scale poorly because their context does not. Agents only begin to replace them when their context becomes portable.

With XTrace, a vendor can ship an agent that arrives with deep, accumulated product knowledge, and each customer can attach its own environment‑specific memory in a governed way. Over time, the vendor’s global memory improves with every deployment, and each customer’s local memory becomes a tailored operational asset for their own environment.

XTrace is building the memory infrastructure that makes this form of portable context practical, auditable, and safe in real enterprise settings.