Skip to content

[awf] Disable rubber-duck sub-agent when Copilot is the engine #36935

Description

@lpcox

Problem

When running agentic workflows with the Copilot engine, the system prompt includes instructions to proactively invoke the rubber-duck sub-agent for plan validation and critique. This adds significant token overhead and latency for every non-trivial task — launching a separate Haiku-model agent, waiting for its response, then processing the feedback.

For Copilot engine runs, this is wasteful because:

  1. The rubber-duck agent uses additional model calls that count against the workflow's token budget
  2. It adds latency (sync sub-agent calls block the main agent)
  3. Copilot's built-in reasoning is generally sufficient for the tasks these workflows handle
  4. The defense-in-depth value is lower when the primary model already has strong reasoning capabilities

Proposed Solution

When the workflow engine is copilot, the compiled lock file should either:

  • Omit the rubber-duck collaboration instructions from the system prompt entirely, or
  • Include a directive like "Do not use the rubber-duck agent" in the system prompt

This could be implemented as:

  • A per-engine default in the compiler (rubber-duck enabled for claude/codex, disabled for copilot)
  • A workflow-level opt-in/opt-out field (e.g. rubber-duck: false)
  • Both (engine default + explicit override)

Context

The rubber-duck instructions are injected via the Copilot CLI system prompt and encourage the agent to call task(agent_type: "rubber-duck") before implementing non-trivial changes. While valuable for some engines/tasks, it's pure overhead for Copilot engine workflows that are already well-scoped.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions