AGOCS Framework: Simulator & Governance

• AGOCS Framework is a dual-purpose model that serves as both a high-fidelity cloud simulator and a template for agentic governance and operational design.
• The simulator component accurately replays Google Cluster Data using modular, event-driven design to support research in scheduling, load balancing, and fault handling.
• Its governance extensions offer structured oversight and cooperative optimization through multi-agent systems, enhancing traceability, compliance, and system control.

Searching arXiv for papers mentioning AGOCS and closely related “AGOCS-style” frameworks. The expression AGOCS Framework is used in more than one way across the cited literature. Its most explicit and concrete usage denotes AGOCS — Accurate Google Cloud Simulator, a high-fidelity, trace-driven simulator of Google-style clusters built around Google Cluster Data and designed for desktop-scale research on scheduling, load balancing, and related infrastructure questions (Sliwko et al., 30 Sep 2025). In a broader interpretive sense, several later works describe “AGOCS-style” frameworks for agentic governance, project specification, and operational design, including COMPASS, the Agentic Automation Canvas, and the Agricultural ODD Framework; these works do not define AGOCS explicitly, but they are presented as suitable templates or pillars for such a framework (Jean-Sébastien et al., 11 Mar 2026, Lobentanzer, 16 Feb 2026, Felske et al., 4 Nov 2025). A further interpretive mapping treats the cooperative group optimization system as an AGOCS in the sense of a multi-agent optimization-and-control architecture (Xie et al., 2018).

1. Terminological scope and major usages

Within the cited corpus, the label has one explicit meaning and several analogical extensions. The explicit meaning is Accurate Google Cloud Simulator, an open-source, Scala/Akka framework for replaying and simulating Google cluster workloads at high fidelity (Sliwko et al., 30 Sep 2025). The analogical usages arise when later papers describe governance, oversight, or operational-design mechanisms as the kind of framework an “AGOCS-style” system would require.

Usage	Source	Core object
AGOCS — Accurate Google Cloud Simulator	(Sliwko et al., 30 Sep 2025)	High-fidelity cloud workload simulator
AGOCS framework used with GCD traces and ML	(Sliwko, 22 Sep 2025)	Data-generation and labeling infrastructure for workload-allocation prediction
AGOCS-style governance layer	(Jean-Sébastien et al., 11 Mar 2026)	COMPASS multi-agent oversight architecture
AGOCS-style specification backbone	(Lobentanzer, 16 Feb 2026)	Agentic Automation Canvas metadata schema
AGOCS-type ODD pillar	(Felske et al., 4 Nov 2025)	Agricultural ODD description, 7-Layer Model, verification loop
AGOCS as optimization-and-control interpretation	(Xie et al., 2018)	Cooperative group optimization system

This distribution suggests two distinct families of meaning. One is infrastructural and simulation-oriented, centered on cloud workload replay and scheduling experimentation. The other is architectural and governance-oriented, centered on explicit control layers, semantic specifications, and verification processes for autonomous or agentic systems.

2. AGOCS as Accurate Google Cloud Simulator

In its explicit sense, AGOCS is a high-fidelity cloud workload simulator built specifically around the publicly available Google Cluster Data traces from May 2011, covering a 12.5K-node Google cluster over a full month (Sliwko et al., 30 Sep 2025). Its stated purpose is to simulate a real, large cloud cluster with realistic workloads and fine-grained resource behavior on an ordinary desktop machine, while remaining detailed enough for low-level research such as scheduling, load balancing, and fault handling.

The simulator is organized as a modular, event-driven framework. Five parser actors ingest the principal Google trace families: machine_events, machine_attributes, task_events, task_constraints, and task_usage. A central WorkloadGenerator actor collects time-appropriate events every five seconds of simulated time, sorts them by timestamp, and applies them to a shared ContextData structure. That state is implemented with thread-safe, lock-free TrieMap and is intended to support concurrent access by schedulers, statistics collectors, and monitoring components (Sliwko et al., 30 Sep 2025).

AGOCS models state changes through immutable WorkloadEvent instances. The event vocabulary includes task addition, task-resource updates, task-usage updates, task-constraint updates, task removal, node addition, node total-resource updates, node-attribute addition and removal, and node removal. This event-centric design preserves the timestamped structure of the original traces while allowing the simulator to ignore Google’s proprietary scheduler decisions and substitute user-provided scheduling logic instead (Sliwko et al., 30 Sep 2025).

The framework distinguishes requested resources from actual used resources. Requested CPU, memory, and disk values are reconstructed from submission and update events, whereas actual CPU usage, memory usage, disk space, disk I/O, and other secondary parameters are reconstructed from task_usage. This separation is central to the framework’s fidelity claim, because it supports realistic modeling of over-provisioning, resource waste, idleness, overload, and dynamic utilization patterns that are difficult to capture with synthetic or coarse-grained simulators (Sliwko et al., 30 Sep 2025).

3. Replay mode, simulation mode, and workload-allocation analysis

A subsequent study extends AGOCS from a replay/simulation environment into a data-generation framework for machine-learning-based workload allocation (Sliwko, 22 Sep 2025). That paper identifies two core modes. In Replay Mode, AGOCS replays recorded scheduling decisions from the traces and is used to collect data-level statistics. In Simulation Mode, it ignores those decisions and uses user-provided scheduling functions to experiment with new scheduling heuristics or meta-heuristics.

For the workload-allocation study, AGOCS was modified to generate outputs for all new tasks together with their corresponding constraint operators, and to output the list of nodes, including their attributes, at five-minute intervals of simulation time (Sliwko, 22 Sep 2025). The framework records the current set of task constraints, snapshots node attributes, compacts multiple operators on the same attribute, discards invalid combinations, and computes the set of nodes whose attributes satisfy all task constraints. In the paper’s conceptual notation, if $\mathcal{N}$ is the node set and $C(t)$ is the constraint set for task $t$, then the suitable-node set is

$$S(t) = \{ n \in \mathcal{N} : n \text{ satisfies all } c \in C(t) \}.$$

This count is then transformed into workload-allocation classes. The framework uses 26 groups (A–Z) based on $|S(t)|$, with special emphasis on tasks that have exactly one suitable node, or only a small fraction of the cluster available (Sliwko, 22 Sep 2025).

Group	Criterion	Interpretation
A	$|S(t)| = 1$	Exactly one suitable node
C	$501 \le |S(t)| \le 1000$	Hard but not extreme constraints
Z	$|S(t)| > 12000$	Effectively any node

The same study reports that the final hard-voting ensemble—combining an Artificial Neural Network, Ridge Regression, and Linear SVM with SGD—achieved 98% accuracy and a 1.5–1.8% misclassification rate for tasks with a single suitable node (Sliwko, 22 Sep 2025). The intended operational use is not a full AGOCS-based online scheduler, but a predictive front end that estimates allocation difficulty from constraint operators alone, so that a scheduler can reserve more search time or more sophisticated heuristics for rare-node tasks.

4. Data model, implementation, and performance characteristics

AGOCS is built around Google Cluster Data from May 2011, approximately 12.5K nodes, roughly 41 GB compressed and 191 GB uncompressed, with the main logs stored in the clusterdata-2011-2 bucket (Sliwko et al., 30 Sep 2025). The simulator does not preload all trace data into memory. Instead, each parser maintains an in-memory event buffer holding up to 30 minutes of simulated time ahead of the current simulation time and at most 1,000,000 events. This streaming strategy is a deliberate design choice to keep the framework usable on a desktop or laptop.

The implementation uses Scala, Akka actors, Scala Futures, and concurrent data structures. The framework is described as more I/O-bound than CPU-bound, because disk throughput, not arithmetic throughput, is the principal bottleneck during large trace replay (Sliwko et al., 30 Sep 2025). The paper reports that a full month-long simulation can run on the test MacBook in about 9 hours with a 75× speed factor, corresponding to approximately 21.22 GB/h of trace data processed, and that after warm-up CPU usage stabilizes around 10–15%.

The authors compare AGOCS with CloudSim. For small scenarios, CloudSim is faster. As scenario size grows, however, CloudSim’s runtime increases more steeply, whereas AGOCS’s runtime grows more gently after initial pre-loading. The interpretation given in the paper is that CloudSim is single-threaded and bottlenecked by ArrayList.removeAll, while AGOCS benefits from multi-threading, parallel parsing, and streaming execution (Sliwko et al., 30 Sep 2025).

The framework is also explicitly presented as extensible. New schedulers can attach as clients of the workload generator, and the MASB project already includes Greedy, Tabu Search, Simulated Annealing, and four Genetic Algorithm variants. New traces can, in principle, be supported by adding modular parser classes; the authors estimate that an experienced developer could add a new workload trace format in roughly a week (Sliwko et al., 30 Sep 2025).

5. AGOCS-style governance and machine-readable specification

In a different line of work, COMPASS is described as “exactly the kind of ‘agentic governance’ layer that an ‘AGOCS Framework’ would be” (Jean-Sébastien et al., 11 Mar 2026). COMPASS is a multi-agent governance and oversight layer for LLM-based agents. It intercepts agent actions before execution, evaluates them along four normative dimensions—Digital sovereignty, Carbon-aware computing, AI regulatory compliance, and AI ethics—grounds each evaluation in external authoritative documents using RAG, and uses an LLM-as-a-judge to produce a quantitative score in $[0,1]$ and a short structured explanation. Architecturally, it consists of an Orchestrator and four specialized sub-agents, and governance is described as “governance by design” because any concrete application agent inherits from the orchestrator and therefore cannot bypass the governance layer (Jean-Sébastien et al., 11 Mar 2026).

The same broader interpretive usage appears in the Agentic Automation Canvas (AAC). The AAC paper states that it never mentions an “AGOCS Framework” explicitly, but that the AAC is exactly the kind of structured, machine-readable framework one would want as the backbone of an AGOCS-style approach (Lobentanzer, 16 Feb 2026). AAC is a prospective design, communication, governance, and documentation framework implemented as a semantic-web-compatible metadata schema. It captures six dimensions of an automation project: definition and scope, user expectations with quantified benefit metrics, developer feasibility assessments, governance staging, data access and sensitivity, and outcomes. The framework validates data with JSON Schema, maps it to standard ontologies such as Schema.org, W3C DCAT, W3C PROV-O, P-Plan, FRAPO, and DUO, and exports completed canvases as FAIR-compliant RO-Crates (Lobentanzer, 16 Feb 2026).

Taken together, these two works define an AGOCS-style layer that is neither a simulator nor a scheduler. Instead, it is a governing middle layer or a domain-agnostic contract + governance layer around autonomous or agentic systems. This suggests a broader meaning of AGOCS centered on explicit goals, oversight, control surfaces, compliance hooks, and auditable outcomes rather than on infrastructure replay alone.

6. Operational-design and cooperative-optimization extensions

A further extension appears in the Agricultural ODD Framework, which is presented as almost exactly what would be wanted as the “ODD pillar” inside a broader AGOCS-type framework for autonomous agriculture (Felske et al., 4 Nov 2025). The Ag-ODD Framework has three core elements: an Ag-ODD description concept, a 7-Layer Model extended from the PEGASUS 6-Layer Model by adding a process layer, and an iterative verification process that reconciles the Ag-ODD against its corresponding logical scenarios. A distinctive concept is the Condition-Dependent Variable (CDV), defined by a start attribute, triggering condition(s), and end attribute, so that field-level agricultural processes can be represented as structured transformations of environmental state (Felske et al., 4 Nov 2025). In this reading, an AGOCS framework acquires a formal ODD boundary model, layered world modeling, and a scenario-based verification loop.

An even older but conceptually related interpretation comes from “A Cooperative Group Optimization System”, whose accompanying mapping explicitly states that an AGOCS—expanded there as Agent/Cooperative Group Optimization and Control System—is almost exactly what the CGO system already is (Xie et al., 2018). The system is defined by the triple

$$\langle \text{Framework}, \text{Toolbox}, \text{Script} \rangle,$$

and organizes cooperation through individual memory $C(t)$0, social memory $C(t)$1, a facilitator, and a portfolio of embedded search heuristics (ESHs). In that interpretation, AGOCS denotes a reusable cooperative multi-agent optimization architecture in which heterogeneous heuristics are composed by a script-defined memory protocol and an updatable graph (Xie et al., 2018).

Across these extensions, a common structural theme emerges. Whether the object is a cloud simulator, a governance layer, an ODD framework, or a cooperative optimizer, the AGOCS label or AGOCS-style mapping consistently denotes a structured orchestration framework with explicit state representations, modular components, controlled interfaces, and a mechanism for traceability or explainability. The precise content differs sharply by domain, but the recurring architectural pattern is one of compositional control over complex autonomous behavior.