Agent never stop

Agent Never Stop

One-line trigger: Say "Start Polling" "Don't Stop" → Enter a frontend autonomous loop Core architecture: The agent layer (this session) performs its own reasoning loop without relying on any background daemon process

---

👑 Full Delegation

Operate autonomously without requiring approval at every step. Make decisions, execute actions, and report results according to predefined rules.

Every iteration must produce valuable output — analysis, judgment, or execution. Idle cycles are prohibited.

---

⛔ Fundamental Rules

1. Do not wait for user instructions. Make decisions, execute actions, and report results according to predefined rules.
2. Scan the full picture every iteration. Inspect relevant data sources based on the task type.
3. Call tools directly. If an action is needed, invoke the appropriate tool without asking for permission.
4. Produce output every iteration. Even if nothing changes, provide analysis and conclusions. Empty loops and meaningless heartbeats are prohibited.
5. Stop and report on failure. If permission issues, tool invocation failures, or unexpected errors occur, immediately stop the loop and report the issue. Do not silently retry or attempt workarounds.
6. Check current state first. The first step of every iteration is to retrieve the current state of the target entity to avoid making decisions based on stale memory.

---

I. Polling Loop Architecture (Only Method: Foreground Session Blocking Mode)

Core Pattern: Reason → Block and Wait → Reason → Block and Wait → ...

Session Layer (Agent):

  ① [Pre-check] Retrieve current state (database/API/file)
  ② Fetch latest data
  ③ Reason and analyze (condition detection, signal evaluation, decision making)
  ④ If necessary: execute actions
  ⑤ Report results to the user
  ⑥ terminal("sleep N && echo go", timeout=N+60)   ← Foreground blocking wait
  ⑦ After sleep completes → return to ①

Key Rules

• No logic is executed inside the waiting tool. It must contain only sleep N && echo go.
• All analysis, decision-making, and tool invocations must occur at the session layer.
• Foreground terminal execution blocks the reasoning chain. During the block period, no reasoning, data retrieval, or responses occur. It is pure waiting.
• Foreground terminal() timeout hard limit = 600 seconds (10 minutes), therefore a single N must not exceed 600.
• Longer wait periods must be split into multiple cycles: reason → terminal sleep → next reasoning cycle.
• time.sleep() inside execute_code is prohibited (300-second limit is too restrictive).
• background=true and notify_on_complete are prohibited (they do not block the reasoning chain).

Waiting Method (Only Valid Method)

Wait Duration	Method	Command
Any duration ≤ 1800s	terminal("sleep N && echo go", timeout=N+30) in foreground blocking mode	Only valid method

All waiting must be blocking. There is no "background polling" mode.

Note: The default maximum foreground timeout for terminal() is 600 seconds. It can be increased to 1800 seconds (30 minutes) via the environment variable TERMINAL_MAX_FOREGROUND_TIMEOUT=1800.

Recommended Frequencies

Scenario	Recommended Interval	Description
High-frequency monitoring (real-time response required)	30–60s	State-sensitive scenarios
Medium-frequency inspection	300–600s (5–10 min)	Routine status checks
Low-frequency background tasks	600–1800s (10–30 min)	Overnight or long-duration tasks

---

II. Data Acquisition

Customize according to task requirements. Example data source patterns:

Method	Tool / Function
HTTP API	web_extract(urls=[...])
Search	web_search(query)
Database	Query inside execute_code
File Reading	read_file(path)
MCP Server	mcp_xxx_*()
Browser	browser_navigate(url) → browser_snapshot()

Define the specific data sources when the task starts.

---

III. Decision-Making and Execution

Decision logic is defined when the task is initialized. Generic structure:

For each iteration:

  ① Information retrieval or data collection
  ② Condition evaluation (rules / thresholds / signals / keywords)
  ③ If a signal exists → execute action
  ④ If no signal exists → record status
  ⑤ Report → wait → next iteration

---

IV. Notes

1. Hot rule updates. After task rules are modified, the next reasoning iteration automatically uses the updated rules without requiring a restart.