Articles/Agents & Manager

◈ Agents & Manager/2026-03-25Advanced

Running 5 Agents in Parallel on Antigravity: A Production Design for Decomposition, Conflict Resolution, and Merging

A production design for running up to five agents in parallel on Antigravity, written from an indie developer's operations perspective. Covers task decomposition, policy-based conflict resolution, artifact validation and merging, and how to tell when parallelization stops helping.

multi-agent⁴⁹ parallel processing architecture¹⁹ orchestration²¹ production⁷¹

✦ Premium Article

Running four content sites in parallel taught me something counterintuitive: the tasks I handed to a single agent with "please do all of it" were the ones that needed the most rework afterward. When one agent tries to optimize the frontend and the infrastructure at the same time, both tend to stall at about seventy percent.

That is why, as an indie developer, I began leaning on a setup of several role-specific agents running at once. This article walks through how to decompose work for up to five parallel agents on Antigravity, how to settle their conflicts, and how to merge their output safely—using the implementation code I actually run.

I will also be honest about where parallelization stops helping. When adding agents becomes the goal in itself, operations only get heavier.

Foundations: Single Agent vs. Parallel Multi-Agent

Why Parallel Agents Matter

Single Agent Limitations

A solo agent must juggle all responsibilities—frontend design, backend architecture, database optimization, testing, DevOps—simultaneously. While capable, the result is often a "jack of all trades, master of none" implementation.

Problems:

One agent can't simultaneously optimize for performance, security, and maintainability
Large codebases (>50K lines) show quality degradation
Specialist domain knowledge is missing
Execution time for complex projects exceeds human expectations

Multi-Agent Parallel Advantages

Input: "Build a full-stack SaaS application"
  │
  ├─ [Frontend Specialist] → React components, styling (parallel)
  ├─ [Backend Architect] → API design, data layer (parallel)
  ├─ [DevOps Engineer] → CI/CD, Kubernetes config (parallel)
  ├─ [Database Architect] → Schema optimization (parallel)
  └─ [QA Automation Master] → Test strategy (parallel)
  ↓
Results:
✓ Each domain is maximally optimized
✓ Quality scales with project size
✓ Total execution time = longest task (~4-6 hours vs. 10 business days)
✓ Risk distributed across agents with guardrails

Task Decomposition Strategies

Pattern A: Lightweight (3 Agents) – Mid-Size Projects

// Minimal viable parallel configuration
const lightweightConfig = {
  parallel_tier: {
    "agent_frontend": {
      type: "Frontend Specialist",
      responsibility: "UI/UX → React implementation",
      input: "project_specification.json",
      output: ["src/components/", "src/pages/", "styles/"]
    },
    "agent_backend": {
      type: "Backend Architect",
      responsibility: "API design → implementation",
      input: "project_specification.json",
      output: ["api/", "models/", "services/"]
    },
    "agent_devops": {
      type: "DevOps Engineer",
      responsibility: "CI/CD pipeline → deployment",
      dependencies: ["agent_frontend", "agent_backend"],
      input: ["frontend_outputs", "backend_outputs"],
      output: [".github/workflows/", "docker/", "terraform/"]
    }
  },
  execution_profile: {
    tier_1_duration: "45 minutes (parallel)",
    tier_2_duration: "30 minutes (after tier_1)",
    total_duration: "75 minutes"
  }
};

Pattern B: Enterprise Scale (5 Agents) – Large Projects

const enterpriseConfig = {
  stage_1_design: {
    // 30 minutes, 3 agents in parallel
    agents: ["UIDesignMaster", "APIDesignEngineer", "InfrastructureArchitect"],
    outputs: ["design_spec.json", "openapi.yaml", "architecture_diagram.json"]
  },
  stage_2_implementation: {
    // 2 hours, depends on stage_1
    agents: ["FrontendImplementation", "BackendImplementation", "DatabaseSpecialist", "InfraSetup"],
    dependencies: ["stage_1_design"]
  },
  stage_3_integration_and_testing: {
    // 1 hour, depends on stage_2
    agents: ["IntegrationTestMaster", "PerformanceTester", "SecurityTestingAnalyst"],
    dependencies: ["stage_2_implementation"]
  },
  total_time: "3.5 hours (vs. 10-15 business days traditionally)"
};

DAG-Based Dependency Management

The Directed Acyclic Graph (DAG) prevents circular dependencies and optimizes scheduling:

// dag.js - Orchestrate agent execution with dependency tracking
class ExecutionDAG {
  constructor() {
    this.tasks = {};
    this.dependencies = {};
  }
 
  addTask(taskId, agent, input, dependencies = []) {
    this.tasks[taskId] = {
      agent_type: agent,
      input: input,
      dependencies: dependencies,
      status: "pending",
      output: null,
      duration_ms: 0
    };
 
    dependencies.forEach(dep => {
      if (!this.dependencies[dep]) {
        this.dependencies[dep] = [];
      }
      this.dependencies[dep].push(taskId);
    });
  }
 
  computeExecutionTiers() {
    // Topological sort: assign tier based on max dependency tier
    const tiers = [];
    const computed = new Set();
 
    const computeTier = (taskId) => {
      if (computed.has(taskId)) return this.tasks[taskId].tier;
 
      const task = this.tasks[taskId];
      const depTiers = task.dependencies.length === 0
        ? [-1]
        : task.dependencies.map(dep => computeTier(dep));
 
      task.tier = Math.max(...depTiers) + 1;
      computed.add(taskId);
 
      if (!tiers[task.tier]) tiers[task.tier] = [];
      tiers[task.tier].push(taskId);
 
      return task.tier;
    };
 
    Object.keys(this.tasks).forEach(computeTier);
    return tiers.filter(t => t);
  }
 
  async executeParallel() {
    const tiers = this.computeExecutionTiers();
    const results = {};
 
    for (const tier of tiers) {
      console.log(`📌 Tier ${tiers.indexOf(tier)}: Running ${tier.length} tasks in parallel`);
 
      const tierPromises = tier.map(async (taskId) => {
        const task = this.tasks[taskId];
        const start = Date.now();
 
        console.log(`  ▶ [${taskId}] starting...`);
        const agent = await getAgent(task.agent_type);
        task.output = await agent.execute(task.input);
 
        task.duration_ms = Date.now() - start;
        task.status = "completed";
        results[taskId] = task.output;
 
        console.log(`  ✓ [${taskId}] done in ${(task.duration_ms / 1000).toFixed(1)}s`);
      });
 
      await Promise.all(tierPromises);
    }
 
    return results;
  }
}
 
// Usage
const dag = new ExecutionDAG();
dag.addTask("design_api", "APIDesignEngineer", projectSpec);
dag.addTask("design_db", "DatabaseArchitect", projectSpec);
dag.addTask("impl_api", "BackendImplementation", {}, ["design_api"]);
dag.addTask("impl_db", "DatabaseImplementation", {}, ["design_db"]);
dag.addTask("test_integration", "IntegrationTestMaster", {}, ["impl_api", "impl_db"]);
 
const results = await dag.executeParallel();

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A DAG-based scheduler that resolves dependencies and runs each tier of agents in parallel

✦A policy-driven conflict resolution engine for performance-vs-security and framework disputes

✦The three situations where adding more agents makes things slower, and why review and merge become the bottleneck

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Conflict Resolution Architecture

When multiple agents operate in parallel, conflicting recommendations are inevitable. Antigravity provides mechanisms to resolve them systematically.

Conflict Scenarios & Resolution Policies

Scenario 1: Performance vs. Security

// Backend Agent proposes:
const backendProposal = {
  database: "MongoDB (NoSQL, ultra-fast)",
  caching: "Redis in-memory",
  encryption: "Optional - performance priority"
};
 
// Security Agent proposes:
const securityProposal = {
  database: "PostgreSQL (strong RBAC, auditing)",
  caching: "TLS-encrypted memcached",
  encryption: "Mandatory at-rest + in-transit"
};
 
// Resolution policy
const policy = {
  "performance_vs_security": {
    priority: "SECURITY_FIRST",
    rationale: "Data breach > performance degradation",
    resolution: securityProposal,
    optimization: "PostgreSQL + TLS Redis achieves both"
  }
};

Scenario 2: Framework Selection Conflict

// Frontend Agent:
const frontendChoice = {
  framework: "Next.js 15",
  state: "Zustand",
  testing: "Vitest"
};
 
// DevOps Agent (conservative):
const devopsChoice = {
  framework: "Create React App",
  state: "Redux",
  testing: "Jest"
};
 
// Context-aware resolution
const contextualResolver = {
  criteria: {
    project_stage: "startup",      // → new tech acceptable
    hosting: "Vercel available",   // → Next.js optimal
    team_expertise: "React heavy", // → Next.js familiar
    legacy_constraints: "none"     // → no technical debt
  },
  decision: frontendChoice // All criteria favor Next.js
};

Conflict Resolution Engine

// conflict-resolver.js
class ConflictResolver {
  constructor(policies = {}) {
    this.policies = policies;
    this.resolutionLog = [];
  }
 
  async resolve(agent1, proposal1, agent2, proposal2, context) {
    const conflictType = this.classifyConflict(proposal1, proposal2);
 
    console.log(`⚠️  Conflict: ${agent1.name} ↔ ${agent2.name}`);
    console.log(`   Type: ${conflictType}`);
 
    // Step 1: Apply policy if exists
    let resolution = this.applyPolicy(conflictType, proposal1, proposal2, context);
 
    // Step 2: Fallback to scoring if no policy
    if (!resolution) {
      resolution = await this.scoreAndCompare(proposal1, proposal2, context);
    }
 
    // Step 3: Log for audit trail
    this.resolutionLog.push({
      conflict_type: conflictType,
      agent1: agent1.name,
      agent2: agent2.name,
      resolution: resolution,
      timestamp: Date.now()
    });
 
    return resolution;
  }
 
  applyPolicy(type, prop1, prop2, context) {
    const policy = this.policies[type];
    if (!policy) return null;
 
    switch (policy.rule) {
      case "PRIORITY_A": return prop1;
      case "PRIORITY_B": return prop2;
      case "SECURITY_FIRST": return this.selectSecurer(prop1, prop2);
      case "CONTEXT_AWARE": return this.evaluateContext(prop1, prop2, context, policy.criteria);
    }
  }
 
  scoreAndCompare(prop1, prop2, context) {
    // Multi-dimensional scoring
    const weights = {
      ecosystem_maturity: 0.2,
      team_capability: 0.2,
      long_term_maintainability: 0.15,
      performance: 0.15,
      security: 0.2,
      cost: 0.1
    };
 
    const score1 = Object.entries(weights).reduce((sum, [dim, w]) => {
      return sum + (prop1[dim] || 0) * w;
    }, 0);
 
    const score2 = Object.entries(weights).reduce((sum, [dim, w]) => {
      return sum + (prop2[dim] || 0) * w;
    }, 0);
 
    return score1 > score2 ? prop1 : prop2;
  }
 
  classifyConflict(prop1, prop2) {
    const keys1 = Object.keys(prop1);
    const keys2 = Object.keys(prop2);
    const overlap = keys1.filter(k => keys2.includes(k));
 
    if (overlap.includes("performance") && overlap.includes("security"))
      return "performance_vs_security";
    if (overlap.includes("framework")) return "framework_choice";
    if (overlap.includes("cost")) return "cost_vs_performance";
 
    return "unknown_conflict";
  }
}

Artifact Validation & Merging

Multi-agent output must be validated and merged safely before deployment.

Artifact Quality Validation

// validator.js
class ArtifactValidator {
  async validateMultiple(artifacts) {
    const results = {};
 
    for (const [source, artifact] of Object.entries(artifacts)) {
      results[source] = await this.validateArtifact(artifact);
    }
 
    return results;
  }
 
  async validateArtifact(artifact) {
    const checks = {
      syntax: await this.verifySyntax(artifact),
      dependencies: await this.checkDependencies(artifact),
      type_safety: await this.checkTypes(artifact),
      security: await this.auditSecurity(artifact),
      performance: await this.benchmarkPerformance(artifact)
    };
 
    const passed = Object.values(checks).every(c => c.ok);
 
    return {
      passed: passed,
      checks: checks,
      warnings: this.extractWarnings(checks),
      score: passed ? "A" : "F"
    };
  }
 
  async verifySyntax(artifact) {
    try {
      if (artifact.type === "javascript") {
        new Function(artifact.code);
      } else if (artifact.type === "json") {
        JSON.parse(artifact.content);
      }
      return { ok: true };
    } catch (e) {
      return { ok: false, error: e.message };
    }
  }
 
  async auditSecurity(artifact) {
    const issues = [];
 
    if (artifact.code?.includes("eval(")) issues.push("eval() usage");
    if (artifact.code?.includes("dangerouslySetInnerHTML")) issues.push("XSS risk");
    if (artifact.code?.match(/password\s*=\s*['"][^'"]+['"]/)) {
      issues.push("Hardcoded secret");
    }
 
    return { ok: issues.length === 0, issues };
  }
}

Smart Merging

// merger.js
class SmartMerger {
  async merge(artifacts) {
    const categorized = this.categorizeByDomain(artifacts);
 
    const merged = {
      frontend: await this.mergeFrontendLayer(categorized.frontend),
      backend: await this.mergeBackendLayer(categorized.backend),
      infrastructure: await this.mergeInfraLayer(categorized.infrastructure),
      tests: await this.mergeTestLayer(categorized.tests)
    };
 
    await this.validateMerged(merged);
    return merged;
  }
 
  mergeFrontendLayer(frontendArtifacts) {
    // Combine React components, styles, assets
    const result = {
      components: {},
      styles: {},
      pages: {},
      utils: {}
    };
 
    for (const [source, artifact] of Object.entries(frontendArtifacts)) {
      result.components = this.deepMerge(result.components, artifact.components);
      result.styles = this.deepMerge(result.styles, artifact.styles);
    }
 
    return result;
  }
 
  deepMerge(target, source) {
    for (const [key, value] of Object.entries(source)) {
      if (target[key] && typeof target[key] === "object") {
        target[key] = this.deepMerge(target[key], value);
      } else if (target[key] && target[key] !== value) {
        console.warn(`⚠️  Merge conflict at ${key} - using newer value`);
        target[key] = value; // Override with newer
      } else {
        target[key] = value;
      }
    }
    return target;
  }
}

Production Workflow: Full-Stack SaaS Example

Building a Notion-like note application with 5 agents in parallel:

// production-workflow.js
const buildFullStackSaaS = async () => {
  console.log("🚀 Starting Full-Stack SaaS Build");
  console.log("📋 Project: Collaborative Note App (Notion-style)");
  console.log("⏱️  Target: 4 hours total (vs. 10 business days)\n");
 
  const agents = {
    frontend: await getAgent("UIComponentSpecialist"),
    backend: await getAgent("BackendArchitect"),
    database: await getAgent("DatabaseArchitect"),
    devops: await getAgent("DevOpsEngineer"),
    testing: await getAgent("QAAutomationMaster")
  };
 
  const startTime = Date.now();
 
  // Stage 1: Parallel execution (no dependencies)
  console.log("📌 Stage 1: Parallel Design & Architecture (30 min)\n");
 
  const [frontend, backend, database, devops, testing] = await Promise.all([
    agents.frontend.generate({
      spec: projectSpec,
      design: figmaLink,
      framework: "Next.js 15",
      styling: "Tailwind CSS v4"
    }),
 
    agents.backend.architect({
      spec: projectSpec,
      slas: { p99_latency: "< 100ms", availability: "99.9%" }
    }),
 
    agents.database.design({
      entities: ["users", "workspaces", "documents", "comments"],
      scale: "10M+ documents",
      compliance: "SOC2"
    }),
 
    agents.devops.configure({
      platform: "AWS",
      regions: ["us-east-1", "ap-southeast-1"],
      autoscaling: true,
      monitoring: "Datadog"
    }),
 
    agents.testing.strategize({
      coverage_target: 80,
      e2e_scenarios: [
        "user_signup",
        "create_document",
        "collaborative_edit",
        "share_workspace",
        "export_as_pdf"
      ]
    })
  ]);
 
  const parallelDuration = (Date.now() - startTime) / 1000 / 60;
  console.log(`✓ Stage 1 complete: ${parallelDuration.toFixed(1)} minutes\n`);
 
  // Stage 2: Validation
  console.log("🔍 Validation Phase\n");
  const validator = new ArtifactValidator();
  const validation = await validator.validateMultiple({
    frontend, backend, database, devops, testing
  });
 
  for (const [source, result] of Object.entries(validation)) {
    const status = result.passed ? "✓" : "✗";
    console.log(`${status} ${source}`);
  }
 
  // Stage 3: Merge
  console.log("\n🔗 Merging artifacts...\n");
  const merger = new SmartMerger();
  const merged = await merger.merge({
    frontend, backend, database, devops, testing
  });
 
  // Stage 4: Commit & Deploy
  console.log("📦 Committing to repository...");
  await git.commit({
    message: "feat: Full-stack SaaS v1.0 (5-agent parallel)",
    files: merged
  });
 
  console.log("🚀 Deploying to production...");
  const deployment = await deployToAWS(merged);
 
  const totalDuration = (Date.now() - startTime) / 1000 / 60;
  console.log(`\n✅ Complete! Duration: ${totalDuration.toFixed(1)} minutes`);
  console.log(`\n📊 Deliverables:`);
  console.log(`   Frontend: ${Object.keys(merged.frontend.components).length} components`);
  console.log(`   Backend: ${Object.keys(merged.backend.routes).length} API endpoints`);
  console.log(`   Database: ${Object.keys(merged.database.tables).length} tables`);
  console.log(`   Tests: ${Object.keys(merged.tests.scenarios).length} test scenarios`);
  console.log(`   🌍 Live at: ${deployment.url}`);
};
 
await buildFullStackSaaS();

When Parallelization Stops Helping

More agents rarely means proportionally faster. Across my own automated workflows at Dolice Labs, three patterns tripped me up repeatedly.

1. When dependencies form a single chain

Design → implement → test work, where each stage must wait for the previous one, takes the same wall-clock time no matter how many agents you line up. If your DAG only grows vertically, you have divided the work, not parallelized it. Parallelism pays off only when two or more tasks sit in the same tier.

2. When merging needs human eyes

Pushing code that five agents generated simultaneously straight to production on mechanical validation alone is not realistic. In my own pipeline, generation runs in parallel, but the final quality gate and the integration decision queue up in a single serial line. Make generation five times faster and, if review stays at one person's capacity, throughput is still bound by review. This wall is common to any automation that keeps a human in the loop.

3. When conflict resolution costs more than the split saves

The finer you slice tasks, the more the agents' assumptions drift apart. If the frontend agent's state-management choice clashes with what the test agent expected, reconciling it burns human time. Three agents often finish faster than five that need constant alignment.

My rule for choosing a parallel setup is a single question: is the reconciliation cost that remains after splitting smaller than the time I save? When I cannot nod confidently, I simply reduce the agent count.

Looking back

Parallel multi-agent orchestration is powerful when you pick the right place for it. The workflow example in this article quotes 3.5 hours, but that is a best case with few dependencies; in practice, conflict resolution and merging always push it higher. What matters is less that it got faster, and more that specialization and multi-view validation reduce the total amount of rework.

If you are about to try it, run a pipeline once with three agents first and watch whether the tasks sharing a tier are truly independent. Decide whether to add more only after that, and the design tends to settle without strain. For more advanced delegation patterns, see Multi-Model Mastery: Integrating Gemini + Claude + GPT.

Thank you for reading.

Published: March 25, 2026 Scope: Antigravity 2025 Q4+

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.