Every custom request creates an asset or a liability. Shipping it does not settle which one.
A field team may solve an urgent problem, learn something important, and still leave a fragile fork that nobody owns. Another one-off may reveal a repeated need that belongs in the product. A third may be worth doing once under an explicit exception. Some work should be discarded after it produces the evidence it was meant to produce.
The headline is a product-discipline question, not a demand to turn every customer request into a feature. Before field work compounds, someone has to decide what it becomes.
What the public evidence establishes
Decagon's June 2026 account of Agent Development describes a field system that could no longer rely on brute-force customer launches. The company says it created a team focused on getting agents from zero to one while making that motion compound. That is Decagon's account of its own operating model, not a universal benchmark.
Factory's current Software Engineer, Deployed role connects customer work to expanding product capabilities, influencing the roadmap, building tooling and documentation, and translating feedback into product improvements. The source describes Factory's role; it does not disclose the economics of each deployment.
Practitioner sessions add attributed detail. Speakers from Factory, Cognition, Decagon, and Kepler describe field-to-product signals, upstreaming, product strategy in the field, or deliberate disposal. These are named viewpoints. They support the importance of a field-to-product loop; the four-disposition system below is my operating analysis.
Four dispositions for field-created work
1. Product capability
Work belongs in the core product when it represents a repeated, strategic problem the provider intends to solve for a defined customer class. It needs product ownership, supported interfaces, tests, documentation, release semantics, and a migration path from the field-built version.
“A second customer asked” is not sufficient. The team should understand the common problem beneath different requests and the carrying cost of supporting the capability.
2. Reusable delivery asset
Some work should not become a customer-facing feature. It can still make delivery repeatable: a connector pattern, evaluation harness, configuration template, deployment check, runbook, diagnostic, or self-service path.
The asset may sit with field engineering, enablement, or a delivery-platform team. Reuse still requires maintenance, versioning, documentation, and a clear data/IP limit. Copying a file between engagements does not create a governed asset.
3. Bounded customer exception
A one-off can be justified even when it will not generalize. Name it as an exception rather than implying that product will absorb it later.
Record the customer-specific reason, responsible party, support obligation, upgrade path, security and data constraints, review date, and retirement condition. The exception may be valuable. Hidden exception debt is the risk.
4. Discard
Some work has completed its job when it disproves an assumption, reveals the real workflow, or shows that the requested path is not worth supporting. Keeping it may cost more than rebuilding if the need returns.
Preserve the decision and any generalized learning that the provider is permitted to retain. Remove unsupported code, access, data, and operational expectations according to the applicable agreement and policy.
Let evidence change the disposition
A disposition is provisional until evidence supports the commitment it creates.
Move an exception toward a reusable delivery asset when the same operating problem recurs, the solution can be separated from customer-specific data or code, and a delivery-system owner accepts maintenance. Move it into product when the problem fits product strategy, a defined customer class needs it, the architecture belongs in the supported platform, and a product owner accepts roadmap and lifecycle cost.
Move work toward discard when the problem does not recur, the pattern cannot be separated from one customer's context, support cost is disproportionate, or the experiment resolves the decision without requiring a persistent asset.
These are decision conditions, not automatic thresholds. Public sources provide no universal number of customers or requests that makes something a product.
Establish a field-product contract
Customer proximity does not automatically create product learning. Field and product functions need a compact record for how work enters, changes disposition, and exits:
- customer problem and current workflow;
- proposed generalizable pattern;
- customer data, code, and IP boundary;
- current disposition and accountable party;
- evidence required to change disposition;
- next review date; and
- support or retirement condition.
The record should be brief enough to maintain and specific enough to govern a decision. “Productize later” is not a disposition.
Run a weekly review while context is fresh. Field engineering brings repeated patterns and operating consequences; product brings strategy and platform cost; engineering brings architecture and maintenance implications. Add commercial, security, or legal participants when commitments or asset boundaries require them.
The review must end with accept, route, bound, discard, or a named evidence task with a return date.
Watch exception debt early
Exception debt appears operationally before it appears cleanly in financial reporting. Look for forks that cannot take upgrades, manual rituals known by one FDE, connectors without maintainers, tests that run only in a customer environment, recurring support escalations, and roadmap items whose only status is “important account.”
Those signals do not prove the work is unprofitable. Public evidence supplies no standard FDE margin or utilization benchmark. They show that the provider has deferred a disposition decision and is carrying attention, support, or upgrade risk.
Preserve the ownership limit
Field learning raises IP and data questions. A provider may recognize a generalized pattern without having the right to retain customer data, code, prompts, evaluation examples, or workflow artifacts. Contract, product, region, and policy matter. This article does not infer reuse rights and is not legal advice.
Classify the asset and its ownership limit together. “Product signal” must never become shorthand for copying customer work.
Before accepting the next custom request, assign a provisional disposition, a responsible party, and a review date. The label can change as evidence arrives. What should not remain ambiguous is who decides and what commitment the provider is carrying.
Custom work compounds when the field team can turn it into supported product, governed delivery capability, a visible exception, or a documented stop. Without disposition, it remains an unresolved commitment that grows with the customer base.