@<agent-name> not working as expected.

[samanhg47]

I'm fairly certain I should be able to have sisyphus delegate to specific agents by @ing their names in the prompt, but recently it gets confused when I do. I'll prompt it with something like "Have @ do " and it responds with:

Limitation: Can't invoke @<agent> directly
The task() tool's subagent_type only supports explore, librarian, oracle, metis, momus — not custom agents.
I can delegate to a quick category task loaded with <skill-name> skill, which achieves the same result.
Or I handle it directly since it's a single-file edit with clear requirements.

This has happened multiple times recently. Not the exact same response, but it always mentions something similar to "The task() tool's subagent_type only supports explore, librarian, oracle, metis, momus — not custom agents." Does this warrant an issue or am I using the tool improperly?

[webrcost4]

This sounds less like user error and more like a capability / routing regression or guardrail kicking in.

From what you’re describing, the system clearly recognizes the @agent intent, but then falls back to a constrained execution path where task() only allows the built-in subagent_type values (explore, librarian, oracle, metis, momus). That usually means one of a few things:

1. The @mention parsing is no longer being mapped to a valid internal agent identifier
2. Custom agents aren’t being registered (or exposed) in the current session/context
3. A safety or capability layer is intercepting delegation and forcing it into the default task() schema

A few things worth checking:

• Are those agents still defined and loaded in your current workspace/session?
• Did anything change in how agents are declared (naming, scoping, config)?
• Does it work if you explicitly invoke the equivalent skill instead of using @mentions?
• Is this happening across all prompts or only certain task shapes (e.g. single-file edits vs multi-step tasks)?

If this is a regression, I’d expect:

• @mentions used to resolve → now consistently fall back to task()
• The model explains the limitation instead of attempting best-effort routing

Given that it’s happening repeatedly and not just on malformed prompts, I’d lean toward this being worth opening an issue — especially if you can include:

• a minimal repro prompt
• expected vs actual behavior
• whether it worked in a previous version

That would help determine if it’s a breaking change in agent delegation or an intentional restriction that just isn’t clearly documented.

[samanhg47]

@webrcost4 I'm very new to the plugin.

Are those agents still defined and loaded in your current workspace/session?

The configured agents seem to be loaded properly, as when I type @, they appear as options in the help text.

Did anything change in how agents are declared (naming, scoping, config)?

I'm fairly new to opencode, so I've only used v1.2.24. I simply followed the specs when I set up my global env:

|- agents/
| |- <agent>.md
|- skills/
| |- <skill>
| | |- SKILL.md

both agents and skills are registering in the TUI text completion popups

Does it work if you explicitly invoke the equivalent skill instead of using @mentions?

This, I believe is the result of a mistake in understanding by the system. It's equivocating agent definitions with the skills they internally invoke which isn't necessarily accurate because of prompt engineering. But yes, kind of. I can preface my true prompt to Sisyphus with the agent definition and probably get the same or a similar result.

Is this happening across all prompts or only certain task shapes (e.g. single-file edits vs multi-step tasks)?

Yes, this is happening for all prompts, both multi-step and simple

I hope that provides more context.