Traditional model serving can treat a request as a relatively compact unit: send work to inference, receive a result. Production agent workflows are structurally different. They repeatedly alternate among GPU inference, scheduler/orchestrator control work, and bursty tool execution. Those roles do not share the same latency sensitivity, concurrency profile, or safe reclamation boundary.
The same-day Research Object therefore supports a stronger infrastructure judgment: schedule workflow roles and execution shapes, not merely average CPU or GPU utilization.
Central judgment
Average idleness is not proof of reclaimable capacity.
A system can show low mean utilization while critical-path bursts are already saturated. If a resource controller sees only idle percentage, it may harvest runner CPU or GPU capacity exactly when tool bursts or inference concurrency need it most, turning a packing optimization into a tail-latency failure.
A production agent resource plane therefore needs at least four inputs: role class, burst/concurrency shape, visibility of future work, and a reversible retreat policy. Efficiency policy must also remain independent from tenant, credential, sandbox, and business-priority constraints.
Source
This candidate consumes only the Production-authorized Q-20260807-02 Research Object. Production did not return to the Signal Pool or Reading Result for new research. The Reading Result is retained only as the evidence boundary and provenance path declared by the Research Object.
Observation
The Research Object preserves several negative operating points that matter more than a headline utilization number.
First, control/scheduler work and runner work have materially different resource behavior. Control paths need stable low-tail-latency CPU availability. Tool runners are bursty and locality-sensitive. They should not be subjected to one undifferentiated reclamation rule.
Second, GPU consolidation is workload-dependent. The analyzed evidence contains a regime where consolidation or harvesting benefits one workload, but aggressive GPU removal is severely harmful for high-load parallel CORAL. The lesson is not that GPU harvesting fails; it is that one global reclamation policy is unsafe.
Third, CPU isolation is non-monotonic. Fully private task cores strengthen separation but remove useful slack and can slightly worsen completion time. Maximum isolation is therefore not automatically the optimal efficiency point.
Fourth, host-visible graph or tool-type hints can support proactive placement, while model-orchestrated workflows cannot reveal the next tool or branch until inference resolves it. The latter need more conservative reactive control.
Comparison
| Runtime role | Primary objective | Typical resource shape | Aggressive reclaim? | Failure signal |
|---|---|---|---|---|
| Control / Orchestrator | Stable decisions and low tail latency | Persistent CPU, critical-path sensitive | Generally no; isolate first | Scheduling delay, context switching, control blockage |
| Tool Runner | Throughput and burst response | Short CPU/IO spikes, variable concurrency | Bounded and reversible | Queue growth, runner contention, tail-latency rise |
| Inference service | GPU throughput and latency | GPU residency, batching, concurrency-dependent | Workload-specific | GPU contention, batch-tail collapse |
| Trust / Business gate | Security and business boundaries | Not a compute pool | Not an efficiency decision | Tenant, credential, sandbox, priority conflict |
The first three rows reflect resource roles described in the Research Object. The final row states an independent engineering boundary: computationally efficient collocation is not automatically authorized collocation.
Discussion
The architectural shift is not “drive utilization higher.” It is moving resource control from a model-serving unit to a workflow-role unit.
Control paths, tool execution, and inference services need different SLOs. A scheduler should know which work is latency-sensitive, which runner capacity can be temporarily lent, which GPU workloads tolerate consolidation, and when the system must retreat. A safe reclaim controller is therefore a feedback loop over workload phase, concurrency, role overlap, and tail latency—not a one-time static packing decision.
Negative operating points should become first-class control signals. A CORAL-like contention regime is not simply “poor optimization performance”; it means the policy crossed a safety boundary. The runtime should record the retreat reason and make later placement decisions explain why harvesting stopped.
Model-driven orchestration adds another uncertainty boundary. When the next tool mix is not host-visible, the scheduler cannot pretend it owns a complete future DAG. It needs conservative reactive control using recent observations and role labels rather than borrowing proactive assumptions from graph-visible workflows.
Engineering impact
For an enterprise agent platform, separate at least three resource classes first: control-plane cores, tool-runner capacity, and inference capacity. Execution units should expose role class, latency sensitivity, tool-burst profile, concurrency shape, and trust/credential boundary rather than only process-wide CPU/GPU averages.
For smaller organizations, reproducing a hyperscale server design or solver is unnecessary. A practical path is to isolate PM/QA/control paths first, then apply bounded, reversible reclaiming to worker/tool capacity after collecting a small set of repeatable workload signatures.
For CodeFlowMu, PM/QA and critical control services should remain isolated from opportunistic worker capacity before aggressive utilization work begins. Runtime telemetry should distinguish control, inference, and runner time, and record threshold crossings, retreat reasons, and recovery. Cross-sandbox, cross-credential, or cross-tenant collocation must pass a trust gate even when a profiler predicts spare capacity.
Boundaries and counter-evidence
The Research Object is explicit about transfer limits: the production trace covers one reported 24-hour window; the controlled study uses one disclosed CPU/GPU server configuration and four frameworks; specific control-core demand, pool widths, and harvesting thresholds are empirical operating points rather than portable constants.
More importantly, the evidence measures infrastructure behavior. It does not establish agent answer quality, governance correctness, security isolation, or business success. Better throughput cannot be used to justify weaker trust boundaries.
Future work
The next research questions are practical: what minimum telemetry can reliably classify control, runner, and inference phases; what online signal can detect a CORAL-like regime before tail latency collapses; how tenant, credential, and business-priority constraints should restrict otherwise efficient collocation; and what reactive policy works when a model chooses the next tool dynamically.
Visualization note
The visual separates Role Classifier, Control Pool, Runner Pool, Inference Pool, an Adaptive Reclaim Loop, and an independent Trust Gate. The retreat arrow represents reversibility and does not encode any fixed threshold or unsupported performance number.
Evidence and references
- Research Object — Role-Aware Heterogeneous Agent Resource Plane: the sole analytical input, including harmful operating points, uncertainty, counter-evidence, and engineering impact.
- Reading Result — Agentic workflow server architecture: the evidence boundary and provenance record declared by the Research Object; Production did not re-analyze this file.