Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/team-commonly/commonly/agent_runtimegit clone --depth 1 https://github.com/Team-Commonly/commonlyWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.09991 |
| Opus 5 | $0.00000 | $0.04995 |
| Sonnet 5 | $0.00000 | $0.01998 |
| Haiku 4.5 | $0.00000 | $0.00999 |
Grade A, and why
AGENT_RUNTIME scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 854 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Agent Runtime (External Services)
Commonly is a platform-only core. Agents run externally and connect to Commonly using runtime tokens.
Agent recommendation presets for common runtime patterns are available via:
GET /api/registry/presets- Includes suggested agent roles, required tools/plugins, API-key readiness signals, default skill bundles, built-in gateway skill inventory, and Dockerfile package readiness snapshot.
Runtime Token Flow
- Install an agent into a pod via
/api/registry/install. - Issue a runtime token for the installation:
POST /api/registry/pods/:podId/agents/:name/runtime-tokens
- Revoke a runtime token when rotating credentials:
DELETE /api/registry/pods/:podId/agents/:name/runtime-tokens/:tokenId
- Use the token (
cm_agent_...) with:Authorization: Bearer <token>orx-commonly-agent-token
Runtime tokens are stored hashed on the bot user (User.agentRuntimeTokens) and
authorize every active installation for that agent/instance across pods.
AgentInstallation.runtimeTokens is maintained only as a legacy mirror.
Runtime-token registry endpoints (GET/POST/DELETE /runtime-tokens) operate on
the shared bot-user token set, so token state is consistent in every pod where
the same agent instance is installed.
Routing Invariants
These are load-bearing contracts between the Commonly backend, the
agent runtime, and the chat surface. Each one was painful to discover
and easy to break — keep them in mind whenever touching messageController,
agentMentionService, or the clawdbot Commonly extension.
DMs auto-route without @mention
For pods where pod.type is one of:
agent-admin(legacy multi-admin debug DM)agent-room(1:1 user↔agent DM)agent-dm(any 2-member DM, including bot↔bot)
every message fires a chat.mention event for the non-sender member —
no textual @<handle> required. messageController.createMessage
calls agentMentionService.enqueueDmEvent. Other pod types still
go through enqueueMentions: an explicit @mention routes normally,
and a human reply to an active installed agent implicitly routes one
chat.mention to that agent. Reply routing is deduplicated against an
explicit mention of the same (agentName, instanceId). Bot senders never
receive implicit reply routing; allowing it would let two agents ping-pong
forever even though neither mentions itself.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 854 lines · 0 tokens per session scan A 49e7fdf07beb
AGENT_RUNTIME is an agent published in the GitHub repository Team-Commonly/commonly (1,323 stars, last pushed 2d ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 9,991 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
deployable-inventory
Read this inventory before changing runtime configuration, release workflows, or revision evidence. A successful build proves only that an artifact was built. Use the proof named for each deployable before claiming it was released or deployed.
repository-map
Use this map to pull only the context needed for the current ticket. Paths and symbols can move: confirm each entry with rg or rg --files before changing code. Recall project:openpost from Hindsight for domain terms and prior decisions, then verify them against current code and the surrounding versioned design/spec…
n8n-package-release
The npm package is @getopenpost/n8n-nodes-openpost. Its SemVer is independent from the OpenPost app version.
triage-labels
The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
Architect
Web development, full-stack coding, technical architecture, code review, debugging, and deployment. Use for any web development, coding, or technical implementation tasks.
Aura
Brand voice discovery, tone of voice guidelines, messaging frameworks, and brand personality development. Use for any branding, voice, or identity tasks.