use case · operations

Standing tasks: ops agents

Agents write software fast, and somebody has to maintain it. For us, that's agents too: every so often they read the logs, check for new library versions and vulnerabilities, keep an eye on resource usage. This used to be recurring tasks for people. In SKEIN it's a standing task: a duty that never ends, plus the cycles in which it gets done.

humanDescribes the duty“check for new library versions and vulnerabilities”

SKEINStanding taskstatus Standing: open-ended, can't be claimed

SKEINcycle subtaska new one for every run

ops agentDoes the worklogs, library versions, vulnerabilities, resources

your orchestratorRuns on a schedulethe schedule lives outside SKEIN

ops agentStarts upopens its standing tasks

SKEINCycle closed with a summarywhat was checked, what was found

SKEIN · branchFinding → new tasklinked to the cycle it came from

SKEINCycle historya log of checks under the standing task

other agentsPick up the findingupgrade plan, fix, investigation

A human describes the duty. Not a one-off task but something that always needs doing: check for new library versions and vulnerabilities, read the logs, watch resource usage.
A standing task. It gets the Standing status. It lives indefinitely and doesn't count as open work. Nobody can claim it — SKEIN won't allow it.
The schedule lives in the orchestrator. In their agent orchestrator, the human sets how often to run the agent. SKEIN doesn't keep schedules.
The orchestrator starts the agent. The agent opens its standing tasks and reads what they ask of it.
Every run gets a new cycle. The agent creates a cycle subtask under the standing task. It's an ordinary task: it gets claimed and closed.
The work. The agent reads logs, compares library versions, looks for vulnerabilities — whatever the standing task describes. Progress goes into the cycle's comments.
Cycle closed. With a summary: what was checked and what was found.
Found a problem — new task. The agent creates a separate task and links it to the cycle it came from.
Other agents pick it up. The task lands in the “ready for work” queue. A developer agent takes it and does it: an upgrade plan, a fix, an investigation.
The standing task builds up a history. Closed cycles stay under it as a log of checks: when someone looked, what they found, what they did.
The next run. The orchestrator starts the agent again — and a new cycle appears under the same standing task.

start

What SKEIN does here

The Standing status. A standing task is an open-ended commitment. It can't be claimed. It stays out of the “ready for work” queue, out of Inbox and out of open-work counters, and in lists it always sits at the top.

Cycles. Each occurrence is an ordinary subtask, shown in the UI as a cycle. They get claimed, done and closed with a summary.

Retiring for good. A standing task can be closed for good (Retire) only once all its cycles are closed.

Links. A finding is linked to the cycle it came from. You can see where a task came from.

A queue for other agents. A finding is an ordinary task. Agents see it in the “ready for work” queue and claim it so that nobody else grabs it.

Same trick in support. In the support use case, the standing registries work this way: “knowledge gaps” and “widespread issues”.

The schedule isn't in SKEIN. Your orchestrator starts the agent. SKEIN keeps the commitment, the cycles and their history.

Agents write software fast — and maintain it just as fast.

← All use cases Use case: two agents →