framework: key in YAML picks which execution backend runs your agents — but the rules differ between agents.yaml and workflow YAML.
framework: selects the backend that runs the workflow.
Quick Start
Which file uses which?
| YAML shape | Engine | framework: choices |
|---|---|---|
roles: / topic: (agents.yaml) | AgentsGenerator + registry | Any registered adapter (crewai, praisonai, autogen, plus entry-point plugins) |
steps: + workflow: (workflow YAML) | Native Workflow engine | Any adapter whose SUPPORTS_WORKFLOW = True (built-in praisonai qualifies) |
type: job / type: hybrid (workflow YAML) | Native Workflow engine | Any adapter whose SUPPORTS_WORKFLOW = True (built-in praisonai qualifies) |
SUPPORTS_WORKFLOW = True. The built-in praisonai adapter has it. Third-party adapters opt in by setting the flag on their subclass — see Capability Flags.
If framework: is omitted, agents.yaml defaults via FrameworkAdapterRegistry.pick_default() and workflow YAML defaults to praisonai.
What you’ll see if the framework isn’t workflow-capable
Selecting a framework whose adapter hasSUPPORTS_WORKFLOW = False raises:
SUPPORTS_WORKFLOW flag is True, so it grows as you install workflow-capable plugins.
Make a custom framework workflow-capable
SetSUPPORTS_WORKFLOW = True on your adapter subclass to accept workflow YAML dispatch:
myframework is accepted in workflow YAML and appears in the “Frameworks supporting workflow execution” list. See Capability Flags.
What to do
Programmatic check
framework_from_config({}) returns "praisonai" (safe default). framework_from_config({"framework": "CrewAI"}) returns "crewai" (lowercased before validation).
validate_workflow_framework() reads the adapter’s SUPPORTS_WORKFLOW flag from the default registry. Pass registry= to test against an isolated registry:
How It Works
Best Practices
Use agents.yaml for multi-framework work
Use agents.yaml for multi-framework work
If you need CrewAI, AutoGen, or a custom framework, write your config as
roles:/topic: agents.yaml. The framework: key there accepts any registered adapter.Omit framework: in workflow YAML
Omit framework: in workflow YAML
The default is
praisonai, so you can omit the framework: key entirely in workflow YAML. This avoids accidentally setting an unsupported value.Validate early in custom code
Validate early in custom code
Call
validate_workflow_framework(fw) immediately after parsing config if you’re building tooling around workflow YAML. It raises ValueError with an actionable message before any execution starts. Pass registry= to validate against an isolated registry in tests.Set SUPPORTS_WORKFLOW to enable workflow YAML
Set SUPPORTS_WORKFLOW to enable workflow YAML
A custom adapter cannot run workflow YAML until it sets
SUPPORTS_WORKFLOW = True (class-level). Leaving it False keeps the adapter agents.yaml-only and blocks workflow dispatch with a clear error.Related
Add new execution backends via Python entry points
Full workflow YAML reference

