swarm: subagent-status KV bucket, the run state of each subagent
One key per subagent (<agent>.<subagent>) holding running/finished, since, exit, model, effort and the publish time. The controller creates the bucket, and the agent credential may publish its own keys. Nothing reads or writes it yet; the daemon publisher and the controller list follow.
This commit is contained in:
parent
c9c2e75091
commit
c7d7f0df55
1 changed files with 214 additions and 0 deletions
|
|
@ -180,6 +180,16 @@ appearing there. The agent's grant is publish on its own
|
|||
subjects and limits are the controller's and never the agent's. Subagents
|
||||
publish output only and read nothing.
|
||||
|
||||
The daemon also publishes whether each subagent is running, one key per subagent
|
||||
(`<agent>.<subagent>`) in the `subagent-status` KV bucket, which swarm-controller
|
||||
creates with one revision per key. The value is the subagent's `state` (`running`
|
||||
or `finished`), `since`, `exit`, `model`, `effort` and `ts`, the time of the
|
||||
publish. A running subagent republishes every 60 seconds, and a reader treats a
|
||||
`running` value older than three of those as stale. The agent's credential may
|
||||
publish `$KV.subagent-status.<agent>.*` and nothing else of the bucket. Keeping
|
||||
this apart from the rows means a list of subagents reads one small value each
|
||||
and never a terminal stream.
|
||||
|
||||
The queue would refuse a row too large for its `max_payload` outright and
|
||||
take the connection down with it, so the harness drops such a row's body before
|
||||
sending and leaves a marker in its place; the summary, level and icon still
|
||||
|
|
|
|||
Loading…
Reference in a new issue