FIELD · Capacity and platforms · 4 min read
Prove a shared capability with a second customer team
One reusable contract, adapters and a supported integration path.
Arunank Sharan · Kuzushi Labs ·
In this article
This worked application uses explicit planning assumptions to demonstrate FIELD. Quantities below are inputs, calculated implications or proposed targets; they are not reported customer results. The engagement decision remains conditional on the evidence described.
Planning basis and engagement boundary
| Item | Basis for this application |
|---|---|
| Demand and context | Three candidate teams; two independent consumers required before generalizing |
| First delivery boundary | One reusable contract, adapters and a supported integration path |
| Acceptance to agree and test | Second consumer integrates without private core patches or hidden support |
| Exclusion or constraint | Domain-specific policy remains outside the shared component unless deliberately generalized. |
F — Frame the outcome
Reduce repeated delivery/operations effort for real internal consumers while preserving their specialized needs.
Value measure: Onboarding time, support burden and consumer delivery outcomes.
I — Investigate the workflow
Observe what three teams actually duplicate and baseline onboarding/support effort. Identify which domain logic should stay with applications.
First evidence task: Onboard a second distinct workflow and perform a backward-compatible upgrade.
E — Engineer the solution
Use shared identity/budgets/contracts with explicit escape hatches, tenant isolation and compatible release bundles; centralize only demonstrated common needs.
The implementation assessment below makes the authority, workload, resource and failure assumptions concrete. Its numbers are calculations from the stated scenario, not a vendor performance guarantee.
Discovery
Identify what the three teams truly repeat: model access, identity, budgets, tracing, evaluation, tool execution or deployment. Keep domain prompts, product decisions and specialized data logic with applications unless sharing them has demonstrated value. Establish onboarding time and support burden baselines.
Implementation plan
A control plane manages tenants, model/tool catalogs, versions, quotas, evaluation policies and deployment templates. Data-plane services provide authenticated model routing, bounded execution and observability. SDKs expose stable typed contracts and explicit capability differences; escape hatches preserve specialized use while retaining required authority/accounting controls.
State and release
Each application pins a compatible prompt/model/tool/index/policy bundle. Platform contracts have versioned schemas, deprecation windows and automated consumer tests. Rollouts can canary by tenant/app; breaking changes require migration rather than silently reinterpreting tool arguments. Task durability and business effects stay in clearly owned components.
Resources
Pool workloads only when measured reuse/utilization gains outweigh noisy-neighbor and blast-radius costs. Budget model residency, token/KV limits, CPU workers, evaluation bursts, trace storage and cold starts. Attribute cost to logical tenant tasks, including retries and shared fixed cost under an explicit allocation policy. A pooled GPU at high utilization can still deliver poor interactive goodput.
Failure scenarios
One tenant's long jobs cannot consume every slot: enforce weighted quotas, class scheduling and bounded queues. A platform release breaking tools triggers consumer-contract gates and tenant-scoped rollback. If onboarding takes weeks, inspect required manual steps and eliminate friction; a technically elegant platform with no willing second consumer has not met its purpose.
Delivery/evaluation
Onboard two materially different applications through the published interface, without private one-off patches. Measure time to first successful production task, support hours, reliability, upgrade success and app-specific task quality. Compare shared service with a documented self-managed template alternative; centralization is not automatically the right answer.
L — Launch with evidence
Onboard two materially different applications through the published interface. Compare time to useful task, support load, reliability and upgrade behavior with templates/self-management.
Critical decision condition: A platform with no viable second consumer or breaking unannounced contracts is not a validated success.
Attach raw artifacts, the tested configuration, population, denominator, date and limitations to the release record. Missing or stale evidence holds the dependent decision. A favorable value forecast cannot offset a failed critical condition.
D — Develop ownership and reuse
A platform product owner owns adoption/support and consumer teams own domain outcomes; reuse requires a genuine second consumer without private patches.
Candidate reusable asset: One stable shared capability, not an all-purpose agent platform by default.
Commercial decision and next commitment
Accountable decision owner: Internal platform product owner with consumer leads.
The initial commitment is the bounded journey above, with the stated exclusions. Confirm access, customer staffing and acceptance ownership during discovery; price and schedule unresolved dependencies explicitly. A new source, tenant class, language, action or operating envelope requires an impact review rather than silent scope growth.
Approve only the next exposure level supported by the evidence. The next useful investment is: onboard a second distinct workflow and perform a backward-compatible upgrade.
Method and references
Apply the FIELD method, economic model and evidence rules. Methodological and technical influences are listed in the source register.