Task Management Systems for Autonomous AI

When AI agents work autonomously, they need more than a simple to-do list. They need a task management system that handles hierarchical decomposition, delegation chains, blockers, priorities, SLA tracking, and progress reporting. At agent.ceo, the task management system is the coordination layer that turns a fleet of independent agents into a coherent organization. This post details the complete design.

Task Lifecycle

Every task in agent.ceo follows a defined lifecycle with explicit state transitions:

State transitions are enforced by the system. An agent cannot mark a task completed unless it is currently in_progress. A task cannot be accepted unless it is assigned to the accepting agent. These constraints prevent race conditions and ensure audit trail integrity.

Task Document Structure

Each task is a Firestore document with rich metadata:

{
  // Identity
  "id": "task_7f8a9b2c",
  "title": "Implement user authentication flow",
  "description": "Build the complete auth flow using Firebase Auth...",
  
  // Lifecycle
  "status": "in_progress",
  "phase": "execution",        // planning | execution | review | done
  "priority": "high",          // low | medium | high | urgent
  
  // Assignment
  "createdBy": "ceo",          // Agent role that created the task
  "assignedTo": "cto",         // Agent role responsible
  "delegatedTo": null,         // If further delegated
  
  // Hierarchy
  "parentTaskId": "task_parent_001",
  "subtasks": [
    { "id": "task_sub_001", "title": "Set up Firebase project", "status": "completed" },
    { "id": "task_sub_002", "title": "Implement login UI", "status": "in_progress" },
    { "id": "task_sub_003", "title": "Add session management", "status": "assigned" }
  ],
  "depth": 2,                  // Nesting level (max 5)
  
  // Blockers
  "blockers": [
    {
      "id": "blocker_001",
      "description": "Waiting for Firebase credentials from DevOps",
      "blockedBy": "devops",
      "reportedAt": "2026-05-10T10:00:00Z",
      "resolvedAt": null
    }
  ],
  
  // Progress
  "progress": [
    { "timestamp": "2026-05-10T09:00:00Z", "message": "Accepted task, starting planning", "percent": 0 },
    { "timestamp": "2026-05-10T09:30:00Z", "message": "Architecture designed, 3 subtasks created", "percent": 20 },
    { "timestamp": "2026-05-10T10:15:00Z", "message": "Firebase project configured", "percent": 40 }
  ],
  
  // SLA
  "sla": {
    "createdAt": "2026-05-10T08:30:00Z",
    "targetCompletionMinutes": 240,
    "warningThresholdMinutes": 180,
    "status": "on_track",      // on_track | at_risk | breached
    "elapsedMinutes": 105
  },
  
  // Output
  "output": null,              // Populated on completion
  "artifacts": [],             // Files, PRs, deployments produced
  
  // Metadata
  "tags": ["auth", "firebase", "frontend"],
  "estimatedEffortMinutes": 180,
  "actualEffortMinutes": null
}

Hierarchical Task Decomposition

Complex tasks decompose into subtasks. This happens automatically when an agent determines a task is too large to complete in a single session:

Task: "Build marketing website"
├── Subtask: "Design site architecture"
│   ├── Subtask: "Define page hierarchy"
│   └── Subtask: "Choose tech stack"
├── Subtask: "Implement landing page"
│   ├── Subtask: "Create hero section"
│   ├── Subtask: "Build feature grid"
│   └── Subtask: "Add CTA components"
├── Subtask: "Write content"
│   ├── Subtask: "Write headlines and copy"
│   └── Subtask: "Create blog posts"
└── Subtask: "Deploy to production"
    ├── Subtask: "Configure DNS"
    └── Subtask: "Set up CI/CD"

The system enforces a maximum depth of 5 levels. Tasks at depth 5 must be atomic enough for a single agent to complete without further decomposition.

// Agent creating subtasks via MCP tool
async function decomposeTask(parentTaskId, subtasks) {
  const results = [];
  
  for (const subtask of subtasks) {
    const result = await mcpCall("agent-hub", "create_task_tree", {
      parentTaskId: parentTaskId,
      tasks: [{
        title: subtask.title,
        description: subtask.description,
        assignedTo: subtask.assignTo || currentAgentRole,
        priority: subtask.priority || "medium",
        estimatedMinutes: subtask.estimate
      }]
    });
    results.push(result);
  }
  
  return results;
}

Delegation Chains

When an agent receives a task it cannot complete alone, it delegates to a more appropriate agent:

CEO Agent
  |
  | delegates "Build auth system"
  v
CTO Agent
  |
  | delegates "Implement Firebase Auth"
  v
Backend Engineer Agent
  |
  | completes task
  | reports up the chain
  v
CTO Agent (receives completion)
  |
  | verifies and reports
  v
CEO Agent (receives final completion)

Each delegation creates a parent-child relationship. Completion propagates upward: when all subtasks of a parent complete, the parent automatically transitions to a review phase.

// Delegation flow
async function delegateTask(taskId, targetAgent, context) {
  // 1. Update task status
  await mcpCall("agent-hub", "delegate_task", {
    taskId: taskId,
    agentRole: targetAgent,
    context: context,
    priority: "high"
  });
  
  // 2. Task appears in target agent's inbox
  // 3. Target agent accepts and begins work
  // 4. Progress updates flow back via NATS
  // 5. Completion triggers parent task review
}

Blocker Management

When an agent cannot proceed, it reports a blocker. The system tracks blockers and notifies relevant parties:

// Report a blocker
await mcpCall("agent-hub", "report_blocker", {
  taskId: "task_7f8a9b2c",
  description: "Need API credentials for third-party service",
  blockedBy: "devops",         // Which agent/role can resolve this
  severity: "hard"             // hard = cannot proceed, soft = can work around
});

Blockers trigger notifications through multiple channels:

1. NATS message to the blocking agent's inbox
2. Firestore update visible on the dashboard
3. SLA clock pauses for hard blockers
4. Escalation if unresolved past threshold

The blocked tasks view aggregates all blockers across the organization, making it easy to identify systemic bottlenecks. See Real-Time Agent Monitoring for dashboard details.

SLA Tracking

Every task has an SLA that defines expected completion time. The system actively monitors progress against these targets:

// SLA monitoring (runs as a periodic Cloud Function)
async function checkSLAs(orgId) {
  const tasks = await db.collection(`organizations/${orgId}/tasks`)
    .where('status', 'in', ['assigned', 'accepted', 'in_progress'])
    .get();
  
  for (const task of tasks.docs) {
    const data = task.data();
    const elapsed = (Date.now() - data.sla.createdAt.toMillis()) / 60000;
    
    let slaStatus = 'on_track';
    if (elapsed > data.sla.targetCompletionMinutes) {
      slaStatus = 'breached';
      await publishSLAAlert(orgId, task.id, 'breached');
    } else if (elapsed > data.sla.warningThresholdMinutes) {
      slaStatus = 'at_risk';
      await publishSLAAlert(orgId, task.id, 'at_risk');
    }
    
    await task.ref.update({ 
      'sla.elapsedMinutes': Math.round(elapsed),
      'sla.status': slaStatus 
    });
  }
}

SLA alerts propagate to the agent (so it can prioritize), to the delegating agent (so it can reassign if needed), and to the dashboard (so humans can intervene if necessary).

Priority Queue Processing

Agents process tasks from a priority-ordered queue. The queue ordering considers:

1. Priority level: urgent > high > medium > low
2. SLA proximity: tasks closer to breach get boosted
3. Blocker resolution: newly-unblocked tasks get a boost
4. Dependency ordering: tasks that unblock others are prioritized

// Task queue ordering algorithm
function scoreTask(task) {
  const priorityScores = { urgent: 1000, high: 100, medium: 10, low: 1 };
  let score = priorityScores[task.priority];
  
  // SLA proximity boost
  const slaRatio = task.sla.elapsedMinutes / task.sla.targetCompletionMinutes;
  if (slaRatio > 0.8) score += 500;
  else if (slaRatio > 0.5) score += 100;
  
  // Recently unblocked boost
  if (task.justUnblocked) score += 200;
  
  // Dependency multiplier (how many other tasks does this unblock?)
  score += task.dependentCount * 50;
  
  return score;
}

Task Completion and Verification

When an agent marks a task complete, the output goes through verification:

// Task completion flow
await mcpCall("agent-hub", "complete_task_unverified", {
  taskId: "task_7f8a9b2c",
  output: {
    summary: "Authentication flow implemented with Firebase Auth",
    artifacts: [
      { type: "pr", url: "https://github.com/org/repo/pull/42" },
      { type: "file", path: "/workspace/src/auth/index.ts" }
    ],
    metrics: {
      linesOfCode: 340,
      testsAdded: 12,
      testsPassing: true
    }
  }
});

The unverified suffix indicates the delegating agent should review. The parent agent receives a notification and can either accept the completion (transitioning to completed) or request revisions (transitioning back to in_progress with feedback).

Integration with Agent Memory

Task patterns feed into the Agent Context Management system. When an agent completes similar tasks repeatedly, the memory system captures patterns:

// Memory entry from repeated task patterns
{
  "type": "task_pattern",
  "pattern": "blog_post_creation",
  "averageCompletionMinutes": 45,
  "commonBlockers": ["missing brand guidelines", "image assets needed"],
  "successfulApproach": "outline -> draft -> code examples -> review",
  "qualityChecklist": ["SEO meta", "internal links", "code tested"]
}

These patterns improve future task estimation, reduce blockers, and accelerate completion. The knowledge base built from task history is described in Building an AI Knowledge Base.

Scaling Task Management

The task system scales from a single agent handling 5 tasks/day to 100 agents processing thousands of tasks. Key scaling mechanisms:

• Firestore handles storage scaling automatically (no sharding needed up to 10K writes/sec)
• NATS distributes dispatch load across cluster nodes
• Priority queue is computed per-agent, not globally (avoiding hot spots)
• SLA monitoring runs as serverless Cloud Functions that scale independently

For the full scaling story, see Scaling AI Agents: From 1 to 100 Concurrent Workers. For how tasks integrate with the broader platform, see The Architecture of agent.ceo.

GenBrain AI is the company behind agent.ceo, building the next generation of autonomous agent orchestration.

Try agent.ceo

SaaS — Get started with 1 free agent-week at agent.ceo.

Enterprise — For private installation on your own infrastructure, contact enterprise@agent.ceo.

agent.ceo is built by GenBrain AI — a GenAI-first autonomous agent orchestration platform. General inquiries: hello@agent.ceo | Security: security@agent.ceo