Salix

Loops

A Loop lets an agent do background work 24/7: watch an inbox, a repository or a feed, and act when something changes. A Loop needs no always-on sandbox, and it does not wake the agent's main loop unless it has to.

How a Loop runs

1. The agent writes the Loop as a program in C.
2. Spinfoam, Salix's server-side eBPF runtime, compiles the program to eBPF.
3. Salix schedules the Loop on the cluster, next to its agent.

Spinfoam's JIT compiler is formally verified, and it generates memory-safe code. A Loop uses a few to tens of kilobytes of memory, so an agent can keep Loops running for as long as it needs them.

Decisions without a large model

A Loop can call fast decision models, such as Jev. With them, a Loop classifies external data and state (for example, whether a new email needs you) without a call to a large language model.

When a Loop finds something that needs the agent, it notifies the agent. Only then does the agent's main loop run, and only then does it use model tokens.

What a Loop can do

A Loop can call only a fixed list of capabilities: read tools, device and environment tools, web requests, your connected apps, and a notification to its agent. A Loop acts with the authority of the person who created it, and nothing more.

• Events: other systems can send events to a Loop through the API or through a secret webhook URL for that Loop.
• State: a Loop saves a checkpoint, and gets it back when it starts again.
• Limits: a Loop can wake its agent a limited number of times in ten minutes. A Loop that stays at that limit for an hour pauses.
• Failures: after a fault, Salix starts the Loop again from its checkpoint, at most three times an hour. After that, the Loop stops and tells its agent.