Feature request: Add kiro agent kind for Kiro CLI 2.0

[craigedmunds]

Summary

Add a new kiro agent kind to sortie, enabling Kiro CLI (formerly Amazon Q Developer CLI) as an agent backend alongside claude-code, copilot-cli, and codex.

Why Kiro CLI

Kiro CLI has strong alignment with sortie's existing architecture:

• Headless mode via kiro-cli chat --no-interactive "prompt" — maps directly to sortie's subprocess-per-turn model used by claude-code and copilot-cli
• Declarative agent config in .kiro/agents/*.json with prompt, model, tools, resources, and hooks — could map to sortie's passthrough config block
• Tool permission flags (--trust-all-tools, --trust-tools=read,grep,write) — similar to claude-code's permission_mode
• MCP support natively — consistent with sortie's tool ecosystem
• Multi-model support — Claude frontier models, with the model selectable per-agent config
• Agent selection via kiro-cli --agent <name> flag

Proposed Design

Workflow config

agent:
  kind: kiro
  command: kiro-cli

kiro:
  model: claude-sonnet-4
  trust_tools: "read,grep,write,edit"    # or trust_all_tools: true
  agent: my-custom-agent                  # optional: select a .kiro/agents/ agent
  require_mcp_startup: false

Adapter implementation

Following the existing pattern in internal/agent/:

1. internal/agent/kiro/kiro.go — AgentAdapter implementation using the subprocess-per-turn model (like claude-code)
2. internal/agent/kiro/command.go — Build CLI args: kiro-cli chat --no-interactive --trust-tools=<tools> "prompt"
3. internal/agent/kiro/parse.go — Parse Kiro CLI stdout into domain.AgentEvent structs

Registration:

func init() {
    registry.Agents.RegisterWithMeta("kiro", NewKiroAdapter, registry.AgentMeta{
        RequiresCommand: true,
    })
}

Open questions

1. Output format: Does Kiro CLI support structured output (JSONL/JSON) in headless mode, or is it plain text only? Sortie's existing adapters rely on JSONL event streams from stdout. If Kiro only emits plain text, the parser would need a different approach.
2. Session continuity: Does kiro-cli support resuming sessions across turns (like claude --resume)? This affects whether sortie can maintain multi-turn conversations.
3. Exit codes: What exit codes does kiro-cli use for success/failure/timeout?
4. Token usage reporting: Does Kiro CLI report token usage in its output? Sortie emits EventTokenUsage events for cost tracking.

Context

We use sortie to orchestrate agent-driven workflows (CI/CD, code generation, wiki updates) and would like to offer Kiro CLI as an alternative backend. Happy to contribute a PR if there's interest and the open questions above can be resolved.

[sergeyklay]

Thanks. This is a good fit for the adapter pattern and I want to implement it myself. There will be gotchas and surprises, even on a quick look, but that's what makes it interesting.

Existing adapters in internal/agent/ are claude, codex, copilot (no -cli suffix). The new one would be kiro, with kind kiro in WORKFLOW.md.

On your open questions, with a few additions:

1. AFAIK headless --no-interactive emits plain text/markdown, not JSONL. The --format json flag exists only for meta commands (--list-models, settings list, diagnostic). The existing Claude Code adapter relies on a structured event stream from stdout; the Kiro adapter has to reconstruct events from text, which means coarser granularity. Tool calls, intermediate steps, and file edits won't surface as discrete events. The adapter likely emits one EventAgentMessage per turn instead of a fine-grained stream.
2. Supported --resume, --resume-id, --list-sessions. Maps cleanly to multi-turn flow.
3. Documented in the Kiro CLI reference. Standard pattern.
4. Not in headless stdout (/usag is interactive-only). This breaks EventTokenUsage and budget tracking via max_budget_usd. A time-based budget per run is the realistic fallback.

This is all from a surface read, so I'm likely off on details. Before any code, the first step is a deeper investigation and an adapter-notes document in the same shape as the existing claude-code-adapter-notes.md, codex-adapter-notes.md, and copilot-adapter-notes.md in docs/. That document becomes the reference for the implementation, not the issue body.

As for timing - my current focus is the OpenCode adapter and the Linear tracker adapter. I can start on Kiro in about a week and a half, with delivery in 2-3 weeks total, barring anything unexpected.

If the community wants it sooner, I can write up an Adapter Authoring Guide on https://docs.sortie-ai.com/ covering the architecture, conventions, and what a new agent adapter has to implement. That would let anyone willing to take a swing at it earlier have what they need.

Let me know which path makes sense.