Three ways to start work
All three tools save an intent first. They do not execute or sign the underlying
action during the scheduling turn. The task records its instruction, target
App, source thread, owner, and a snapshot of the current user state.
From saved intent to completed run
1. Save
Saving a task captures its intent and execution context. A future run gets the wallet and chain context that existed when the task was created. The selected App must still be available when the task fires. Recurring schedules use the timezone from your settings. Whole-day schedules stay anchored to local wall-clock time across daylight-saving changes. The model does not choose or change your timezone.2. Check the trigger
Time-based tasks become eligible at their scheduled time. Condition tasks periodically call a read tool and compare a value or time window. A false condition is a normal check, not a failed attempt. A condition can expire if it never matches. A recurring watchdog can also use hysteresis. After it fires, the measured value must cross a separate re-arm threshold before it may fire again. This avoids repeated actions while a value remains on the same side of a boundary.3. Claim and run
Before execution, Aomi claims the occurrence with a lease. The lease prevents two workers from running the same occurrence at the same time. Different due tasks may run concurrently, so you should not depend on their relative order. The claim is not an exactly-once guarantee. If execution stops before clean completion, the lease expires and the occurrence can run again. A task is tried at most three times. After that, it is retained as a dead letter for inspection. App tools should therefore make retried side effects safe to recognize or repeat.4. Execute in a fresh thread
Each occurrence creates a child thread with its saved intent and context. The thread follows the same transaction pipeline as an interactive request. It builds, simulates, checks signing authority, and only then submits a transaction. A one-time task is retired after a clean run. A recurring schedule advances to its next anchored occurrence. A recurring condition waits until its re-arm rule is satisfied.Signing is decided when the task runs
Scheduling never grants signing authority. Each occurrence checks the current wallet policy at execution time.- Auto can complete unattended only when a live delegated grant covers the exact wallet.
- Manual can prepare a request for your wallet, but the asynchronous run cannot provide the missing human approval by itself.
- Locked stops before signing.
- A read-only source thread creates read-only task threads. They cannot sign.
Optional confirmation for conditions
A condition can add a confirmation step after its read guard matches. A separate read-only child evaluates the available evidence and must return a clear yes before the action thread starts. An unclear answer, a no, a stall, or a crash fails closed. The task remains eligible for a later check, and the rejected confirmation does not consume a retry attempt.Choosing the right tool
- Use
spawn_threadfor self-contained work that should begin now and should not block the current conversation. - Use
schedule_cronwhen time determines readiness. - Use
wake_on_conditionwhen observable state determines readiness. - Use a foreground child from Multi-threading when the current conversation needs the result before it can continue.
Further reading
Multi-threading
See how parent and child threads preserve context while narrowing authority.
Transaction pipeline
Follow each occurrence from intent through simulation and submission.