Building an Intelligent Task Management Agent: A Practical Application of Automated Planning and Multi-Step Execution

Chapter 1: Operational Demo: From Text Request to Execution Plan

Welcome to the practical foundation of our course. In this chapter, we will deconstruct a complete, operational demo of our Intelligent Task Management Agent. Our goal is to move from a simple, natural language request—like something you'd tell a colleague—to a structured, executable plan that a computer can understand and act upon. This end-to-end walkthrough will illuminate the core problem we're solving: bridging the gap between human intent and machine-executable workflows.

1.1 The User's Request: A Natural Language Command

Our journey begins with a user's need. Imagine a project manager, Alex, who is preparing for a sprint review. Instead of manually opening multiple applications, Alex types a command into our agent's interface:

// The raw, natural language input from the user
const userRequest = "Prepare the sprint review: fetch open bugs from Jira tagged 'high-priority', summarize the main project document from Google Drive, and schedule a 1-hour meeting for tomorrow at 3 PM with the dev team.";

This single sentence encapsulates a multi-step, cross-platform operation. A human assistant would understand the implicit dependencies: you need the bug list and document summary before you can properly prepare for and schedule the meeting. Our agent must derive this same understanding. The request is declarative ("what" to do) rather than imperative ("how" to do it), which is the central challenge of automated planning.

1.2 Stage 1: Intent Parsing & Goal Decomposition

The first subsystem to engage is the Natural Language Understanding (NLU) module. Its job is to transform the free-text request into a structured, internal representation of the user's goal. Let's examine the output of this stage.

// Output from the NLU/Parsing stage
const parsedGoal = {
  primaryGoal: "prepare_sprint_review",
  subGoals: [
    {
      id: "sg_1",
      action: "fetch_data",
      target: "jira_issues",
      parameters: { filter: "open", label: "high-priority" },
      output: "highPriorityBugsList"
    },
    {
      id: "sg_2",
      action: "summarize_document",
      target: "google_drive",
      parameters: { docTitle: "main project document" },
      output: "projectSummary"
    },
    {
      id: "sg_3",
      action: "schedule_meeting",
      target: "calendar",
      parameters: { title: "Sprint Review", duration: "60", time: "tomorrow 15:00", attendees: "dev_team" },
      dependencies: ["sg_1", "sg_2"], // This is CRITICAL
      output: "meetingEvent"
    }
  ]
};

Let's break down this structure deeply. The primaryGoal is a canonical identifier for our planner. The subGoals array is the decomposed task list. Each sub-goal is an object representing a discrete, actionable step. Crucially, note the dependencies field in the third sub-goal. The NLU module, using semantic analysis, has inferred that scheduling the meeting logically depends on having the data from the first two steps. This dependency graph is the seed for our execution plan.

1.3 Stage 2: Planner Execution & Plan Generation

The parsed goal is now fed into the Automated Planner. This is the brain of our operation. The planner's knowledge base contains definitions of actions—their preconditions (what must be true to run them) and effects (what they make true). The planner searches for a sequence of these actions that transforms the initial state (no data fetched) into a state where the goal (sprint review prepared) is satisfied.

// The generated execution plan from the automated planner
const executionPlan = {
  planId: "plan_abc123",
  goal: "prepare_sprint_review",
  initialState: { hasBugsList: false, hasDocSummary: false, meetingScheduled: false },
  finalState: { hasBugsList: true, hasDocSummary: true, meetingScheduled: true },
  steps: [
    {
      stepId: 1,
      action: "call_jira_api",
      parameters: { endpoint: "/search", query: "status=open AND labels=high-priority" },
      expectedOutput: "highPriorityBugsList",
      preconditions: { api_available: true, authenticated: true }, // World state checks
      effects: { hasBugsList: true } // State changes after success
    },
    {
      stepId: 2,
      action: "call_gdrive_api",
      parameters: { action: "get_document", docId: "main_project_doc_id" },
      expectedOutput: "fullDocumentText",
      preconditions: { api_available: true, authenticated: true },
      effects: { hasDocText: true }
    },
    {
      stepId: 3,
      action: "call_summarization_service",
      parameters: { text: "{{fullDocumentText}}", maxLength: 500 },
      expectedOutput: "projectSummary",
      preconditions: { hasDocText: true }, // Depends on Step 2's effect!
      effects: { hasDocSummary: true }
    },
    {
      stepId: 4,
      action: "call_calendar_api",
      parameters: {
        summary: "Sprint Review",
        description: "Review based on high-priority bugs: {{highPriorityBugsList}} and summary: {{projectSummary}}",
        startTime: "{{tomorrow 15:00}}",
        duration: 60
      },
      expectedOutput: "meetingEvent",
      preconditions: { hasBugsList: true, hasDocSummary: true }, // Depends on Steps 1 & 3
      effects: { meetingScheduled: true }
    }
  ]
};

This plan is a complete, executable recipe. Notice the evolution from the NLU's subGoals to the planner's steps. The planner has resolved abstract actions ("fetch_data") into concrete API calls ("call_jira_api"). It has formalized the dependencies using preconditions and effects, creating a verifiable state transition model