Execution & Automation

An operation with a known owner

A capability describes an operation the system can perform. A provider implements that capability on a node. Instead of requiring every caller to know where the implementation lives and how to invoke its internals, LOOM resolves the request through those declared relationships.

The request has typed inputs and an actor. Policy determines whether that actor can make the call in the relevant scope. Routing selects the provider, and the result can be recorded and inspected independently of the terminal or agent that initiated it.

This is an execution boundary, not a claim that every shell command should be a new registered capability. Ordinary source editing remains ordinary development. Capabilities are useful where a shared system operation needs an explicit contract, ownership and history.

Events preserve durable changes in state. Messages carry information between components. Logs help explain what the implementation did. Keeping those roles separate prevents a line of terminal output from becoming the only account of an important operation.

Several ways to start work

Manual requests, event-driven rules and schedules can all initiate work. A scheduled occurrence is a particular trigger, an invocation is a particular request, and a job is a particular execution. Their identities make it possible to see whether a timer fired, whether its request was admitted, and whether the resulting work finished.

The source includes five-field cron schedules with an explicit timezone, as well as other schedule forms. Calendar calculations produce durable UTC occurrences from the selected local time. Spring-forward gaps are skipped; a repeated fall-back local minute is not a reason to run the same daily work twice. Previewing upcoming occurrences is separate from enabling execution.

For example, a research-sync project might request a supported maintenance capability at 30 2 * * * in Europe/Amsterdam. That is an illustrative policy, not an enabled schedule on this site. The operator still needs the capability, its input, authorized identity and appropriate timeout and concurrency behavior.

Missed occurrences also need defined behavior. The calendar implementation advances beyond the current time instead of blindly replaying every missed minute. A laptop reconnecting after a week should not accidentally create a week's worth of overlapping work.

Background work has its own lifecycle

LOOM workers perform recurring internal work such as processing queues or maintaining projections. Their policies include manual, interval and daily-local modes. Worker policies are not merely aliases for the capability scheduler, even when both involve clocks.

A worker can be registered while scheduling is disabled. A healthy daemon can coexist with a disabled optional processor, a retryable job failure or a backlog. The useful question is not just “is LOOM running?” but “which occurrence and operation are we looking at, and what happened to it?”

In the application workflow, that same distinction matters when a process starts before it becomes ready. Installation, readiness and public endpoint provisioning have separate evidence. A supported resume continues a partial operation from its recorded state; it is not a universal guarantee that any arbitrary side effect can safely be retried.

Scheduling an operation is not scheduling an agent

A model-driven task has more moving parts: the agent identity, instructions, working directory, model runtime, tool access, conversation state and where its result should go. LOOM's capability scheduler does not acquire all of that simply because Hermes is installed on the same machine.

Hermes native cron remains owned by Hermes. It is not automatically registered in LOOM's job history or governed by LOOM's schedule controls. The planned direction is a bounded LOOM-owned adapter for agentic runs, with project-specific declarations, explicit identity, concurrency and failure reporting.