Bug Description
After upgrading to the latest CAO (relevant commit is actually 10953b9, merged March 25), assign no longer correctly recognizes AIM-installed kiro-cli agents. Instead of launching agents via kiro-cli with full tools and skills, it falls back to a generic provider.
Steps to Reproduce
- Install agents via AIM:
aim agents install ZhakaidaPersonalAgents
- This creates directories like
~/.kiro/agents/librarian/ containing agent-spec.json (not .md files)
- Start a CAO session and use
assign to dispatch work to an agent (e.g., librarian)
- The agent could not be launched - not found in CAO profile
Expected Behavior
assign should discover AIM-installed agents in ~/.kiro/agents/{name}/ and launch them via kiro-cli --agent {name}, which picks up the full agent-spec.json configuration including tools, skills, and context.
Actual Behavior
assign does not find the agent profile and either falls back to a built-in/generic profile or fails. The agent launches without the correct provider configuration.
Root Cause
The new _scan_directory() in agent_profiles.py (introduced in #108) only looks for:
.md files (flat): {dir}/{name}.md
- Directory-style with
agent.md: {dir}/{name}/agent.md
But AIM-installed kiro-cli agents use agent-spec.json inside subdirectories (e.g., ~/.kiro/agents/librarian/agent-spec.json). The discovery logic never matches these, so load_agent_profile() falls through to the built-in store.
Workaround
Create a minimal .md file in the local agent store:
mkdir -p ~/.aws/cli-agent-orchestrator/agent-store
cat > ~/.aws/cli-agent-orchestrator/agent-store/librarian.md << EOF
---
name: librarian
description: librarian agent
---
EOF
This makes load_agent_profile() match at step 1 (local store), and assign then correctly uses kiro-cli to start the agent with all tools and skills.
Possible Fix
When scanning provider directories (especially kiro_cli), also check for agent-spec.json inside subdirectories. For kiro-cli agents, the profile does not need to contain a system prompt — CAO just needs to know the agent exists and should be launched via kiro-cli --agent {name}.
Environment
- CAO version: latest (post-commit 10953b9)
- Agent installation: AIM (
aim agents install)
- Provider: kiro_cli
- OS: macOS
Bug Description
After upgrading to the latest CAO (relevant commit is actually 10953b9, merged March 25),
assignno longer correctly recognizes AIM-installed kiro-cli agents. Instead of launching agents viakiro-cliwith full tools and skills, it falls back to a generic provider.Steps to Reproduce
aim agents install ZhakaidaPersonalAgents~/.kiro/agents/librarian/containingagent-spec.json(not.mdfiles)assignto dispatch work to an agent (e.g.,librarian)Expected Behavior
assignshould discover AIM-installed agents in~/.kiro/agents/{name}/and launch them viakiro-cli --agent {name}, which picks up the full agent-spec.json configuration including tools, skills, and context.Actual Behavior
assigndoes not find the agent profile and either falls back to a built-in/generic profile or fails. The agent launches without the correct provider configuration.Root Cause
The new
_scan_directory()inagent_profiles.py(introduced in #108) only looks for:.mdfiles (flat):{dir}/{name}.mdagent.md:{dir}/{name}/agent.mdBut AIM-installed kiro-cli agents use
agent-spec.jsoninside subdirectories (e.g.,~/.kiro/agents/librarian/agent-spec.json). The discovery logic never matches these, soload_agent_profile()falls through to the built-in store.Workaround
Create a minimal
.mdfile in the local agent store:This makes
load_agent_profile()match at step 1 (local store), andassignthen correctly useskiro-clito start the agent with all tools and skills.Possible Fix
When scanning provider directories (especially
kiro_cli), also check foragent-spec.jsoninside subdirectories. For kiro-cli agents, the profile does not need to contain a system prompt — CAO just needs to know the agent exists and should be launched viakiro-cli --agent {name}.Environment
aim agents install)