AACWorkflow Docs

AI coding tools matrix

AACWorkflow supports 12 AI coding tools; they implement the same interface, but the capability details diverge significantly.

AACWorkflow ships with built-in support for 12 AI coding tools. They all implement the same interface — queue, dispatch, execute, return results — so you can drive any of them from the same AACWorkflow board. But the capability details diverge significantly: whether session resumption actually works, whether MCP is supported, where skill files live, how models are selected. This page is the full matrix.

For guidance on picking a tool when creating an agent, see Creating and configuring agents.

Capability matrix

ToolVendorSession resumptionMCPSkill injection pathModel selection
AntigravityGoogle✅ (--conversation <id>).agents/skills/Managed inside the Antigravity CLI itself
Claude CodeAnthropic.claude/skills/Static + flag
CodexOpenAI⚠️ Code exists but unreachable$CODEX_HOME/skills/Static
CopilotGitHub.github/skills/Static (determined by account entitlement)
CursorAnysphere⚠️ Code exists but unusable.cursor/skills/Dynamic discovery
GeminiGoogle.agent_context/skills/Static
HermesNous Research.agent_context/skills/ (fallback)Dynamic discovery
KimiMoonshot.kimi/skills/Dynamic discovery
Kiro CLIAmazon.kiro/skills/Dynamic discovery
OpenCodeSST.opencode/skills/Dynamic discovery
OpenClawOpen source.agent_context/skills/ (fallback)Bound to the agent, can't be switched per task
PiInflection AI✅ (session is a file path).pi/skills/Dynamic discovery

What each tool is for

Antigravity

From Google. CLI binary name is agy. Pairs with Google's Antigravity service and ships with a Gemini-backed default model. Session resumption works via --conversation <id>; the daemon captures the conversation UUID from the CLI's log file because stdout is plain text rather than a structured event stream. There is no --model flag — model selection lives inside the Antigravity CLI settings, so AACWorkflow disables the per-agent model picker for this provider. Skills land in .agents/skills/ (the CLI inherits Gemini CLI's workspace skill layout — see Antigravity migration docs).

Claude Code

From Anthropic. First choice for new users — the most complete feature set: session resumption actually works, it reads MCP configuration, and it supports fine-tuning flags like --max-turns and --append-system-prompt. Requires an Anthropic API key.

Codex

From OpenAI. Uses JSON-RPC 2.0, has stronger statefulness, and a finer-grained approve mechanism (manual approval for exec_command and patch_apply). MCP config is materialized into the per-task $CODEX_HOME/config.toml. Session resumption code exists but is currently unreachable — if you need resume, pick Claude Code or one of the ACP family.

Copilot

From GitHub. Model routing goes through your GitHub account entitlement — the tool doesn't select a model itself; GitHub decides which model you get. Placing skills in .github/skills/ is GitHub CLI's native discovery mechanism.

Cursor

From Anysphere, the CLI counterpart to the Cursor editor. Session resumption code exists but doesn't actually work — the Cursor CLI event stream doesn't return a session ID, so any resume value you pass is always invalid. If you need resume, pick something else.

Gemini

From Google, supports the Gemini 2.5 and 3 series. No session resumption and no MCP — suitable for one-shot tasks that don't need long context memory.

Hermes

From Nous Research. Uses the ACP protocol (shares a transport with Kimi). Session resumption works, and MCP config is passed through ACP mcpServers. But the skill injection path is the generic fallback (.agent_context/skills/), not a dedicated one — if the Hermes CLI itself doesn't read this path, skills may not take effect. Verify by testing.

Kimi

From Moonshot, aimed at the Chinese market. Shares the ACP protocol with Hermes, including MCP config through ACP mcpServers, but the skill path .kimi/skills/ is Kimi CLI's native discovery mechanism — different from Hermes's fallback.

Kiro CLI

From Amazon. Uses ACP over stdio via kiro-cli acp. Session resumption works through ACP session/load, MCP config is passed through ACP mcpServers, model selection works through session/set_model, and skills are copied into .kiro/skills/ for native project-level discovery.

OpenCode

From SST, open source. Dynamically discovers available models (scans the CLI's configuration file). Session resumption works, and it consumes the agent's mcp_config field — AACWorkflow injects it inline through the OPENCODE_CONFIG_CONTENT environment variable, so the agent's MCP servers reach OpenCode without writing anything into the task workdir's opencode.json (the agent or the user keep ownership of that file). Suitable for tinkerers who want to customize their model catalog.

OpenClaw

Open-source project, a CLI agent orchestrator. MCP config is materialized through AACWorkflow's per-task OpenClaw config wrapper. Model is bound at the agent layer (openclaw agents add --model) — it can't be overridden per task. Configuration is strictly controlled: users can't pass --model or --system-prompt; the agent-registration config decides.

Pi

From Inflection AI, minimalist. Session resumption is unusual — the session ID is a file path on disk (~/.pi/...) rather than a string ID. In other tools, the resume id is a string returned by the CLI; in Pi, the resume id is the session file itself.

Session resumption: who really supports it

The session resumption mechanism is covered in Tasks. Here's the exact current state per tool:

StatusToolsMeaning
✅ Really worksAntigravity, Claude Code, Copilot, Hermes, Kimi, Kiro CLI, OpenCode, OpenClaw, PiPass the resume id and it continues from the previous context
⚠️ Code exists but unreachableCodex, CursorResume paths exist in the code but aren't actually reached (Codex silently falls back; Cursor doesn't return session id) — treat as unsupported
❌ NoneGeminiThe CLI has no resume mechanism

For your decision: if your workflow needs agents to preserve context across tasks (failure retries, manual reruns, conversational iteration), pick only from the ✅ row.

MCP configuration: provider-specific support

Of the 12 tools, seven consume mcp_config: Claude Code, Codex, Hermes, Kimi, Kiro CLI, OpenCode, and OpenClaw. The other five accept the field but ignore it — no error, no warning, the config just has no effect.

The runtime paths are provider-specific: Claude Code receives it through --mcp-config paired with --strict-mcp-config; Codex writes a daemon-managed mcp_servers block into the per-task $CODEX_HOME/config.toml; Hermes, Kimi, and Kiro CLI receive ACP mcpServers; OpenCode receives inline config through OPENCODE_CONFIG_CONTENT; OpenClaw receives mcp.servers through AACWorkflow's per-task config wrapper. OpenCode's path does not rewrite the project's opencode.json.

If you set mcp_config in an agent configuration but pick a tool not marked ✅ in the MCP column, your MCP servers have no effect on that agent. MCP integration is provider-specific.

Where skill files go

Each tool uses its own skill discovery path. Before a task runs, the AACWorkflow daemon copies the workspace's skill files into the corresponding path:

ToolPathNative discovery?
Claude Code.claude/skills/✅ Native
Codex$CODEX_HOME/skills/✅ Native
Copilot.github/skills/✅ Native
Cursor.cursor/skills/✅ Native
Kimi.kimi/skills/✅ Native
Kiro CLI.kiro/skills/✅ Native
OpenCode.opencode/skills/✅ Native
Pi.pi/skills/✅ Native
Antigravity.agents/skills/✅ Native (inherits Gemini CLI's workspace layout — see Antigravity docs)
Gemini.agent_context/skills/⚠️ Generic fallback
Hermes.agent_context/skills/⚠️ Generic fallback
OpenClaw.agent_context/skills/⚠️ Generic fallback

Whether a fallback-path tool actually reads this directory depends on the tool's own documentation — no guarantees. If your skills aren't taking effect for Gemini / Hermes / OpenClaw, check this first.

For creating and using skills, see Skills.

Next