An FDE accelerator is not reusable because it worked once. It becomes a candidate for reuse when a bounded component survives a second, materially different context with its assumptions and exceptions made visible.
Proposed method: this pattern qualification record is FDE Brief editorial synthesis, not an AWS or Anthropic operating standard. A second deployment is useful evidence, but it does not prove a component is safe, economical, or broadly portable.
Why the second customer matters
AWS’s Principal Forward Deployed Engineer posting describes reusable architectures, patterns, engineering mechanisms, production-readiness criteria, and reference architectures. Anthropic’s Applied AI Engineer, Enterprise Tech posting describes guiding customers from discovery through deployment, identifying common design patterns, and creating scalable technical assets.
Those are employer-authored descriptions of expected work, checked October 1, 2026. They do not show that a particular accelerator was reused successfully, reduced delivery time, or should become a platform feature. The practical interpretation is to test the reuse claim rather than attach the label after a first launch.
Start with a bounded component
Choose an artifact with a clear interface: a retrieval adapter, workflow state machine, approval gate, test fixture, or escalation packet. “Reuse our customer deployment” is too broad. A usable claim is: “Given an approved document collection, normalize metadata and return citations that preserve source ID and revision.”
Do not move production data, credentials, or privileged actions merely to run the test. Use approved environments and the receiving customer’s access controls.
Write the first customer’s hidden assumptions down
| Assumption | Evidence in the first context | What breaks if false? |
|---|---|---|
| Every source has a stable document ID | Ingestion contract and test fixture | Citations cannot be reconciled after updates |
| Metadata includes an owner and revision | Content-governance workflow | Stale material cannot be routed for correction |
| Support staff have read-only diagnostics | Role-permission matrix | Recovery becomes an unsafe admin workaround |
| Documents fit an expected structure | Sample set from the first test | Extraction or retrieval may need another strategy |
These are example fields, not facts about any customer. Ask the receiving team to correct them. “We do not know” is a valid value and a reason to hold the reuse claim.
Worked fictional example: a retrieval adapter
Everything in this example is fictional. A team built a small retrieval adapter for Customer A’s internal support portal. It expects a source ID, revision, content owner, and access class, then returns a citation bundle so an operator can decide whether an answer is current.
Customer B also wants a support assistant. Its filenames can change, ownership lives in a separate records system, and contractors can view only some sources. Each difference changes the component’s contract.
| Qualification field | Customer B observation | Disposition |
|---|---|---|
| Source identity | Filename can change | Add a mapping layer; do not reuse identifiers unchanged |
| Revision evidence | Revision is in a separate records system | Hold freshness claim until the approved join is tested |
| Owner lookup | Owner is external to the source record | Make lookup configurable and name a system owner |
| Access boundary | Contractor and employee scopes differ | Require authorization design before any production connector |
The proposed result is stable core with required adapters, not “drop-in accelerator.” No time saved, reliability improvement, customer outcome, or successful deployment is asserted in this fictional example.
Run a narrow fit check, then record the exception
Define the smallest permitted test that could falsify the claim: retrieve three approved test documents from Customer B’s sandbox, verify that each citation resolves to the correct source record and permitted viewer, and record every mapping or permission exception.
- Observed evidence: what the test actually showed.
- Unresolved constraint: what remains unknown or blocked.
- Local adaptation: code, configuration, or process belonging only to this context.
- Candidate stable core: behavior that passed in both contexts.
A passing sandbox check is not production acceptance. Production readiness needs its own approval, security review, operational owner, and acceptance evidence.
Make a disposition with an owner
- Generalize: move only the documented interface, configuration, tests, and known limits into a shared artifact.
- Keep local: preserve customer-specific value when assumptions are too particular or insufficiently tested.
- Retire: stop carrying a component whose dependencies or exception handling outweigh repeatable value.
Name the accountable person, evidence reviewed, and condition that would reopen the decision. A shared repository without that record is storage, not a reusable delivery mechanism.
What this signals in a career or hiring review
A credible FDE reuse story explains one customer-specific assumption, how it was tested elsewhere, and why the team generalized, localized, or retired the work. Candidates can use fictional or open-data cases; they should not invent client outcomes or permission to disclose former employer materials.
Teams can present a first-customer artifact and second-context constraints, then evaluate what the person would carry forward, rework, hold, and escalate. Assess the reasoning and safety boundaries—not whether they say “productize everything.” Related guides: turn one deployment into a platform bet, this qualification record, and the deployment context packet.
The FDE Brief
Get practical deployment-pattern field notes.
Get FDE playbooks on customer context, delivery judgment, and reusable technical artifacts.
Reader question
What did the second customer expose?
Which supposedly reusable component required the most rewriting—and what assumption did it reveal?