Custom Modes and Scheduler: How an AI Agent Works on Schedule Without Human Intervention

AI coding agents have moved from “autocomplete” to “autonomous workers.” But for most tools, the agent lives only while the chat is open. Close the IDE — and it disappears. We at THINKING•OS AI Lab did it differently: in the Tao·Coder platform, the agent can run on schedule, switch between modes, and chain tasks — from server monitoring to publishing analytical reports — fully autonomously.

The Problem: An Agent That Lives Only in Chat

Most AI coding agents (Cursor, Copilot, Claude Code in basic mode) work synchronously: you write a prompt → agent responds → you close the chat. This works for one-off tasks but fails for systematic ones.

Examples of tasks that require autonomy:

• Hourly production server health checks
• Daily code quality audits across repositories
• Automatic remediation of discovered issues
• Regular blog and social media article publishing
• Weekly industry news collection and digest preparation

For such tasks, you need an agent that:

1. Runs on schedule (cron)
2. Switches between specialized modes
3. Chains tasks together (handoff)
4. Works autonomously, without human intervention

TAO·MODES: Declarative Configuration Inside Tao·Coder

TAO·MODES is the custom modes mechanism of the Tao·Coder platform. Boundaries, tools, stages, and exit criteria are described in JSON files. The agent doesn’t “guess” what to do — it follows a formal specification.

Key principle: a mode is a universal constructor for any task. You create a mode for your specific scenario: from a narrow task (checking one endpoint) to a broad one (full feature development cycle). The examples in this article are not pre-installed system modes — they are illustrations of what you can build.

Custom Mode Structure

Each mode is a directory with configuration files:

.taocoder/modes/<mode_id>/
├── mode.json              # Mode configuration
└── stages/
    └── <stage_id>.json    # Stage configuration

mode.json defines:

• id — unique mode identifier
• name — UI display name
• description — user-facing description
• system_prompt — agent’s system prompt
• stages[] — list of stages
• extends — inheritance from another mode

stage.json defines:

• id — stage identifier
• stage_prompt — prompt for this stage
• allowed_tools[] — available tools
• forbidden_tools[] — blocked tools
• default_exit_criteria[] — criteria for transitioning to the next stage
• hooks[] — hooks for business logic

Stages Don’t Have to Be Linear

Important to understand: stages in a mode are not a mandatory pipeline “A → B → C.” The agent can:

• Return to a previous stage — if testing reveals a problem, the agent returns to the implementation stage
• Execute stages cyclically — for example, “write test → run → fix → run again” until green
• Skip stages — if exit criteria are already met

Stages are more like a set of states with different tools and prompts, between which the agent moves as needed.

Example: Server Monitoring Mode

{
  "id": "server_monitor",
  "name": "Server Monitor",
  "description": "Hourly production server health check",
  "system_prompt": "You are an ops agent. Check server state and log issues.",
  "stages": [
    {
      "id": "check_health",
      "stage_prompt": "Check CPU, RAM, disk usage. If anything exceeds 80% — create a task.",
      "allowed_tools": ["execute_command", "read_file", "write_to_file"],
      "default_exit_criteria": [
        {
          "checkType": "all_metrics_below_threshold",
          "threshold": 80
        }
      ]
    }
  ]
}

An agent in this mode:

• Has access only to execute_command, read_file, write_to_file
• Cannot write code or change configuration (no apply_patch)
• Cannot communicate with the user (no ask_followup_question)
• Works autonomously when launched on schedule

Example: Module Refactoring Mode

{
  "id": "refactor_module",
  "name": "Module Refactorer",
  "description": "Module refactoring while maintaining test coverage",
  "system_prompt": "You are a senior developer. Refactor code while preserving behavior and test coverage.",
  "stages": [
    {
      "id": "analysis",
      "stage_prompt": "Analyze the module: find duplication, complex places, SOLID principle violations.",
      "allowed_tools": ["read_file", "search_files"],
      "forbidden_tools": ["apply_patch", "execute_command"]
    },
    {
      "id": "implementation",
      "stage_prompt": "Perform refactoring. Keep the public API unchanged.",
      "allowed_tools": ["read_file", "apply_patch", "execute_command"],
      "forbidden_tools": ["web_search"]
    },
    {
      "id": "testing",
      "stage_prompt": "Run tests. If coverage dropped or tests broke — return to implementation.",
      "allowed_tools": ["execute_command", "read_file"],
      "forbidden_tools": ["apply_patch", "web_search"],
      "default_exit_criteria": [
        {
          "checkType": "all_tests_pass",
          "coverage_threshold": 80
        }
      ]
    }
  ]
}

Note: if tests fail at the testing stage, the agent returns to the implementation stage. This is a non-linear flow — the agent cyclically goes through “refactoring → tests → refactoring → tests” until achieving a green result.

Example: Test Writing Mode

{
  "id": "test_writer",
  "name": "Test Writer",
  "description": "Writing unit tests for a module",
  "system_prompt": "You are a QA engineer. Write unit tests covering edge cases.",
  "stages": [
    {
      "id": "explore",
      "stage_prompt": "Study the module: find public methods, edge cases, dependencies.",
      "allowed_tools": ["read_file", "search_files"],
      "forbidden_tools": ["apply_patch", "execute_command"]
    },
    {
      "id": "write_tests",
      "stage_prompt": "Write unit tests. Cover happy path, edge cases, error scenarios.",
      "allowed_tools": ["read_file", "apply_patch"],
      "forbidden_tools": ["execute_command", "web_search"]
    },
    {
      "id": "run_and_fix",
      "stage_prompt": "Run tests. If a test fails — fix it or the code. Repeat until green.",
      "allowed_tools": ["read_file", "apply_patch", "execute_command"],
      "forbidden_tools": ["web_search"],
      "default_exit_criteria": [
        {
          "checkType": "all_tests_pass"
        }
      ]
    }
  ]
}

Here the run_and_fix stage is cyclic: the agent runs tests, sees failures, fixes them, runs again. The cycle continues until all tests pass.

Modes for Any Task

TAO·MODES is not only about programming. Declarative mode configuration works for any task requiring specialization and autonomy. We use modes ourselves for content work and analytics.

Example: Blog Article Writing Mode

{
  "id": "blog_writer",
  "name": "Blog Writer",
  "description": "Writing and publishing articles for the blog",
  "system_prompt": "You are a content writer. Write articles according to the specification, follow company style.",
  "stages": [
    {
      "id": "research",
      "stage_prompt": "Gather information on the topic via web search. Find facts, figures, examples.",
      "allowed_tools": ["web_search", "read_file", "write_to_file"],
      "forbidden_tools": ["apply_patch", "execute_command"]
    },
    {
      "id": "writing",
      "stage_prompt": "Write the article in Russian and English. Follow the template, use facts from research.",
      "allowed_tools": ["read_file", "write_to_file"],
      "forbidden_tools": ["apply_patch", "execute_command", "web_search"]
    },
    {
      "id": "publishing",
      "stage_prompt": "Publish the article: create astro pages, update blog index, run deployment.",
      "allowed_tools": ["read_file", "write_to_file", "execute_command"],
      "forbidden_tools": ["apply_patch"]
    }
  ]
}

Result: the agent goes through three stages — research, writing, publishing. If a deployment error is discovered during the publishing stage, the agent can return to the writing stage for fixes.

Example: News Collection and Analysis Mode

{
  "id": "news_analyst",
  "name": "News Analyst",
  "description": "Daily industry news collection and analytical digest preparation",
  "system_prompt": "You are an analyst. Collect news, identify trends, write a brief digest.",
  "stages": [
    {
      "id": "collection",
      "stage_prompt": "Collect news from the last 24 hours from specified sources.",
      "allowed_tools": ["web_search", "read_file", "write_to_file"],
      "forbidden_tools": ["apply_patch", "execute_command"]
    },
    {
      "id": "analysis",
      "stage_prompt": "Analyze collected news. Identify key trends, find connections between events.",
      "allowed_tools": ["read_file", "write_to_file"],
      "forbidden_tools": ["apply_patch", "execute_command", "web_search"]
    },
    {
      "id": "report",
      "stage_prompt": "Write an analytical digest. Save in markdown format.",
      "allowed_tools": ["read_file", "write_to_file"],
      "forbidden_tools": ["apply_patch", "execute_command"]
    }
  ]
}

Result: the agent collects news daily, analyzes it, and prepares a digest. You can set a schedule — for example, every weekday at 8:00.

Mode Chains: From Mode to Mode via new_task

Modes can be chained together through the handoff mechanism. When a mode completes its work, it creates a new task (new_task) with artifacts for the next mode.

How It Works

Exit criterion for handoff:

{
  "checkType": "handoff_created",
  "targetMode": "developer",
  "artifactsRequired": ["architecture.md", "api-spec.yaml"]
}

Example chain for issue remediation:

1. Server Monitoring (ops) → detected CPU > 90% ↓ handoff with artifacts: [“metrics.json”, “logs.txt”]
2. Developer (developer) → analyzes logs, creates a fix ↓ handoff with artifacts: [“fix.patch”, “test-results.json”]
3. Tester (qa) → runs tests, verifies the fix ↓ handoff with artifacts: [“qa-report.json”]
4. Operations (ops) → deploys changes to production

The entire chain works autonomously, without human intervention. Each handoff is a new task with new context, which prevents context bloat.

Example chain for content production:

1. Researcher (research) → gathers information on the topic ↓ handoff with artifacts: [“research-notes.md”, “sources.json”]
2. Writer (blog_writer) → writes an article based on research ↓ handoff with artifacts: [“article-ru.md”, “article-en.md”]
3. Publisher (publisher) → publishes the article in the blog ↓ handoff with artifacts: [“published-url.txt”]
4. SMM Specialist (social_publisher) → adapts and publishes to social media

Chains are user configuration. You define which modes participate, which artifacts are passed, and in what order they execute.

Scheduling System: Agent on Schedule

Tao·Coder has a built-in local scheduler that runs in the VS Code extension host. This is not a server mechanism — the scheduler runs locally, without cloud dependency.

How It Works

Schedule storage:

.taocoder/schedules.json

Each workspace has its own schedules.json. Schedules are not synchronized between projects.

Schedule model:

interface Schedule {
  schedule_id: string              // UUID
  task_template: {
    mode_id: string                // built-in or custom mode
    role_mode: string              // developer, architect, ops, debug
    spec: string                   // task specification
    constraints: string[]          // constraints
  }
  recurrence: RecurrencePattern
  next_run: string                 // ISO 8601 UTC
  last_run?: string                // ISO 8601 UTC
  status: "active" | "paused" | "completed" | "cancelled"
  timezone: string                 // IANA timezone
}

interface RecurrencePattern {
  type: "simple" | "cron" | "custom"
  // simple: "every_hour" | "daily_at_09:00" | "weekly_thursday"
  // cron: "0 9 * * 4" (cron expression)
  // custom: { interval_ms: number } | { cron: string }
  pattern: string | { interval_ms: number } | { cron: string }
}

Launch mechanism:

1. setInterval with a check every minute (60,000 ms)
2. If next_run <= now → trigger execution
3. A new task_id is created (not reusing existing)
4. The task template is cloned into a new context
5. After execution, the next next_run is calculated

Template → Multiple Runs

Key principle: each scheduled execution creates a new task. This means:

• Task context doesn’t bloat from previous runs
• Each task is isolated — if one fails, others won’t suffer
• Run history is saved in .taocoder/scheduled_runs/

Exception: self-delay

If the agent uses the self-delay tool (delay itself for N minutes or hours), execution continues in the same task_id. This is not a new scheduled run, but a continuation of the current task.

Autonomous Mode: Working Without Human Intervention

When a task is launched on schedule, the agent receives a system message:

You are running autonomously. Solve the task without user feedback.
If you encounter an issue, attempt to resolve it independently.
Do not ask the user for clarification — proceed with best-effort solution.

Crash Analyst: What If the Agent Gets Stuck

If the agent tries to ask the user (uses ask_followup_question), the system intercepts:

1. Autonomous response: “Continue with the best solution based on available information”
2. The agent continues execution without feedback
3. If the agent doesn’t progress for N steps → escalation (task cancellation + user notification)

Missed Runs Detection

When VS Code starts, the scheduler checks for missed runs:

1. Loads schedules.json
2. For each status === "active":
   • If next_run <now → missed run detected
3. User sees a dialog:

Schedule "Blog Writer" missed its run at 2026-10-10T08:00:00Z.
[Run now] [Skip] [Reschedule]

Stage Hooks: Business Logic Through Configuration

Hooks are a mechanism for adding business logic to stage configuration. Hooks are executed by the bridge layer and integrated into existing tool handlers.

Hook Types

request_approval — request user confirmation:

{
  "name": "require_approval_for_deploy",
  "on": "tool_call",
  "action": "request_approval",
  "params": { "message": "Confirm deployment to production" }
}

require_handoff — block transition if handoff is not completed:

{
  "name": "require_handoff_before_exit",
  "on": "stage_exit",
  "action": "require_handoff",
  "params": { "targetMode": "qa" }
}

log — logging without blocking:

{
  "name": "log_stage_transition",
  "on": "stage_enter",
  "action": "log",
  "params": { "message": "Entering development stage" }
}

Integration into Tool Handlers

Hooks are called in a specific order:

1. Command handler:

   • security check → auto-approval guard → approval hooks → auto-approve flow

2. File write handler:

   • auto-approval guard → approval hooks → auto-approve flow

3. Stage transition handler:

   • Hooks are called BEFORE the stage exit hook is executed
   • If a hook returns cancel: true → stage transition is blocked

Important: hooks NEVER break the runtime. Errors are caught and logged.

Practical Examples

Example 1: Hourly Server Monitoring

Task: check production server state every hour and log issues.

Configuration:

{
  "schedule_id": "hourly-server-check",
  "task_template": {
    "mode_id": "server_monitor",
    "role_mode": "ops",
    "spec": "Check CPU, RAM, disk usage. If anything exceeds 80% — create a task."
  },
  "recurrence": {
    "type": "cron",
    "pattern": "0 * * * *"
  },
  "timezone": "Asia/Novosibirsk"
}

Result: the agent checks the server every hour, logs metrics in .taocoder/scheduled_runs/, creates tasks for problematic cases.

Example 2: Daily Code Quality Audit

Task: every weekday at 9:00, check code quality in the repository.

Configuration:

{
  "schedule_id": "daily-code-audit",
  "task_template": {
    "mode_id": "refactor_module",
    "role_mode": "developer",
    "spec": "Analyze changes from the day, find issues, suggest refactoring."
  },
  "recurrence": {
    "type": "cron",
    "pattern": "0 9 * * 1-5"
  },
  "timezone": "Europe/Moscow"
}

Result: the agent analyzes code every weekday, finds issues, and suggests improvements.

Example 3: Weekly Analytical Digest

Task: every Monday at 8:00, collect news for the week and prepare an analytical report.

Configuration:

{
  "schedule_id": "weekly-news-digest",
  "task_template": {
    "mode_id": "news_analyst",
    "role_mode": "analyst",
    "spec": "Collect news for the week, identify trends, write an analytical digest."
  },
  "recurrence": {
    "type": "cron",
    "pattern": "0 8 * * 1"
  },
  "timezone": "Europe/Moscow"
}

Result: the agent collects news every Monday, analyzes it, and prepares a digest with key trends.

Example 4: Automatic Issue Remediation

Task: if monitoring detects a problem, automatically create a task for the developer.

Chain:

1. Server Monitoring (ops) → detected CPU > 90% ↓ handoff with artifacts: [“metrics.json”, “logs.txt”]
2. Developer (developer) → analyzes logs, creates a fix ↓ handoff with artifacts: [“fix.patch”, “test-results.json”]
3. Tester (qa) → runs tests, verifies the fix ↓ handoff with artifacts: [“qa-report.json”]
4. Operations (ops) → deploys changes to production

The entire chain works autonomously, without human intervention.

Comparison with Competitors

Aspect	Tao·Coder	Claude Code	Cursor	Devin
Scheduling	Local scheduler in VS Code	CLI with -p flag, external cron	None	Cloud-based
Custom Modes	TAO·MODES (JSON configuration)	CLAUDE.md (persistent instructions)	Cursor Rules	None
Autonomous Mode	Crash analyst, self-delay	Hook system	None	Full autonomy
Handoff	Mode chain with artifacts	None	None	None
Non-linear Stages	Yes (return, cycles)	None	None	None
Stage Hooks	JSON configuration	None	None	None
Project Binding	Yes	Yes	Yes	No
Versatility	Any tasks (code, content, analytics)	Limited	None	None

Key Tao·Coder differences:

1. Declarative configuration — TAO·MODES provide formal behavioral guarantees through JSON Schema validation
2. Local scheduler — runs in VS Code, no server required
3. Handoff with artifacts — each handoff passes context through files, not through bloated dialogue
4. Non-linear stages — the agent can return to previous stages and execute them cyclically
5. Versatility — modes work for any tasks: from coding to content work and analytics

What’s Next

TAO·MODES and the scheduling system in Tao·Coder are the foundation for fully autonomous AI agents. We continue to develop the system:

• Server scheduling — for paid features, cron-based launch token issuance
• Multi-agent orchestration — coordination of multiple agents
• Self-healing CI/CD — autonomous agents for automatic pipeline error fixing
• Mode ecosystem expansion — ready-made modes for typical tasks

If you need AI agents that work on schedule and chain tasks together — contact us. We’ll help you set up the system for your tasks.

---

Links:

• AI Agent Orchestration: From Solo Coding to Teamwork
• Bounded Task Context: How an AI Agent Works Within a Task
• TaoCoder Guide: Platform for Autonomous Development
• TaoCoder Economics: The Cost of AI Development

Contacts:

• Telegram: @thinkingos
• Email: info@thinkingos.tech
• Phone: +7 (906) 950-66-95