Architecture
observe · legal_actions · executeHTTP · JSON
- Validates against the manifest
- Keeps per-entity memory
- Holds provider keys
- Debug console
provider API
Reference: OpenAI Decisions
Inside the game
Section titled “Inside the game”The game side has three layers. Only the middle one is game-specific code you write.
Your game stays as it is: entities, rules, physics and the native AI. Each entity gets one call in its update loop:
if A2G.execute(self, delta): # true: A2G controls this entity this frame return# otherwise run the original state machineAdapter and manifest — written by the game developer. The manifest declares the world, entity types, observation fields and actions. The adapter implements three functions per entity type:
| Function | Returns |
|---|---|
observe(entity) |
The observation fields declared in the manifest |
legal_actions(entity) |
Actions the game allows right now (rules, cooldowns, visibility) |
execute(entity, action) |
Performs the action through existing game code; may refuse |
Engine SDK — provided by A2G, one per engine. It loads the manifest, opens the session, decides which entities need a decision, batches decide requests without blocking frames, tracks epochs and TTLs, and sends reports and telemetry. See Godot SDK.
Local policy (proposed) — a small model file trained on the service’s decisions. The SDK evaluates it in-process, so a game can make decisions without the network and ship without the service. See Policy format.
Decision service
Section titled “Decision service”A separate process that owns everything AI-related: validation against the manifest, per-entity memory, provider calls and credentials, bounded telemetry and a debug console. Proposed: a persistent decision log and the training of local policies. See Reference service.
Model provider
Section titled “Model provider”The model API that makes the typed choice. The service isolates the game from provider details, so the provider can change without touching the game.
Trust boundaries
Section titled “Trust boundaries”- The game trusts nothing it receives: it checks the epoch, that the action is one it offered and that the decision is still fresh.
- The service trusts nothing from the game: it validates every field against the manifest and keeps only scalar telemetry.
- Provider keys never leave the service.