A shared agent service with tenant-level accountability

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

F — Frame the outcome

Provide shared agent capabilities that improve tenant delivery and verified outcomes while containing cost, fairness and operational burden.

Value measure: Cost per verified tenant outcome, onboarding effort and class-specific goodput.

I — Investigate the workflow

Observe consumer differences, background versus interactive work and concentrated tenant load; define who owns policy, exceptions and quotas.

First evidence task: Combine a dominant tenant burst, provider quota reduction and an in-flight version upgrade.

E — Engineer the solution

Use separated configuration/execution responsibilities, versioned adapters and per-tenant budgets; preserve the token/event/stream capacity model.

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.

Implementation plan

Separate configuration/governance from execution. The control plane manages approved integrations, contract manifests, quotas, identity mapping and rollout policy. Workers receive validated configuration snapshots rather than synchronously consulting a global registry on every internal step. Revocation-sensitive actions still require an enforcement path with a defined freshness bound. Choose behavior during control-plane failure explicitly: existing low-risk reads may continue under valid configuration; actions requiring a fresh grant fail closed.

Partition durable work and state using tenant/run keys with a plan for large tenants and hot partitions. Weighted admission and per-tenant concurrency prevent one customer from monopolizing workers, model quota or a shared business API. Use separate queues for interactive, background and sandbox jobs. Protocol gateways perform version-specific validation/routing and propagate bounded deadlines; they do not become a generic proxy that forwards arbitrary credentials or endpoint URLs supplied by the model.

Keep operation identity and policy enforcement independent of framework. Offer typed adapters and a conformance suite. A compatibility manifest declares tested protocol/SDK/binding/extension combinations. Pin in-flight runs or migrate state explicitly. Canary new work; shadow only safe/stubbed operations. Rollback includes old task readability, approval meaning and integration configuration.

Capacity and SLO reasoning

At peak, tool load is 300 calls/s. With 400 ms mean wait, mean tool concurrency is 120. Three model calls/task give 150 model requests/s; at 2,000 input/300 output tokens, this is 300,000 input and 45,000 output tokens/s. A protocol gateway that uses little CPU can still bottleneck on sockets, authorization latency, serialization or dependency quotas. Measure per-component demand rather than assigning all latency to “the model.”

Twelve 2-KB events/task produce 1.2 MB/s and 103.68 GB/day raw. Thirty days is 3.1104 TB raw, before replication/indexes/backups. Use retention classes, object references and cost accounting; avoid keeping every token delta forever in the authoritative event store. Ten thousand open streams with 64-KiB buffers consume 625 MiB before connection/runtime overhead. Slow consumers need bounded buffering and a defined resynchronization path.

Set separate SLOs for admission, progress freshness, eligible task completion, tenant fairness and state recovery. Measure p95/p99 under representative load, including bursts and dependency throttling. Define RPO/RTO per state class: losing a progress projection differs from losing an acknowledged operation receipt. Regional failover needs identity, secrets, queues, artifacts and external-system access, not just replicated application pods.

Failure and rollout

Inject one tenant's tenfold burst, a model quota reduction, a gateway restart, stale configuration, a revoked credential and one zone outage. Admission should shed or queue before memory and downstream retries explode. Use circuit breakers and bounded retry budgets without globally blocking healthy dependencies. Observe unknown-outcome backlog and manual-review workload as first-class operational signals.

Track cost per verified outcome by tenant/workload/model, including failed attempts, polling and remote-agent charges. Keep trace payloads bounded and redacted. Use deterministic fixtures for conformance/security and representative model evaluations for quality; both gate releases.

If the scope changes: A single tenant contributes 70% of traffic. Isolate or partition its workload, enforce a negotiated quota and revisit capacity reservation. Hashing on tenant alone can concentrate load rather than solve it.

Simpler alternative: Begin with a shared application and database plus modular adapters when actual scale is small. Extract independent services only when measured bottlenecks, isolation requirements or team ownership justify them.

L — Launch with evidence

Canary by tenant/workload, inject quota and zone failures and compare task quality/cost. Test old runs and approvals through upgrades and rollback.

Critical decision condition: A noisy tenant, unsafe downgrade or stale authority cannot be hidden by aggregate availability.

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

Platform product and service owners accept support, economics and revocation behavior; consumers retain domain logic and outcome ownership.

Candidate reusable asset: Versioned runtime contract with a demonstrated second consumer.

Commercial decision and next commitment

Accountable decision owner: Platform service owner with consumer outcome owners.

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: combine a dominant tenant burst, provider quota reduction and an in-flight version upgrade.

Method and references

Apply the FIELD method, economic model and evidence rules. Methodological and technical influences are listed in the source register. The protocol assessment follows the agent control chapter; pin and verify the actual protocol/runtime combination before implementation.