Generic subagent dispatch cannot select a named worker profile on Devin

[GodsBoy]

Summary

CE skills dispatch generic subagents for reviewers, scouts, researchers, fixers, and similar workers. On Devin (CLI and Devin Local), run_subagent selects a worker by named profile, not by raw model id. The two built-in profiles are subagent_explore (read-only tools, no exec, no file writes) and subagent_general (full tool set, always inherits the parent model).

The plugin has no configuration surface that maps a generic CE dispatch to a named profile. Any CE worker that needs more than read-only tools already lands on subagent_general, so it runs the parent model at parent cost. A cheaper or stronger profile can only be requested by hand-editing every dispatch site.

Two authority classes

CE's generic workers split into two authority classes:

• Read-only workers: reviewers, scouts, researchers, validators. They never mutate tracked project content; per-run scratch artifacts (dossiers, reviewer JSON, run logs) stay in this class.
• Write-capable workers: implementers and fixers that mutate tracked project content.

The split matters because a cheaper profile must never silently gain write authority.

Proposed configuration

Two optional keys under the existing .compound-engineering/ cascade (config.local.yaml then config.yaml):

# .compound-engineering/config.yaml
subagent_read_profile: ce-explorer    # generic dispatches that do not mutate tracked content
subagent_write_profile: ce-worker     # generic dispatches that do

Semantics:

• Profile names are opaque host-defined strings. The plugin never invents, validates, or defaults one.
• The authority class is chosen per dispatch call, from the work the child actually needs.
• Keys apply only where the host's generic dispatch primitive accepts a named worker profile (on Devin, run_subagent's profile argument). Typed or registered-agent selectors are out of scope.
• On hosts with no such selector the keys are inert and dispatch is unchanged. Unset keys are a strict no-op everywhere, so existing Claude Code model-selector behaviour is preserved.
• A resolved profile supersedes the surface's model selection for that dispatch class; a profile and a model override are never passed together.
• Unknown, rejected, or unresolvable names follow the surface's ordinary dispatch-failure or degradation path, are named in coverage or degradation notes, and are never reported as having run.

Distinction from #1301

#1301 concerns model and effort selectors for the high-stakes adversarial code-review pass. This proposal covers the generic worker dispatch used across most CE skills: a different mechanism (run_subagent profile versus model flags), different consumers, and a different risk model. The two are complementary.

Tested environment

• Devin CLI 3000.10.31 on Linux x86_64: devin doctor reports pass custom subagent profiles 1 profile(s) loaded for a profile authored to the documented .devin/agents/<name>/AGENT.md shape.
• Installed docs for Devin CLI 3000.10.27 (subagents.mdx, models.mdx, reference/configuration/config-file.mdx) describe the two built-in profiles, the profile argument, custom profile locations, and allowed-tools as a hard restriction.
• Known limit: the subagent panel shows profile, status, and tool-call count but not the running model, so profile-to-model attribution is not machine-verifiable from the CLI. The implementation verifies the mechanical contract plus devin doctor and claims nothing further.

Request for comment

A draft implementation exists on a branch and will be proposed as a PR shortly. Feedback on the host-neutral shape is welcome: are subagent_read_profile/subagent_write_profile the right key names, and is the two-key authority split the right granularity? Implementation is not conditional on a response.

[tmchow]

Thanks for digging into this. There's def a gap here: run_subagent picks a worker by named profile, so CE's "use a cheaper tier for this worker" guidance has nowhere to land on Devin, and anything that needs write tools ends up on subagent_general at the parent model's cost. The docs/specs/devin.md additions are careful work and I'd like to keep them.

I don't want to take #1735 in its current shape, though. It adds two config keys for one host's experimental feature, and the same 11-line block goes into about 55 skill surfaces. Your agent went wild with this :(

Every Claude Code and Codex user loads that block on every dispatch and gets nothing from it. It also puts a Devin tool name into prose we author once for every host, and the parity test means each future dispatch site has to carry the block or be listed as excluded. That's a lot of permanent surface for a narrow case.

I think there's a much smaller fix that gets you the same result:

1. Define your profiles in .devin/agents/<name>/AGENT.md, which Devin already supports.
2. In your project's own AGENTS.md, say which profile to use for read-only subagents and which for ones that change tracked files. The agent already has that in context when it dispatches.
3. On the CE side, add one sentence where the model-tier guidance already lives (the model-tiers.md references): on a host that selects workers by named profile instead of by model, use the profile the project's instructions name for that class of work.

That's no config keys, no pasted block, and no parity sweep. Your read/write split still holds, because the project's instructions name a profile per class and the agent picks the class for each dispatch.

Would you be up for reworking the PR to that shape? Keep the spec doc changes, drop the rest, and add the one-line tier note.

One more thing: you mentioned 61 ce-work test failures that reproduce on a clean main, from a shared /tmp/ce-work-repo-template-* fixture that another file's cleanup deletes mid-run. Could you file that as its own issue with the repro? If that's what's happening, it's a real bug in our tests and I don't want it buried in this thread.

[GodsBoy]

Opened the minimal follow-up in #1746: retained the endorsed Devin spec additions, rechecked them against 3000.10.31, and added one host-neutral sentence to each of the two model-tier references. Profile selection comes from the project's active instructions; no configuration keys, repeated dispatch blocks or parity tests.

The separate fixture report is #1745, with exact reproduction commands, individual-file passes and the cache/cleanup cause. It predates and is independent of #1735. The version distinction matters: Bun 1.4.2 reproduces it in non-isolated multi-file runs, while the normal parallel suite isolates files and avoids that failure.

Focused checks and both validation commands pass. The PR records the full-suite baseline failures, the isolated timeout rerun and behavioural validation limits. GitHub's CI and Docs site workflows currently await maintainer approval before any jobs can run.

[tmchow]

Opened the minimal follow-up in #1746: retained the endorsed Devin spec additions, rechecked them against 3000.10.31, and added one host-neutral sentence to each of the two model-tier references. Profile selection comes from the project's active instructions; no configuration keys, repeated dispatch blocks or parity tests.

The separate fixture report is #1745, with exact reproduction commands, individual-file passes and the cache/cleanup cause. It predates and is independent of #1735. The version distinction matters: Bun 1.4.2 reproduces it in non-isolated multi-file runs, while the normal parallel suite isolates files and avoids that failure.

Focused checks and both validation commands pass. The PR records the full-suite baseline failures, the isolated timeout rerun and behavioural validation limits. GitHub's CI and Docs site workflows currently await maintainer approval before any jobs can run.

Did you actually do real world tests that this approach now works in Devin?