Performance lens

Apply with root AGENTS.md, including its allocation and retained-memory guidance. This lens examines resource cost: network, disk, memory, and CPU, each by bandwidth and latency.

Procedure

1. For performance-sensitive changes (hot paths, per-message or per-activation state, scale-dependent work), estimate the dominant costs at realistic counts of activations, messages per second, and silos.
2. Identify the slowest resource on the path, weighted by frequency.
3. Prefer design-level wins (batching, control/data plane separation, locality) to micro-optimizations.
4. Support performance claims with comparable before-and-after measurements: BenchmarkDotNet projects under test/Benchmarks for local code paths, and load or integration measurements for distributed behavior.
5. Keep correctness and simplicity intact; a faster design that weakens an invariant is a regression.

Checklist

• Back-of-envelope at design time. The largest wins come from design, so new designs and scale-dependent changes start from an estimate of network, disk, memory, and CPU cost.
• Slowest resource first. Effort goes to the few bottleneck operations, identified by measurement and weighted by frequency.
• Tail latency. Fan-out and background contention are evaluated through end-to-end latency percentiles under representative load (The Tail at Scale).
• Bounded speculation. Retries and hedges share explicit attempt, concurrency, and time budgets with the original request; duplicate execution and work continuing after cancellation preserve the operation's contract.
• Batch. Per-operation overhead (storage writes, messages, directory operations) is amortized across batches where latency, ordering, and partial-failure semantics permit.
• Separate planes. Control-plane work (membership, directory, placement) stays out of per-message and per-turn paths, which use cached decisions with defined refresh.
• Run at your own pace. A component that receives external events processes them in batches at its own rate, rather than doing full work per event as it arrives, where latency permits.
• Simple algorithms for small N. Where N is small in practice (per-activation collections, silo counts), the simplest algorithm wins; scale-dependent N (activations, messages, subscriptions) justifies better complexity.
• GC-aware hot paths. On hot paths (messaging, serialization, scheduling), avoidable steady-state allocations are removed with pooled buffers, pre-sized collections, Span<T>, and structs where measurement shows net benefit.

Findings

Report findings ordered by expected impact, each with the location, a cost estimate or measurement with its stated assumptions, and a concrete fix.