Skip to content

Specialist Agents

You interact with one default assistant. It handles strategic work: briefings, priorities, decisions, shipping. When you need deep domain expertise, you invoke a specialist. Each specialist has focused skills and a clear scope boundary.

The Default Assistant

The default assistant is who you talk to in Copilot CLI. It is goal-aware, productivity-focused, and opinionated about priorities. It uses the shared skills for observe, plan, and ship workflows, and dispatches to specialists when work shifts into deep execution.

Defined by:

  • Identity & Routing: AGENTS.md (voice, routing rules, behavioral constraints)
  • Skills: shared skills in skills/ (available to all contexts)

Operating Modes

The default assistant automatically selects a mode based on your request:

Mode What it does Example
Prioritize Rank tasks by impact and urgency "What should I work on today?"
Decide Frame trade-offs with clear recommendations "Should we split this into two MRs?"
Synthesize Combine multiple sources into insight "Summarize this week's OSDU activity"
Mode What it does Example
Draft Produce send-ready written artifacts "Draft the ADR for this change"
Coach Teach through questions, not answers "Help me understand the CNPG operator"
Explore Open-ended research when you want breadth before action "What's the state of OSDU on GCP?"
Mode What it does Example
Briefing Daily OSDU status report /gm or /briefing
Tasks Manage and track work items "What are my open tasks?"

Routing: Observe vs Operate

Most interactions stay with the default assistant. Specialists activate when you need to operate on infrastructure or services, not just observe them.

Intent Where it goes Examples
Observe Default assistant "What MRs are open?", "Pipeline status for partition", "How are my goals?"
Plan Default assistant "What should I work on?", "Draft an ADR", "Summarize this week"
Ship Default assistant /send, /gm, /brain, /consolidate
Load data Default assistant "Load reference data", "Bootstrap with test data", "What datasets available"
Create / manage environments @cimpl "Create a cimpl environment", "Provision OSDU on Azure"
Operate infrastructure @cimpl "Add ACR to the infrastructure", "Debug the deployment failure"
Operate services @osdu "Clone partition and scan deps", "Run tests on storage"

The boundary is intent, not topic

Asking "what pipelines are failing?" stays with the default assistant — that is observation. Asking "fix the failing partition pipeline" dispatches to @osdu — that is operation. Same topic, different intent.

Delegation Model

Delegation is one-way: the default assistant dispatches to either specialist. Specialists never dispatch to each other or back to the default.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#036A6E', 'primaryTextColor': '#fff', 'primaryBorderColor': '#034f52', 'lineColor': '#036A6E', 'secondaryColor': '#0a8f94', 'tertiaryColor': '#0a8f94'}}}%%
graph TD
    D[Default Assistant] -->|infrastructure| C[@cimpl]
    D -->|services| O[@osdu]
    O -->|tests| R[qa-runner]
    O -->|analysis| A[qa-analyzer]
    O -->|compare| P[qa-comparator]
    O -->|reports| E[qa-reporter]

The default assistant holds the strategic picture: goals, priorities, deadlines, and decision history. Specialists stay focused on execution without carrying that broader context. You can also invoke a specialist directly without going through the default.

@cimpl

Purpose: Infrastructure, platform, and environment provisioning specialist.

When to use: When you need to create or manage CIMPL environments, modify infrastructure (Terraform, Helm, Kustomize, AKS), or debug deployment issues.

Spec: agents/cimpl.agent.md

Skills:

  • iac — Azure IaC patterns, AVM modules, Helm/Kustomize, AKS safeguards compliance, four-phase root cause analysis, evidence-based verification
  • clone — Clone the cimpl-azure-provisioning repository

Who uses it: Both new developers setting up environments and platform engineers modifying infrastructure.

Example: Creating a new environment

cimpl, create a cimpl environment
The agent:

  1. Clones cimpl-azure-provisioning to your workspace
  2. Verifies Azure authentication (az login, azd auth login)
  3. Checks for existing environments via azd env list
  4. Provisions the full stack via azd up (typically 20–30 min)

Example: Debugging a deployment failure

cimpl, debug why the CNPG webhook readiness check is failing
The agent runs a four-phase investigation:

  1. Gather evidence — kubectl logs, pod status, recent events
  2. Check recent changes — git log, Terraform state, Helm history
  3. Form hypothesis — correlate the failure with a likely root cause
  4. Implement fix — apply targeted fix, verify cluster health

Example use cases:

  • Creating or tearing down CIMPL environments (azd up, azd down)
  • Adding Azure Container Registry to the infrastructure layer
  • Migrating from MinIO to SeaweedFS across the stack
  • Onboarding a new OSDU service into the deployment pipeline
  • Resolving AKS deployment safeguard violations

@osdu

Purpose: Ecosystem operations specialist for OSDU platform services.

When to use: When you need to operate on OSDU service code: clone repos, scan dependencies, run builds and tests, analyze quality, remediate issues, review MRs.

Spec: agents/osdu.agent.md

Skills:

  • dependencies — Multi-ecosystem dependency analysis with Trivy scanning and risk scoring
  • maven — Maven version checking and security vulnerability scanning
  • build-runner — Execute build/test commands with structured output summaries
  • acceptance-test — Run Java acceptance/integration tests from service repos against live cimpl environments

Example: Dependency remediation workflow

osdu, clone the partition service
osdu, scan partition dependencies
osdu, remediate low-risk items, flag anything high
The agent clones the repo, runs Trivy scans, scores dependencies by risk, then processes updates by tier: batch LOW-risk changes, test MEDIUM individually, and flag HIGH for review. Results are stored in the vault under 04-reports/ when the brain is configured.

QA Sub-Agents

The OSDU agent spawns specialized sub-agents for test execution, analysis, comparison, and reporting:

Sub-Agent Role When to use
Runner Execute test commands in parallel across environments "Run tests on partition"
Analyzer Parse test results and identify failure patterns "Why are these tests failing?"
Comparator Compare results across environments "How does cimpl/lab compare to cimpl/qa?"
Reporter Generate dashboards and markdown reports "Generate a quality report for core services"

QA Environments

Environment Purpose Role
cimpl/lab Production reference Baseline for comparisons
cimpl/qa Master branch testing Primary QA environment
cimpl/temp Feature branch testing Pre-merge validation
cimpl/dev1 Development testing Active development

See also

  • Developer Workflows — repeatable patterns using these agents
  • Capabilities — skills and extensions available to each context
  • Brain — persistent memory layer for decisions, reports, and goals