Skip to content

Agent Collaboration Patterns

This document defines patterns for agent collaboration in the ConnectSoft AI Software Factory. It is written for architects and engineers designing agent interactions, workflows, and automation flows.

Agents collaborate through events, shared knowledge, and orchestration. Understanding these patterns is essential for designing effective agent workflows, debugging agent interactions, and extending the Factory with new automation capabilities.

Tip

This document can be used when designing new automation flows in the Factory. Choose the appropriate collaboration pattern based on your scenario (greenfield project, cross-cutting change, refactor, etc.).

Core Collaboration Patterns

The Factory uses several core collaboration patterns:

Sequential Pipeline

Pattern: Agents execute in strict sequence, each stage depends on previous stage's outputs.

When to Use: - Greenfield projects where architecture must precede implementation - When strict ordering is required (e.g., design before code)

Example: Vision → Architect → Engineering → QA → DevOps

Parallel Workstreams

Pattern: Multiple agents work on independent tasks simultaneously.

When to Use: - Multiple microservices or domains that don't depend on each other - When tasks can be safely parallelized

Example: Multiple Engineering agents generating different microservices in parallel

Review Loops

Pattern: Agents review each other's work and request changes in iterative loops.

When to Use: - Quality gates and validation - When feedback improves outcomes

Example: QA agent reviews Engineering output, requests fixes, Engineering fixes, QA re-validates

Governance Gate

Pattern: Final validation step before committing artifacts.

When to Use: - Critical changes requiring final approval - Compliance and security checks

Example: Governance agent validates all artifacts before finalization

Pattern 1: Sequential Pipeline

Diagram:

sequenceDiagram
    participant O as Orchestrator
    participant V as Vision Agent
    participant A as Architect Agent
    participant E as Engineering Agent
    participant Q as QA Agent
    participant D as DevOps Agent

    O->>V: Assign: Refine Requirements
    V->>O: Product Plan
    O->>A: Assign: Design Architecture
    A->>O: Blueprints & ADRs
    O->>E: Assign: Generate Code
    E->>O: Code & Tests
    O->>Q: Assign: Validate Quality
    Q->>O: Quality Report
    O->>D: Assign: Create Infrastructure
    D->>O: CI/CD & IaC
    O->>O: Finalize & Commit
Hold "Alt" / "Option" to enable pan & zoom

When to Use: - New project or major feature - When architecture must be designed before implementation - When strict ordering ensures correctness

Characteristics: - Predictable execution order - Each stage blocks next stage - Easy to debug and trace

Pattern 2: Parallel Workstreams

Diagram:

flowchart TD
    O[Orchestrator] -->|Assign| A[Architect Agent]
    A -->|Blueprints| O

    O -->|Assign in Parallel| E1[Engineering Agent 1<br/>Microservice A]
    O -->|Assign in Parallel| E2[Engineering Agent 2<br/>Microservice B]
    O -->|Assign in Parallel| E3[Engineering Agent 3<br/>Microservice C]

    E1 -->|Code| O
    E2 -->|Code| O
    E3 -->|Code| O

    O -->|Assign| Q[QA Agent]
    Q -->|Validates All| O
Hold "Alt" / "Option" to enable pan & zoom

When to Use: - Multiple independent microservices - When tasks don't depend on each other - To reduce total execution time

Characteristics: - Faster execution (parallel work) - Requires careful dependency management - More complex orchestration

Pattern 3: Review Loops

Diagram:

sequenceDiagram
    participant O as Orchestrator
    participant E as Engineering Agent
    participant Q as QA Agent

    O->>E: Assign: Generate Code
    E->>O: Code Generated
    O->>Q: Assign: Validate Code
    Q->>O: Issues Found

    alt Issues Found
        O->>E: Assign: Fix Issues
        E->>O: Fixed Code
        O->>Q: Assign: Re-validate
        Q->>O: Validation Pass
    else No Issues
        Q->>O: Validation Pass
    end

    O->>O: Proceed to Next Stage
Hold "Alt" / "Option" to enable pan & zoom

When to Use: - Quality gates and validation - When iterative improvement is beneficial - When feedback improves outcomes

Characteristics: - Iterative improvement - May require multiple loops - Can be time-consuming if many issues

Pattern 4: Governance Gate

Diagram:

flowchart TD
    O[Orchestrator] -->|All Artifacts| G[Governance Agent]
    G -->|Validates| G

    G -->|Compliance Check| G
    G -->|Security Check| G
    G -->|Policy Check| G

    G -->|Pass| O
    G -->|Fail| O

    O -->|Pass| C[Commit to Azure DevOps]
    O -->|Fail| E[Escalate to Human]
Hold "Alt" / "Option" to enable pan & zoom

When to Use: - Critical changes requiring final approval - Compliance and security requirements - Policy enforcement

Characteristics: - Final validation step - Blocks commits if failed - Escalates to humans if needed

When to Use Which Pattern

Greenfield Project

Pattern: Sequential Pipeline + Parallel Workstreams

Flow: 1. Vision & Planning (sequential) 2. Architecture (sequential) 3. Engineering (parallel - multiple microservices) 4. QA (parallel validation) 5. DevOps (sequential) 6. Governance Gate (final check)

Rationale: Architecture must precede implementation, but multiple microservices can be built in parallel once architecture is complete.

New Platform Capability

Pattern: Sequential Pipeline + Review Loops

Flow: 1. Vision & Planning 2. Architecture (with review loop) 3. Engineering (with QA review loops) 4. DevOps 5. Governance Gate

Rationale: Platform capabilities require careful design and validation, so review loops ensure quality.

Refactor Existing Service

Pattern: Review Loops + Governance Gate

Flow: 1. Architecture reviews existing service 2. Engineering updates code 3. QA validates (review loop until pass) 4. Governance Gate (ensure no regressions)

Rationale: Refactoring requires careful validation to avoid breaking changes.

Cross-Cutting Change

Pattern: Parallel Workstreams + Governance Gate

Flow: 1. Architecture designs change pattern 2. Engineering updates all affected services (parallel) 3. QA validates all services (parallel) 4. Governance Gate (ensure consistency)

Rationale: Cross-cutting changes affect multiple services, so parallel execution reduces time while governance ensures consistency.

Example: New Bounded Context

Scenario: Customer wants a new "Notification" bounded context.

Pattern Used: Sequential Pipeline + Review Loops

Detailed Flow:

  1. Vision & Planning Agent:
  2. Refines requirement into features (email notifications, push notifications, notification preferences)
  3. Creates user stories

  4. Outputs: Product plan

  5. Architect Agent:

  6. Designs Notification bounded context
  7. Defines aggregates (Notification, NotificationTemplate, NotificationPreference)
  8. Designs APIs (POST /notifications, GET /notifications, PUT /preferences)
  9. Designs events (NotificationSent, PreferenceUpdated)

  10. Outputs: Architecture blueprint, ADR

  11. Engineering Agent:

  12. Generates Notification microservice using template
  13. Implements domain logic (Notification aggregate, NotificationService)
  14. Creates use cases (SendNotification, UpdatePreferences)
  15. Generates API controllers

  16. Outputs: Complete microservice code

  17. QA Agent (Review Loop):

  18. Generates tests
  19. Validates code quality
  20. Finds issues → Engineering fixes → QA re-validates (loop until pass)

  21. Outputs: Test suites, quality report

  22. DevOps Agent:

  23. Creates CI/CD pipeline
  24. Generates infrastructure (Service Bus for notifications, storage)

  25. Outputs: Pipelines, Infrastructure-as-Code

  26. Governance Agent (Gate):

  27. Validates compliance
  28. Checks security

  29. Outputs: Approval or escalation

  30. Finalization:

  31. Commits all artifacts to Azure DevOps

Result: Complete Notification microservice with tests, infrastructure, and documentation.

Example: Cross-Cutting Change

Scenario: Add tenant context propagation to all microservices.

Pattern Used: Parallel Workstreams + Governance Gate

Detailed Flow:

  1. Architect Agent:
  2. Designs tenant context propagation pattern
  3. Creates ADR documenting the change

  4. Outputs: Pattern design, ADR

  5. Engineering Agents (Parallel):

  6. Agent 1: Updates Invoice microservice
  7. Agent 2: Updates Billing microservice
  8. Agent 3: Updates Audit microservice
  9. Each agent adds tenant context handling

  10. Outputs: Updated code for all services

  11. QA Agents (Parallel):

  12. Validates each updated service
  13. Ensures tenant isolation works correctly

  14. Outputs: Validation reports for all services

  15. DevOps Agent:

  16. Updates infrastructure if needed (no changes in this case)

  17. Outputs: Updated infrastructure (if any)

  18. Governance Agent (Gate):

  19. Validates tenant isolation across all services
  20. Ensures consistency

  21. Outputs: Approval

  22. Finalization:

  23. Commits changes to all repositories

Result: Tenant context propagation added consistently across all microservices.