Self-Development Guide

This guide explains how to use agents_conductor to develop itself — the ultimate proof of the system's capabilities.

Concept: Dogfooding

Dogfooding means using your own product for development. By running agents_conductor on its own repository, we demonstrate:

✅ Complete autonomy: System can execute full development lifecycle
✅ Cost efficiency: Free execution layer enables 0-cost self-improvement
✅ Quality assurance: Multi-round review ensures code correctness
✅ Loop capabilities: Self-fixing via feedback loops
✅ Production readiness: Real-world scenario, not toy demo

Architecture

┌─────────────────────────────────────────────────────────────┐
│ agents_conductor monitors its own GitHub repo                │
│   ↓                                                          │
│ Detects issue labeled "conductor-ready"                     │
│   ↓                                                          │
│ Planner (GLM-5.2) plans implementation                        │
│   ↓                                                          │
│ Executor (GLM-4.7-flash FREE) modifies its own code          │
│   ↓                                                          │
│ Reviewer (DeepSeek-v4-flash) reviews its own code            │
│   ↓                                                          │
│ Reconciler creates PR to agents_conductor                    │
│   ↓                                                          │
│ Human merges PR                                             │
│   ↓                                                          │
│ agents_conductor improves itself!                           │
└─────────────────────────────────────────────────────────────┘

Setup

1. Configure Self-Development

# Use self-development config
./conductor -config config/self-development.yaml

Key differences from standard config:

worker_count: 2 — Lower to avoid conflicts with manual development
poll_interval: 30s — Faster for responsive self-improvement
db_path: ./self-dev.db — Separate database for safety
repo: wangke19/agents_conductor — Watches own repository

2. Set Environment Variables

export GLM_API_KEY="your-glm-key"        # For planner & executor
export DEEPSEEK_API_KEY="your-deepseek"  # For reviewer
export GITHUB_TOKEN="your-github-token"  # For creating PRs

3. Create Self-Development Issues

Create issues in wangke19/agents_conductor with the label conductor-ready:

## Example Issue: Add metrics dashboard

**Title:** Add Prometheus metrics for circuit breaker state

**Body:**
Add prometheus metrics to expose circuit breaker state:
- Circuit open/close events
- Failure counts per provider
- Success rates

This should be added to internal/circuit/circuit.go with a new
metrics package that exports to Prometheus format.

**Priority:** medium
**Complexity:** low

4. Watch Self-Development

# Monitor the self-development database
sqlite3 self-dev.db "SELECT id, status, issue_title FROM tasks ORDER BY created_at DESC"

# Check recent activity
sqlite3 self-dev.db "SELECT status, COUNT(*) FROM tasks GROUP BY status"

Example Self-Development Tasks

Level 1: Simple Improvements

Issue: "Add unit tests for retry logic"

Planner adds tests to internal/retry/
Executor implements test cases (FREE)
Reviewer validates test coverage
Result: Improved test coverage at 0 cost

Issue: "Update README with new architecture"

Planner identifies sections needing updates
Executor modifies README.md (FREE)
Reviewer checks documentation quality
Result: Self-documenting system

Level 2: Feature Development

Issue: "Add worktree cleanup on task completion"

Planner designs cleanup mechanism
Executor implements cleanup in orchestrator (FREE)
Reviewer validates safety
Result: Self-improving resource management

Issue: "Implement task priority queue"

Planner designs priority system
Executor modifies router logic (FREE)
Reviewer checks correctness
Result: Advanced scheduling features

Level 3: Advanced Self-Improvement

Issue: "Add multi-provider fallback"

Planner designs fallback strategy
Executor modifies agent layer (FREE)
Reviewer validates logic
Result: Enhanced reliability

Issue: "Implement distributed task execution"

Planner designs distribution system
Executor creates coordination layer (FREE)
Reviewer checks race conditions
Result: Scalability improvements

Safety Mechanisms

1. Separate Database

db_path: ./self-dev.db  # Isolated from main conductor.db

Prevents self-development tasks from mixing with production tasks.

2. Lower Worker Count

worker_count: 2  # Fewer parallel self-modifications

Reduces risk of conflicting self-changes.

3. Human Review Gate

# Reconciler creates PR, doesn't auto-merge
# Human reviews all self-improvement PRs

Final approval always requires human review.

4. Rollback Safety

All self-changes on branches → PR review → Merge
Easy to revert if self-improvement breaks system

Monitoring Self-Development

Track Self-Improvement Progress

# View self-development tasks
sqlite3 self-dev.db "
SELECT 
  id, 
  status, 
  issue_title,
  review_count,
  created_at
FROM tasks 
WHERE issue_url LIKE '%agents_conductor%'
ORDER BY created_at DESC 
LIMIT 10
"

Check Quality Metrics

# Review iteration counts (quality indicator)
sqlite3 self-dev.db "
SELECT 
  AVG(review_count) as avg_reviews,
  MAX(review_count) as max_reviews,
  COUNT(*) as total_tasks
FROM tasks
WHERE status = 'done'
"

Monitor Cost Savings

# Estimate self-development cost savings
# Each task using commercial LLM: $0.15-0.30
# Each task using domestic LLM: $0.008-0.036

# For 100 self-improvement tasks:
# Commercial: 100 × $0.20 = $20.00
# Domestic: 100 × $0.02 = $2.00
# Savings: $18.00 (90%)

Best Practices

1. Start Simple

Begin with low-risk, high-value tasks:

Documentation improvements
Test coverage additions
Logging enhancements
Configuration options

2. Gradual Complexity

Progress to medium complexity:

Feature additions
Refactoring existing code
Performance improvements

3. Careful with Core Changes

For critical changes:

Create detailed issue descriptions
Review PRs carefully
Test thoroughly before merging
Have rollback plan ready

4. Monitor Loop Health

Watch for:

# Tasks hitting max review iterations
sqlite3 self-dev.db "
SELECT id, issue_title, review_count
FROM tasks
WHERE review_count >= 4
"

# May indicate:
# - Self-improvement quality issues
# - Need for better planning
# - Reviewer tuning needed

Expected Outcomes

Short-term (1-2 weeks)

✅ 10-20 self-improvement tasks completed
✅ Documentation auto-updated
✅ Test coverage increased
✅ Minor features added

Medium-term (1-2 months)

✅ 50-100 self-improvement tasks completed
✅ Multiple features self-developed
✅ Bugs self-fixed
✅ Quality improvements validated

Long-term (3-6 months)

✅ System continuously self-improving
✅ Complex features self-developed
✅ Architecture evolves autonomously
✅ Cost savings proven at scale

Proof Points

For Stakeholders

Managers:

"The system develops itself at 90% cost reduction"
"Zero marginal cost for feature additions"
"Continuous autonomous improvement"

Developers:

"Focus on complex tasks, let AI handle routine improvements"
"System maintains its own documentation"
"Test coverage improves automatically"

Architects:

"Validates system architecture completeness"
"Demonstrates Loop Agent capabilities"
"Proves production readiness"

Metrics to Track

-- Self-development velocity
SELECT 
  DATE(created_at) as day,
  COUNT(*) as tasks_completed
FROM tasks
WHERE status = 'done'
GROUP BY day
ORDER BY day;

-- Quality assurance effectiveness
SELECT 
  AVG(review_count) as avg_quality_checks,
  COUNT(CASE WHEN status = 'blocked' THEN 1 END) as blocked_tasks,
  COUNT(CASE WHEN status = 'done' THEN 1 END) as successful_tasks
FROM tasks;

-- Cost efficiency
SELECT 
  COUNT(*) as total_tasks,
  COUNT(*) * 0.02 as estimated_cost_domestic,
  COUNT(*) * 0.20 as estimated_cost_commercial,
  (COUNT(*) * 0.20) - (COUNT(*) * 0.02) as savings
FROM tasks
WHERE status = 'done';

Comparison: Self-Development vs Manual Development

Aspect	Manual Development	Self-Development
Cost per feature	Developer hours + API costs	API costs only (~$0.02)
Speed	Days to weeks	Hours to days
Consistency	Variable	Multi-round review ensures quality
Documentation	Manual updates	Auto-documented
Test coverage	Manual addition	Auto-improved
24/7 operation	No	Yes
Scalability	Linear (more devs)	Constant (system runs itself)

Limitations

Not Suitable For

❌ Breaking architecture changes (human oversight required)
❌ Security-sensitive modifications (human review mandatory)
❌ Performance-critical optimizations (human validation needed)
❌ Complex refactoring (human planning superior)

Best For

✅ Feature additions
✅ Documentation updates
✅ Test improvements
✅ Bug fixes
✅ Configuration enhancements
✅ Logging/metrics additions

Conclusion

Self-development is the ultimate validation of agents_conductor's capabilities. By successfully developing itself, the system proves:

Complete autonomy — Full development lifecycle automation
Cost efficiency — 90% cost reduction with domestic LLMs
Quality assurance — Multi-round review ensures correctness
Loop capabilities — Self-fixing via feedback loops
Production readiness — Real-world dogfooding

The system that develops systems — including itself.

FilesExpand file tree

self-development.md

Latest commit

History