Self-Generated Tasks and Goals

This is where things start to get interesting.

Once an agent can manage its own memory, the next leap is letting it create its own tasks and goals. Instead of only doing what it is told, the system begins to notice problems, gaps, and opportunities on its own - and decides to work on them.

What Self-Generated Tasks Look Like

The examples are concrete:

The agent notices recurring errors in the infrastructure logs. Rather than waiting to be asked about them, it creates a task to investigate the root cause and begins gathering the relevant context.

The agent observes that certain categories of questions consistently produce low-confidence answers. It generates a goal to gather more data in that area, identifies which memory gaps are responsible, and begins filling them.

The agent detects that a pattern it has relied on for weeks has stopped holding. It initiates a review, generates critique events for the affected memories, and flags the change for attention.

The Goal type in the system already has the structure needed to represent self-generated work. A goal has a horizon (micro through meta), status, progress tracking, and links to the memory IDs that motivated it:

// packages/core-types/src/goal.ts

export type GoalHorizon = 'micro' | 'short' | 'mid' | 'long' | 'meta'
export type GoalStatus = 'active' | 'completed' | 'stalled' | 'cancelled' | 'deferred'

export interface Goal {
  readonly goalId: string
  // NOTE: article omits createdAt field present in source: readonly createdAt: string;
  readonly description: string
  readonly horizon: GoalHorizon
  readonly priority: number
  readonly progress: number
  readonly status: GoalStatus
  readonly parentGoalId?: string
  readonly associatedMemoryIds: ReadonlyArray<string> // what memories motivated this
  readonly subgoals: ReadonlyArray<string>
}

export interface GoalProgressEvent {
  readonly goalId: string
  readonly progressDelta: number
  readonly completedSubgoals: ReadonlyArray<string>
  readonly nextAction?: string
  readonly sourceExperienceId?: string // what triggered the progress
}

The associatedMemoryIds field is key: when the agent creates a goal, it links it to the memories that motivated the goal. This creates an auditable chain - you can trace any self-generated task back to the observations that triggered it. That traceability is what makes self-directed agent behavior debuggable rather than opaque.

The Shift from Reactive to Proactive

In each case, no human prompted the action. The agent observed something in its environment or its own performance, concluded that action was warranted, and acted.

This shifts the AI from being purely reactive to becoming proactive. It stops waiting for instructions and starts taking initiative based on what it observes. The human oversight role changes - rather than directing every task, you are reviewing what the agent decided to pursue and why.

Why This Depends on Everything Before It

Self-generated tasks require the full stack built across this series. Persistent memory to notice patterns over time. Trust scoring to know where the agent's own performance is weak. World models to predict which signals are actually meaningful. Without those foundations, an agent has no basis for deciding which observations are worth acting on.

This is one of the most important steps toward building agents that feel genuinely intelligent - not because they were told to do something clever, but because they decided to.