TaoCoder 3.0.1 and 3.1.0: From Autonomous Agents to Probabilistic Decisions

AI coding agents have moved from “autocomplete” to “autonomous workers.” But autonomy without control is chaos. In versions 3.0.1 and 3.1.0, we at THINKING•OS AI Lab solved two fundamental problems: how an agent works on a schedule without human intervention and how it makes decisions under uncertainty. The result — 1000+ steps without context loss, a probabilistic JEV decision model, and a compact prompt architecture.

The Problem: Agents Live Only in Chat and Can’t Make Decisions

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.

Two key problems:

1. The agent disappears when you close the IDE. Fine for one-off tasks. Unacceptable for systematic ones. Examples of tasks requiring autonomy:

   • Hourly production server health checks
   • Daily code quality audits in repositories
   • Automatic problem remediation
   • Regular blog and social media publishing
   • Weekly industry news collection and digest preparation

2. Agents can’t make decisions under uncertainty. When a task has no clear solution, the agent either hallucinates or gets stuck. You need a mechanism that evaluates confidence in a decision and chooses a strategy: act independently, request confirmation, or defer the decision.

For such tasks, you need an agent that:

1. Works on a schedule (cron)
2. Switches between specialized modes
3. Chains tasks together (handoff)
4. Makes probabilistic decisions based on context
5. Works autonomously without human intervention

Version 3.0.1: Autonomy and Deep Memory

Version 3.0.1 (2026-10-11) focuses on autonomous agent operation and solving the context problem.

TAO·MODES: Declarative Agent Configuration

TAO·MODES is the custom modes mechanism in TaoCoder. 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).

Custom mode structure:

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

mode.json defines:

• id — unique mode identifier
• name — UI 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

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 problems.",
  "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
        }
      ]
    }
  ]
}

The 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 scheduled

Stages don’t have to be linear. The agent can:

• Return to a previous stage — if it finds a problem during testing
• Execute stages cyclically — e.g., “write test → run → fix → run again”
• Skip stages — if exit criteria are already met

Scheduling System: Agent on a Schedule

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

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"
  pattern: string | { interval_ms: number } | { cron: string }
}

Launch mechanism:

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

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 aren’t affected
• Run history is saved in .taocoder/scheduled_runs/

Autonomous Mode: Working Without Human Intervention

When a task is scheduled, 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 analyzer: 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. Agent continues execution without feedback
3. If the agent doesn’t progress for N steps → escalation (task cancellation + user notification)

Missed run 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 a run at 2026-10-10T08:00:00Z.
[Run now] [Skip] [Reschedule]

Deep Memory Architecture: 1000+ Steps Without Context Loss

One of the fundamental problems with AI agents is unbounded context growth. When an agent works for a long time (hundreds of steps), context bloats, tokens grow, and the model starts hallucinating.

Solution in version 3.0.1: deep memory architecture that allows the agent to work 1000+ steps without context loss.

How it works:

1. Bounded context — history doesn’t accumulate in the dialog but is compressed into an external Task Context. Context stays constant size, tokens don’t grow.
2. Update cycle — every N steps, the system extracts key information from history and writes it to Task Context. History is cleared, but knowledge is preserved.
3. Knowledge migration — when creating a new task, knowledge from previous tasks migrates to the new context. The agent doesn’t start from scratch.

Result: the agent can work for hours, performing hundreds of steps, without quality degradation. Context remains compact, tokens don’t grow.

Quantized Model Optimization

Version 3.0.1 added support for quantized models Qwen 3.6 (35B) and Qwen 3.8 (37B). This allows running the agent on local models with minimal hardware requirements.

Quantized model advantages:

• Work on consumer hardware (16-32 GB RAM)
• No internet connection required
• Zero token cost
• Full data privacy

Limitations:

• Lower quality compared to frontier models
• Slower generation
• Require careful prompt tuning

Solution: TaoCoder automatically selects the model for the task. Simple tasks (refactoring, tests) — quantized models. Complex tasks (architectural design, code review) — frontier models.

Version 3.1.0: Probabilistic Decisions and Prompt Architecture

Version 3.1.0 (2026-10-19) focuses on decision-making under uncertainty and prompt architecture optimization.

JEV Decision Model: Fast “Judge” for Agent Actions

JEV is a decision model of the “System One” class — fast, structured responses with probabilities instead of text generation. Created by TypeSafe AI specifically for quick structured decisions.

Key properties:

Property	Value
Text generation	No. The model doesn’t write text — only structured answers
What it returns	Probabilities for typed questions
Latency	70–500 ms (orders of magnitude faster than LLM judges)
Context	32k tokens
Price	Input tokens only (~$0.042/M), output is free
Response format	Deterministic, convenient for machine processing

Three question primitives:

Primitive	What it does	Answer
Choice	Selection from 2–255 options	Probability of each option + confidence
Noul	Probability of statement truth	Number 0–1
Score	Position on an ordered scale of 2–10 levels	Probabilities by levels + confidence

Integration in TaoCoder:

JEV is connected at four points:

1. Terminal Guard — every command passes through two-stage classification. Local policy (whitelist) handles safe commands for free. Unknown commands go to JEV as a noul question: “is it safe to execute this command?” If probability ≥ threshold → command executes. Below threshold → requires user approval.

2. taocoder_jev_validate tool — the agent can ask JEV a structured question itself. The agent receives raw probabilities without interpretation — the agent decides what to do with them.

3. Stage hooks — in stage configuration, you can declare a jev_validate hook that fires on stage_exit. Example: “before exiting the development stage, ask JEV if exit criteria are met.”

4. Settings UI — full pipeline: enable/disable, provider selection (TypeSafe/OpenRouter/custom), API key in SecretStorage, confidence threshold slider, Terminal Guard toggle.

Design principles:

• Fail-open — if JEV is unavailable, timeout expires, or response fails to parse — the check is skipped with logging. The agent is never blocked by an external service.
• Accept when confident, escalate when unsure — confidence above threshold → verdict accepted automatically; below → escalation to human or stronger model.
• Token economy — only what can’t be solved locally goes to the model (e.g., unknown terminal commands).
• No interpretation — JEV returns probabilities; interpretation and decisions are always made by the party above (guard code, agent, human).

REST API Server: Built-in Connections Without MCP

Version 3.1.0 added a built-in REST API Server that allows the agent to connect to external APIs without using MCP (Model Context Protocol).

How it works:

1. User creates a REST API connection configuration:

{
  "id": "github_api",
  "name": "GitHub API",
  "base_url": "https://api.github.com",
  "auth": {
    "type": "bearer",
    "token_env": "GITHUB_TOKEN"
  },
  "endpoints": [
    {
      "name": "list_repos",
      "method": "GET",
      "path": "/user/repos",
      "params": {
        "per_page": 100
      }
    }
  ]
}

2. Agent uses the rest_api_call tool to invoke the API:

const repos = await rest_api_call({
  connection_id: "github_api",
  endpoint: "list_repos"
});

3. TaoCoder automatically adds authorization headers, handles errors, and returns the result.

REST API Server advantages:

• No MCP required — agent works with APIs directly
• Centralized connection management
• Automatic authorization via environment variables
• Support for any REST API

Limitations:

• REST API only (not GraphQL, not WebSocket)
• Requires pre-configured connections

Secrets Management: Centralized Secret Storage

Version 3.1.0 added centralized encrypted secret storage. Secrets (API keys, tokens, passwords) are stored encrypted and accessible to the agent through tools.

How it works:

1. User adds a secret:

taocoder secrets add GITHUB_TOKEN "ghp_xxxxxxxxxxxx"

2. TaoCoder encrypts the secret and saves it to .taocoder/secrets.json:

{
  "secrets": [
    {
      "id": "github_token",
      "name": "GITHUB_TOKEN",
      "encrypted_value": "aes256:xxxxxxxxxxxx",
      "created_at": "2026-10-19T10:00:00Z"
    }
  ]
}

3. Agent uses the secret via environment variable:

const token = process.env.GITHUB_TOKEN;

4. TaoCoder automatically substitutes the decrypted value.

Secrets Management advantages:

• Secrets are encrypted (AES-256)
• Centralized management
• Automatic substitution into environment variables
• Support for rotation and revocation

Security:

• Secrets stored locally (not in the cloud)
• File-level encryption
• Access only for authorized agents

Prompt Architecture: Compact Kernel Prompt

Version 3.1.0 optimized prompt architecture to reduce token consumption. The key idea — a compact kernel prompt that stays at the beginning of every request and gets cached by the LLM provider.

How it works:

1. Prompt is split into parts:

   • System prompt (doesn’t change)
   • Task Context (changes rarely)
   • History (changes frequently)

2. TaoCoder optimizes part order:

   • System prompt — always at the beginning (cached)
   • Task Context — after system prompt (cached)
   • History — at the end (not cached)

3. When the agent makes a new request, the system checks which parts are already cached and reuses computations.

Result:

• Token cost reduction: 30-40%
• Generation speedup: 20-30%

Technical details:

interface PromptArchitecture {
  system_prompt: string;      // Cached
  task_context: string;       // Cached
  history: string[];          // Not cached
  current_request: string;    // Not cached
}

// Optimized order:
// [system_prompt] + [task_context] + [history] + [current_request]

Compact kernel prompt:

TaoCoder uses a compact kernel prompt — the system prompt is compressed to minimal size without losing meaning. This reduces token costs and speeds up generation.

New Chat Design: Sidebar Panel

Version 3.1.0 introduced a new chat design as a sidebar panel. Now the agent works in a side panel, not a separate window.

Advantages:

• Agent is always visible while working with code
• No need to switch between windows
• Convenient for multitasking

User Notes: User-Only Notes

Version 3.1.0 added the ability to add user notes to tasks. Notes are saved in Task Context but are only visible to the user — the agent does not see them.

How it works:

1. User adds a note:

taocoder notes add "Use Redis for session caching"

2. Note is saved in Task Context:

{
  "notes": [
    {
      "id": "note_001",
      "text": "Use Redis for session caching",
      "created_at": "2026-10-19T10:00:00Z",
      "author": "user",
      "visible_to_agent": false
    }
  ]
}

3. User sees the note in the interface. The agent does not have access to user notes.

Advantages:

• Users can keep personal reminders and context
• Notes persist between sessions
• User notes don’t affect agent behavior

Memory Optimization: 10+ Concurrent Sessions

Version 3.1.0 optimized memory management, allowing 10+ concurrent sessions without performance degradation.

How it works:

1. Each session is isolated — has its own Task Context
2. Sessions don’t share memory — each session uses its own memory
3. TaoCoder automatically manages memory:
   • Unloads inactive sessions
   • Loads active sessions on demand
   • Optimizes RAM usage

Result:

• 10+ concurrent sessions without degradation
• Automatic memory management
• Session isolation — if one session fails, others aren’t affected

Version Comparison: What Changed

Mechanism	Version 3.0.1	Version 3.1.0
TAO·MODES	✅ Custom modes	✅ Improved documentation
Scheduled Execution	✅ Cron-based scheduling	✅ Improved missed run handling
Deep Memory	✅ 1000+ steps	✅ Optimized
Quantized Models	✅ Qwen 3.6/3.8	✅ Added support for new models
JEV Decision Model	❌	✅ Fast “judge” for agent actions
REST API Server	❌	✅ Built-in connections
SecretExtractor	❌	✅ Auto-extraction from MCP/REST configs
OAuth 2.0	❌	✅ Secure authentication
Prompt Architecture	❌	✅ Compact kernel prompt
New Chat Design	❌	✅ Sidebar panel
User Notes	❌	✅ User-only notes (agent doesn’t see them)
Memory Optimization	❌	✅ 10+ concurrent sessions

2026 Industry Trends: How TaoCoder Fits the Mainstream

TaoCoder versions 3.0.1 and 3.1.0 hit all key AI coding agent trends for 2026:

1. Persistent project context — agents store long-term project memory. TaoCoder solves this through Task Context and deep memory architecture.

2. Multi-agent architectures — orchestration of specialized agents. TaoCoder implements this through TAO·MODES and handoff between modes.

3. Autonomous execution — agents work for minutes/hours as background jobs. TaoCoder ensures this through scheduled execution and autonomous mode.

4. MCP as connection standard — TaoCoder supports MCP and also adds REST API Server for working without MCP.

5. IDE+CLI+cloud three-layer stack — TaoCoder works in VS Code (IDE), supports CLI commands, and can integrate with cloud services.

6. Tool definitions consume context — the problem of cost and latency. TaoCoder solves this through role modes (−30–50% tokens) and compact kernel prompt architecture.

TaoCoder vs Competitors Differentiators

Axis	TaoCoder	Competitors (Cline, Kilo, Continue, Cursor)
Memory	Structured external memory (Task Context Kernel)	Growing chat history
Control	Role modes with stage-gated execution	Write access by default
Cost	Optimized for flash models (10-30x cheaper)	Frontier models (expensive)
Long tasks	1000+ steps without context loss	Degradation after 100-200 steps
Parallelism	Parallel task execution with per-task isolation	Single sessions
Knowledge migration	Knowledge migration between tasks	No migration
Customization	Custom role modes for non-coding workflows	Code only

What’s Next

We continue developing TaoCoder. In the pipeline:

• Server-side 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
• Expanded mode ecosystem — ready-made modes for typical tasks
• Cloud LLM integration — support for new providers

Conclusion

TaoCoder versions 3.0.1 and 3.1.0 are not just updates. These are fundamental changes in how an AI agent works with tasks, makes decisions, and manages context.

Key results:

• Agent works on a schedule and chains tasks together
• Agent makes probabilistic decisions based on context
• Agent works 1000+ steps without context loss
• Enterprise project cost: $30–50 on flash models
• 1 developer with TaoCoder = team of 3–5 at 1/10 the cost

If you need AI agents that work autonomously, make decisions, and scale — contact us. We’ll help you set up the system for your tasks.

---

Links:

• Custom modes and scheduler: how an AI agent works on a schedule
• Bounded Task Context: how an AI agent works within a task
• TaoCoder guide: platform for autonomous development
• TaoCoder economics: how much AI development costs

Contacts:

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