GAAI (Governed Agentic AI Infrastructure) is a governance framework for AI programming tools, with the goal of turning AI programming tools into a reliable agentic software delivery system. It takes the form of a .gaai/ folder placed into any Git project, consisting of Markdown, YAML, and bash, and includes a vendored Python runtime and a small number of Node helper scripts. The official emphasis: no SDK, no packages to install, no external services, and nothing is pulled during installation.
Purpose and the problems it solves AI programming tools are fast, but without governance, speed brings drift: agents touch code they should not change, forget decisions from previous sessions, and deliver features that cannot be verified against acceptance criteria. GAAI fills in the missing governance layer for such tools, and is suited to developers who already have a clear understanding of the product—independent founders, senior engineers, and small teams who know what they want to build and need an agent that executes reliably without going off track.
Main capabilities: the dual tracks of Discovery and Delivery Discovery: converse with the Discovery Agent in the current session to clarify what to build; the output is a Story in the backlog with acceptance criteria. Discovery only reasons; it does not execute. Delivery: always runs in an isolated process. /gaai-daemon starts the Delivery Daemon, running a separate claude -p session for each Story via tmux—fully independent operating system processes, with no Discovery residue and no conversation history cross-talk. The Delivery Agent orchestrates dedicated sub-agents (Planning, Implementation, QA) for each Story. It can be viewed in real time via tmux attach. The official claim: no improvisation, no scope drift, no context pollution. The backlog is the contract between the two; anything not in the backlog will not be built.
How to use Installation: download from GitHub, copy the .gaai/ folder into the project root, then tell the AI tool: "Read .gaai/core/README.md and bootstrap this project." The installer will copy .gaai/ andYour tool deploys the corresponding adapter (CLAUDE.md, AGENTS.md, or .cursor/rules/). Two slash commands: /gaai-deliver delivers a single Story in the current session; /gaai-daemon starts the background daemon, which polls the backlog and delivers multiple Stories in parallel (each in its own tmux session). The Delivery Daemon requires a git repository and a staging branch, polls refined Stories, launches parallel Claude Code or Codex sessions in tmux (default 3 slots, configurable), coordinates across devices via git push, monitors health status, retries failures, and archives completed work. It runs in a private tmux server, with the socket bound to a repository digest, so a second checkout cannot join or break the lifecycle. It also provides an on-demand monitoring dashboard. Daemon startup has a strict security contract: daemon-setup.sh and daemon-start.sh are executable files with a #!/bin/bash -p shebang; invoking them with a plain bash interpreter prefix is rejected with entry_authority_invalid; the only alternative is to use an absolute path to a verified Bash with the --noprofile --norc -p arguments. daemon-setup.sh is also the only command that can create or update the dedicated daemon home worktree. At startup the home is verified, and if it is missing, stale, dirty, foreign, or on the wrong branch, startup is refused, with no repair and no fallback to the working checkout. Because the entry point rebuilds a closed configuration allowlist, a shell that has exported variables such as GIT_EDITOR, GIT_CONFIG_COUNT, or PYTHONPATH cannot start the daemon—the official position is that this is a contract, not a defect, and starting from a clean environment is recommended, for example: env -i PATH=/usr/bin:/bin HOME="$HOME" TERM="$TERM" .gaai/core/scripts/daemon-start.sh.
Compatibility and dependencies Discovery and governance work with any AI coding tool; the Delivery workflow is portable to AI programming runtimes that support subagents, and Claude Code is the reference implementation (the daemon uses claude -p, because Claude Code was the first coding agent to expose subagent primitives). The Delivery Daemon explicitly supports two local headless executors: Claude Code CLI (default) and Codex CLI (via GAAI_DAEMON_EXECUTOR=codex). Unknown or unavailable executors stop before governance work begins and produce an actionable error. "No package installation required" is literal and not a claim of zero dependencies: nothing is pulled (PyYAML is vendored in-tree), but the Delivery Daemon requires git, python3, node, and tmux to be in PATH, and the vendored runtime is a binary zipapp rather than readable source. tmux is required rather than optional (3.2 is the nominal floor, but actual capability probing is the admission authority), and there is no Terminal.app or nohup fallback.
Use cases and limitations Applicable: developers who already have product clarity, solo founders, senior engineers, and small teams that need agents to deliver reliably without going off track. Limitations: Discovery is conversational and deliberately lightweight; it helps structure what is already known and does not replace deep product research or team brainstorming; trivial tasks still require a backlog entry (it can be one line, but the gate always exists); the framework depends on agents following the files, with no programmatic enforcement; the repository was recently released under ELv2, and the community is just getting started. Tested environment: macOS (Apple Silicon). Linux and WSL (Windows) are expected to work but have not yet been verified. License: source-available, under the Elastic License 2.0 (ELv2). Author: Frédéric Geens.
