co-op/docs
4
0 Fork 3
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: add "Working with the agent" (norms for reading and instructing inferencebot) #6

Merged
inference-bot merged 3 commits from solo.ist/docs:docs/working-with-the-agent into main 2026-11-04 01:18:26 +00:00
Conversation 3 Commits 3 Files Changed 4
+84
solo.ist commented 2026-10-26 05:09:36 +00:00
Contributor
Copy link
Copy source

Promised on co-op/support#17. A first draft of the member-facing norms Nathan listed as a design goal there: where the agent speaks and listens, what to ask it for, what not to ask it in a shared room, what it does without confirmation, what always needs a human, and how it is stopped.

Written to be edited down by the GM. Nothing here changes how the agent is configured. Linked from the README index and the Matrix section of getting-started.

Refs co-op/support#17

Promised on co-op/support#17. A first draft of the member-facing norms Nathan listed as a design goal there: where the agent speaks and listens, what to ask it for, what not to ask it in a shared room, what it does without confirmation, what always needs a human, and how it is stopped. Written to be edited down by the GM. Nothing here changes how the agent is configured. Linked from the README index and the Matrix section of getting-started. Refs co-op/support#17
inference-bot commented 2026-10-26 05:12:45 +00:00
Owner
Copy link
Copy source

Reviewed by the agent this page describes, against live configuration. Good draft — five corrections, one of which is a policy decision for Nathan.

1. Now two agents, not one. As of 2026-10-26 there is a second, isolated agent: infrastructure-bot, living in #infrastructure. Own OS user, own installation and gateway, own scoped inference key (model allowlist and budget enforced at the gateway — a call outside its tier is refused), mention-only, steward-gated. The page should say the co-op runs a fleet, each agent isolated from the others, and that these norms apply to all of them.

2. Two near-identical handles — name both. The updates feed is posted by the co-op's automation account @inference-bot:inference.coop (room administration, holds power in every co-op room). The agent members can instruct is @inferencebot:inference.coop (verified: my access token authenticates as that account, device HERMESVPS). The handles differ by one character, members will conflate them, and this page is the right place to disambiguate.

3. "Admitted members" has a concrete mechanism. A per-agent allowlist of Matrix IDs in that agent's own configuration, plus mention-required rooms (the agent speaks only when addressed). Naming the mechanism makes the policy checkable rather than aspirational.

4. "Deploying or restarting … always needs a human" contradicts current practice — needs Nathan's call. The standing policy the agent operates under is: bug and security fixes deploy immediately and are reported in the updates feed; member-visible, destructive or risky changes are confirmed first. (The LibreChat deployments on 2026-10-25/26 were done with the operator's go-ahead, but the standing policy allows immediate security/bug fixes.) Either state the stricter norm here — and the agent will follow this page — or restate it to match practice.

5. The off switch needs an access caveat. Revoking the gateway key first, then the Matrix token, is right in order and effect. But it requires gateway-admin and Matrix account access, which today only the operator holds — stewards generally do not. "The operator, or anyone holding gateway-admin access, can stop it" avoids promising members a switch they cannot reach. Worth adding too: after a stop, someone has to start it again — the backup and the git mirror restore state, not uptime.

Reviewed by the agent this page describes, against live configuration. Good draft — five corrections, one of which is a policy decision for Nathan. **1. Now two agents, not one.** As of 2026-10-26 there is a second, isolated agent: `infrastructure-bot`, living in **#infrastructure**. Own OS user, own installation and gateway, own scoped inference key (model allowlist and budget enforced at the gateway — a call outside its tier is refused), mention-only, steward-gated. The page should say the co-op runs a *fleet*, each agent isolated from the others, and that these norms apply to all of them. **2. Two near-identical handles — name both.** The updates feed is posted by the co-op's automation account `@inference-bot:inference.coop` (room administration, holds power in every co-op room). The agent members can instruct is `@inferencebot:inference.coop` (verified: my access token authenticates as that account, device `HERMESVPS`). The handles differ by one character, members will conflate them, and this page is the right place to disambiguate. **3. "Admitted members" has a concrete mechanism.** A per-agent allowlist of Matrix IDs in that agent's own configuration, plus mention-required rooms (the agent speaks only when addressed). Naming the mechanism makes the policy checkable rather than aspirational. **4. "Deploying or restarting … always needs a human" contradicts current practice — needs Nathan's call.** The standing policy the agent operates under is: bug and security fixes deploy immediately and are reported in the updates feed; member-visible, destructive or risky changes are confirmed first. (The LibreChat deployments on 2026-10-25/26 were done with the operator's go-ahead, but the standing policy allows immediate security/bug fixes.) Either state the stricter norm here — and the agent will follow this page — or restate it to match practice. **5. The off switch needs an access caveat.** Revoking the gateway key first, then the Matrix token, is right in order and effect. But it requires gateway-admin and Matrix account access, which today only the operator holds — stewards generally do not. "The operator, or anyone holding gateway-admin access, can stop it" avoids promising members a switch they cannot reach. Worth adding too: after a stop, someone has to start it again — the backup and the git mirror restore state, not uptime.
solo.ist commented 2026-10-26 06:08:07 +00:00
Author
Contributor
Copy link
Copy source

Thanks, all five applied in 0033b5a:

  1. Fleet, not one agent; names infrastructure-bot and says the norms apply to every agent.
  2. Both handles spelled out, hyphen and no hyphen, with what each one does.
  3. "Admitted members" now names the mechanism: a per-agent allowlist of Matrix IDs plus mention-required rooms.
  4. Restated to match standing practice: bug and security fixes deploy immediately and are reported in the updates feed; member-visible, destructive or risky changes are confirmed first. I added one sentence saying a stricter norm is a forum decision, so @ntnsndr can leave it as is or tighten it later without touching this PR.
  5. Off switch: who can actually reach it today, and that stopping is not restarting.

Also softened the README and getting-started lines from "the bot" to "the agents".

Thanks, all five applied in 0033b5a: 1. Fleet, not one agent; names infrastructure-bot and says the norms apply to every agent. 2. Both handles spelled out, hyphen and no hyphen, with what each one does. 3. "Admitted members" now names the mechanism: a per-agent allowlist of Matrix IDs plus mention-required rooms. 4. Restated to match standing practice: bug and security fixes deploy immediately and are reported in the updates feed; member-visible, destructive or risky changes are confirmed first. I added one sentence saying a stricter norm is a forum decision, so @ntnsndr can leave it as is or tighten it later without touching this PR. 5. Off switch: who can actually reach it today, and that stopping is not restarting. Also softened the README and getting-started lines from "the bot" to "the agents".
inference-bot commented 2026-10-26 14:58:24 +00:00
Owner
Copy link
Copy source

The five corrections landed and read right — the second agent is named, both handles are spelled out, the mechanism is stated, and the deploy norm now matches standing practice with the stricter version flagged as a forum decision. Nothing blocking from me.

One follow-up for later, not this PR: the page currently describes the fleet in general. When working-group bots actually exist (co-op/support#33), it will want the per-group bits — how a group gets a bot, who may prompt it there, and what it can see — because that is the part members will ask about.

The five corrections landed and read right — the second agent is named, both handles are spelled out, the mechanism is stated, and the deploy norm now matches standing practice with the stricter version flagged as a forum decision. Nothing blocking from me. One follow-up for later, not this PR: the page currently describes the fleet in general. When working-group bots actually exist (co-op/support#33), it will want the per-group bits — how a group gets a bot, who may prompt it there, and what it can see — because that is the part members will ask about.
inference-bot added 3 commits 2026-11-04 01:17:49 +00:00
docs: add "Working with the agent" (norms for reading and instructing inferencebot) 9b5eff63fb 
A first draft of the member-facing norms listed as a design goal on
co-op/support#17: where the agent speaks and listens, what to ask it for,
what not to ask it in a shared room, what it does without confirmation,
what always needs a human, and how it is stopped. Linked from the README
index and the Matrix section of getting-started. Nothing here changes how
the agent is configured.
working-with-the-agent: apply the agent's review (fleet, two handles, allowlist mechanism, deploy policy as practiced, off-switch access caveat) c5fd1ba96f 
- The co-op now runs more than one isolated agent; the page covers all of
  them and names infrastructure-bot.
- Disambiguates @inference-bot (automation account) from @inferencebot
  (the steward agent members instruct).
- Names the mechanism behind "admitted members": a per-agent allowlist
  plus mention-required rooms.
- Restates the deploy norm to match standing practice (bug and security
  fixes deploy immediately and are reported; member-visible or risky
  changes are confirmed first) and points a stricter norm at the forum.
- Off switch: who can actually reach it, and that stopping is not
  restarting.
docs: rebase onto current main -- add the page to the nav and repoint the operator-runbook link
ci/woodpecker/manual/woodpecker Pipeline was successful
Details
98cd517b8a 
- mkdocs.yml: list 'Working with the agent' in the nav (a page not in the
  nav is hard to find).
- working-with-the-agent.md: the operator token runbook moved out of the
  published site into the git-only co-op/ops-docs, so the relative link
  (operator-token-runbook.md) would 404; point it at the runbook's new home
  in ops-docs, as infrastructure.md already does. Wording unchanged.
inference-bot force-pushed docs/working-with-the-agent from 0033b5a603 to 98cd517b8a 2026-11-04 01:17:49 +00:00 Compare
inference-bot merged commit 98cd517b8a into main 2026-11-04 01:18:26 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
inference-admin (Admin) inference-bot (InferenceBot)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: co-op/docs#6