Initiatives and Tasks

A task is the durable business record of work. It is distinct from the temporary worker process that executes it and from any individual attempt.

Task Information

A useful task identifies:

• the owning profile or department;
• the desired outcome;
• the current status;
• dependencies;
• execution mode;
• attempt limits;
• blockers;
• expected artifacts; and
• evidence used to verify completion.

Initiatives

Use an initiative to group related outcomes while keeping each executable task bounded. Avoid a single enormous task whose success cannot be verified. Child work should have clear stopping points and dependencies rather than relying on sequence hidden in prose.

Dependencies

Dependencies can require another task’s success, completion, or artifact. Oblive rejects self-links and dependency cycles. A dependent task becomes runnable only when its requirements are satisfied. If required work in another task tree fails, Oblive creates one recovery review instead of leaving the dependent blocked forever. Same-department recovery stays with that department; recovery across departments is coordinated by Operator. The dependent resumes after the review closes and uses its recorded result to decide how to proceed.

Attempts and Retries

Each attempt is preserved. A retry does not overwrite the failed or timed-out attempt, and only the latest retryable attempt can be retried within the configured limit.

Tasks expose two run counts: total runs is the complete attempt history, while consumed runs is the number charged to the task budget. A run that stops cleanly for human input or action approval stays in history but refunds its consumed run credit. Failures, timeouts, and invalid output remain charged. Initiative and task budgets default to 12 consumed runs; research, review, and learning budgets default to 6. Each run request still has its independent three-attempt retry ceiling. Cost-denominated task caps are rejected until runtime usage has a real billing meter; token and tool usage remain observable but are not treated as currency.

The task page keeps this history in a compact run ledger. Open a run to review its agent, mode, status, outcome summary, artifacts or evidence, timing, and token/tool usage. The owner view is a deliberately safe projection: execution prompts, runtime capabilities, worker leases, and workspace or log storage locations are not exposed. Recorded output artifacts open in the inline file viewer; Oblive resolves their run-owned object internally and supports preview, source, copy, and download without sending the browser to a worker filesystem path.

Select View context from a run to inspect the files that were available when that attempt started. The searchable tree includes instructions, selected skills, organization Context, safe integration inventory, learned lessons, and retained prior-attempt files when the run received them. Availability records the run’s boot boundary; it does not claim that the agent opened or used every file. New runs retain their mutable organization Context as immutable run-owned bytes. For an older run, a changed or missing organization file appears as Unavailable instead of showing newer content under an old run.

Transport wakeups may be duplicated, but the worker rechecks durable state before starting an attempt. This prevents a duplicate notification from becoming duplicate work.

Retryable failures use exponential backoff from 5 seconds up to 5 minutes. A stale heartbeat is closed together with its request and task state; an exhausted final attempt fails the task instead of leaving it running. Organization and profile concurrency limits are checked under one serialized admission boundary. Capacity deferral creates no attempt and consumes no run credit.

While backoff is active, the task page shows Waiting to retry and the scheduled next attempt. The timed-out or failed run remains in the ledger with its concrete error. A retryable failure still counts as an execution attempt; waits for human input or action approval continue to refund their consumed run credit.

Coordination tasks may replan up to three times. If another amendment is needed, Oblive asks once for a human decision. An approved final amendment is recorded as the task’s single override; a later attempt to amend again fails cleanly rather than repeatedly asking or stalling the task.

Completion Checks

Acceptance criteria are optional as a product decision: a task may use an empty criteria list when a successful operation is already sufficient evidence. This is useful for self-verifying work such as a bounded integration smoke test. If proving that one exact connector call occurred matters, the task can declare that call as a formal check without adding another agent run.

Oblive supports three deterministic criteria:

These checks run in the backend from synchronized file bytes and sanitized worker receipts. The agent cannot mark them passed by writing a persuasive summary. Text, metric, and artifact criteria remain available as human-readable expectations, but do not gate completion or start another run. When judgment must gate downstream work, use a separate review task with a clear evidence boundary.

The first failed completion evaluation schedules one automatic repair when run budget remains. A repeated failure opens one calm Human Inbox repair request instead of looping. That post-execution human repair does not refund the completed run: the work already ran. If no run credit remains, the task fails with the retained completion report.

Waiting for a Human

When execution needs information or approval, the task moves to a human-waiting state. Answering the item advances the task version and queues fresh execution rather than reviving an expired process. Human waits do not consume the task’s aggregate run allowance.

Cancellation

Cancelling a task also cancels its unfinished child work, queued requests, active runs, open questions, and actions that have not started. Completed child records and already executing or uncertain actions remain visible as history. A task waiting on another task’s completion may continue after that prerequisite is cancelled; requirements for success or an artifact remain blocked.

Completion

Completion should include a concise outcome, evidence, artifacts, blockers that remain, and useful next actions. The task page shows one calm completion state and expands individual checks only when needed. It does not expose internal receipt, repair-item, workspace, or run identifiers.

A task run can synchronize at most 100 changed files beneath its declared output roots. The worker validates the complete set before uploading any file, so 101 files fail as one deterministic non-retryable output error rather than producing a partial result. A run is not successful until validated workspace output has been synchronized.