Field productization

Make a field capability work beyond its original author and setting. Inspect the task, artifacts, implementation, expert interventions, and deployment effort. Identify what made it valuable and what another team would have to rediscover.

Find the part worth reusing

Describe the job before choosing the component. A research workflow depends on testing explanations, source access, and a useful artifact; its prompt captures only part of that capability.

Compare cases along the dimensions that change behavior: task, domain meaning, context, tools, output, and lifecycle. Separate stable method from local knowledge and system-specific action semantics. Use a materially different task or deployment to challenge the proposed abstraction. When one case exposes a compelling platform gap, build the smallest useful response and use the next case to test its reach.

Capture discoveries while doing the work: a successful method, source quirk, diagnostic test, or reason an approach changed. Turn the useful lesson into the maintained skill, context, tool, or example another team will use. Preserve what changes the next attempt rather than publishing a transcript of every run.

Package the capability at the right layer

Choose the asset that removes demonstrated reinvention:

• Task skill: A transferable method, decision criteria, and examples for doing a job well.
• Context asset: Maintained definitions, source maps, examples, or schemas that let an agent understand the enterprise's work.
• Tool or adapter: A clear operation that supplies information or performs an action with meaningful, testable semantics.
• Evaluation set: Cases that preserve the expertise needed to judge success, including useful alternatives and known failure mechanisms.
• Harness capability: Shared behavior such as durable work, resumption, artifact handling, or observable execution.
• Product or delivery practice: A supported combination that a customer or deployment team can use repeatedly.

Repair defects in existing promises before treating them as new features. Inspect current supported capabilities before maintaining another layer. Keep a customer-specific rule local when its meaning does not transfer; use configuration when the variation has clear, checkable semantics.

Make reuse concrete

State what the consumer supplies, what the capability completes, and which variations it supports. Include the context and access assumptions that otherwise live in the author's head. Let the next team run a representative task and a difficult variation. Inspect its result and the adaptations it needed.

For a skill, have another user or agent use it without its author's explanation. Exercise tools against the receiving system and test harness continuation against persisted state. Check that evaluations recognize good solutions from another implementation.

Keep reusable learning separate from customer data and rights. Permission to deliver a deployment does not grant permission to redistribute its documents, policies, traces, or examples. Transfer the general method using permitted material or independently constructed cases that retain the behavior being tested.

A covenant-review example shows how a reusable investigation and calculation workflow can travel while negotiated definitions remain local. It also shows why shared code alone may not reduce delivery effort.

Support variation and change

Provide extension points for differences that matter, such as a source adapter, metric definition, or output destination. Keep incompatible business meanings explicit.

After model improvements, compare performance with and without older capability guidance or scaffolding. Retire workarounds that no longer help. Keep current domain definitions, user preferences, authority, and security contracts: their validity does not depend on a quality-score gain.

Choose an owner who can maintain the asset and receive field corrections. Version behavior when consumers rely on it, and identify what an upgrade changes for existing configuration, open work, and evaluation cases. Preserve old decision evidence where later changes alter its interpretation. Make the supported migration practical enough that teams can adopt the improvement.

Test the economic effect of repetition

Measure where scarce effort remains: context mapping, integration, expert interpretation, validation, onboarding, and support. Name which effort the reusable asset should reduce and compare the next deployment with that hypothesis. Include new maintenance and adaptation costs. Reuse can also enable a valuable task that was previously uneconomic.

Give product and engineering a concrete investment choice: the obstructed outcome, proposed behavior, meaningful variation, reproduction or demanding case, and delivery benefit. Work with the receiving team on the implementation, try it in the field, and retire the replaced workaround.