Introduction
Overview
AGS is designed to work on every surface developers use: the terminal, an IDE, a CI pipeline, and AI assistants. The AGS CLI is the single tool that connects all of those surfaces to AGS.
The recording shows moving from services to resources to methods with nothing but the command tree and help pages.
The deterministic layer
Every ags command maps one-to-one to an AGS API endpoint. When you run a command, the CLI makes exactly the network call described by the command name and parameters. There are no hidden side effects and no compound operations that surprise you after the fact. You can review every step before it runs.
Chat interfaces alone are a poor fit for multi-step backend changes. AI is strong at understanding intent and resolving ambiguity, and weak at executing long chains of state changes reliably. The CLI therefore keeps execution deterministic while the assistant handles intent.
Workflows
Workflows are YAML files with typed inputs, ordered steps, and explicit step dependencies. A value produced by one step passes to the next step by reference. Before anything executes, you can run a workflow in dry-run mode to see every call and its inputs. Nothing is applied until you confirm. That means you can set up a whole feature in one reviewed run instead of a chain of portal visits.
See Workflows for the built-in workflows and how to author your own.
AI and the CLI
AI agents can select workflows and fill in the required inputs. The AGS CLI runtime then executes those steps deterministically. The agent handles intent. The CLI handles execution. This separation means the agent cannot accidentally take an undocumented or unexpected action. Skills and assistants sit on top of workflows and handle the language work, never the state changes. The division of labor means the same workflow behaves identically whether a person or an agent invokes it.
For more on this pattern, see the AccelByte blog post "Beyond the Chat Box" by Phil Tossell (June 2026).