How Autopilot Enables Agents to Start Work Automatically on Schedule

This piece analyzes Multica’s Autopilot, a component that lets agents run tasks without manual triggers. Earlier articles covered manual activation methods (issue assignment, @mention, chat). Autopilot solves the need for periodic, time‑ or event‑driven work such as weekly stand‑ups, nightly clean‑ups, or PR‑based code reviews.

Autopilot mental model

Autopilot consists of three parts: Trigger (when to run), Execution Mode (how to run), and Agent (who runs it). The trigger can be a cron schedule (standard 5‑field expression with minute granularity and IANA time zone, e.g., Asia/Shanghai) or a webhook from external systems like GitHub PR events.

Execution modes: create_issue vs run_only

Multica documentation recommends starting with create_issue mode. The code in server/internal/service/autopilot.go shows a switch on autopilot.ExecutionMode:

switch autopilot.ExecutionMode {
case "create_issue":
    // create an issue with title interpolating {{date}}
    s.dispatchCreateIssue(ctx, autopilot, &run, triggerTimezone)
case "run_only":
    // enqueue a task directly, no issue created
    s.dispatchRunOnly(ctx, autopilot, &run)
}

create_issue creates an issue whose title contains the {{date}} placeholder, interpolated to a UTC date (e.g., 2023-09-15). The issue appears on the board, preserving history, comments, and status exactly like a manually assigned issue.

run_only skips issue creation and enqueues a task directly; the run is only visible in Autopilot’s execution history.

The author argues that create_issue is preferred for observability: each run becomes a visible issue, allowing lifecycle tracking, commenting, and failure detection. run_only is “silent” – failures may go unnoticed for weeks, making it less reliable in production. Multica therefore defaults to create_issue based on real‑world experience.

Placeholder validation

In create_issue mode, only the {{date}} placeholder is allowed in the issue title. Any other {{...}} pattern is rejected at creation time, preventing silent misspellings (e.g., {{daten}}) that would otherwise produce a malformed title like "{{daten}} standup".

This defensive design follows Multica’s broader philosophy: "fail explicitly rather than degrade silently," consistent with earlier series on failure classifiers and skill injection paths.

Scheduler tick and precision trade‑off

The scheduler wakes up every 30 seconds (default TickInterval = 30 * time.Second) to evaluate due plans. It uses robfig/cron/v3 to parse cron expressions and compute the next run time. Because the tick interval is 30 seconds, the worst‑case delay for a cron job is also 30 seconds.

This granularity is acceptable for tasks like weekly stand‑ups or nightly clean‑ups, but insufficient for second‑level precision requirements. The parser only supports minute‑level fields, deliberately capping precision to minutes to avoid unnecessary load from sub‑second ticks.

The full loop is: front‑end config → store in database → scheduler tick → ComputeNextRun → dispatch ( dispatchCreateIssue or dispatchRunOnly) → task queued → WebSocket broadcast → front‑end shows agent start.

Conclusion: six engineered properties of an Agent

Workstation (runtime) – agent runs on your machine, heartbeat determines presence.

Brain (adapter) – 13 tools unified under a Backend interface.

Lifecycle (task state machine) – three‑tier timeout distinguishes "slow" vs "dead", with automatic failure attribution.

Skill (skills) – a good prompt becomes a team asset.

Squad (routing) – tasks routed to a team rather than an individual for stability.

Autonomy (autopilot) – agents start work on schedule, handling standing orders.

These components form the technical backbone behind the claim "2 humans + 10 agents ≈ 20 people output," turning the product vision of agents as colleagues into a concrete, runnable system.