Collegium
Introduction

Comparison

How Collegium's design differs from Hermes Agent and DeepSeek Harness.

Most agent frameworks optimize for autonomy: give the model a shell and a loop, and let it iterate until the task looks done. That shape fits coding, where a bad attempt costs nothing and every change is reviewable as a diff before it ships. Collegium optimizes for the opposite case: business work where actions are visible to clients and colleagues the moment they happen, and most can’t be undone. The comparisons below focus on two frameworks built for the first case — Hermes Agent and DeepSeek Harness — and where Collegium’s constraints diverge from theirs.

Collegium’s design is a direct response to running an agent framework matching Hermes’s shape in production. The Specification lists what went wrong: unrestricted filesystem access, sub-agents whose work nobody could inspect, no approval mechanism, and instructions the agent treated as advisory rather than binding. Each failure has a structural answer in Collegium, not a prompt-level one.

At a Glance

CollegiumHermes AgentDeepSeek Harness
Identity and messagingMattermost bot accounts, the only substrateTelegram, Discord, Slack, WhatsApp, Signal, and CLI through one gatewayCLI and a local web UI
Capability modelHand-written TypeScript tools, immutable at runtime40+ built-in tools plus any MCP serverEvery capability — including the agent loop, sandboxing, and scheduling — is a Cordis plugin
Consequential actionsBlocking approval, full payload disclosed, no timeoutCommand approval and container isolation exist; the workflow isn’t a designed gate on every consequential callAn interaction package exposes ask-user and permission primitives; whether a given action prompts depends on the plugins installed
Sub-agent delegationNone. Every worker is a persistent, named agent; delegation is one agent addressing one peer, bounded in width and depthSpawns isolated sub-agents at runtime for parallel workstreamsA subagent capability delegates work through workflow plugins
Autonomous schedulingAn agent never wakes itself; non-LLM code decides when a turn startsBuilt-in cron scheduler runs tasks unattended, on any platformScheduling is a swappable plugin, wired in per deployment
Self-modificationAgents cannot write skills, prompts, or tool definitions; memory is the sole exceptionA “closed learning loop” with autonomous skill generationNot a built-in behavior, though a workflow plugin could implement it
Shell accessA per-agent grant, confined to a dedicated OS user with no read access to the framework or other agents’ homesA terminal capability with seven backends (local, Docker, SSH, Singularity, Modal, Daytona, Vercel Sandbox)A sandbox plugin (E2B, Landlock) chosen per deployment
ExtensibilityPlugins are TypeScript, reviewed like any deployed code, granted per agent, no runtime installMCP servers, connected at runtimeCordis plugins, swapped in configuration

Where the Designs Diverge

One substrate versus several. Collegium runs on Mattermost alone — no internal message bus, no scheduler calling an agent directly. If work is happening, there’s a post you can point at. Hermes reaches an agent through whichever platform a human is on; that’s a real advantage for personal use, but it means the record of what happened is split across however many gateways are configured. DeepSeek Harness assumes a developer at a terminal or the local web UI, not a channel other people can read over your shoulder.

Approval is a structural property, not an installed feature. In Collegium, a tool declares approval in code, and the framework — not the model, not a plugin — renders the full payload and blocks until a human decides. There’s no way to grant a capability that skips this. Hermes documents command approval and container isolation as safety features, but delegation and cron jobs run without a human in the loop by design, since unattended operation is the point. DeepSeek Harness makes approval a plugin (interaction), which is consistent with “everything is a plugin” but means the gate a deployment gets depends on which plugins it installed, including whether one is installed at all.

Delegation width is fixed, not elastic. Both alternatives spawn workers to parallelize a task — Hermes’s isolated sub-agents, DeepSeek Harness’s subagent capability. Collegium has no equivalent. An agent is a persistent identity provisioned before the framework starts, never created at runtime, and a turn can address exactly one peer. This bounds the total work a chain of delegations can do to a depth limit; a framework where a turn can fan out to several peers has no such bound without a separate throttle.

The loop itself is fixed. DeepSeek Harness’s everything-is-a-plugin architecture extends to the agent loop, the sandbox, and the scheduler — a deployment can reconfigure how the system decides to act, not just what it can act on. Collegium inverts this: activation, budgeting, and approval are the framework’s, identically for every deployment, and a plugin can only add a capability behind a grant. What a plugin decides is whether its own tools require approval; it can’t opt out of disclosure or budgeting the way a Cordis plugin could reconfigure the loop that calls it.

No self-modification. Hermes’s closed learning loop generates its own skills over time. Collegium’s agents can’t write skills, system prompts, tool definitions, or model selection — memory is the one thing an agent can add to on its own, and even that is disclosed in the channel as it happens. An operator who wants an agent’s behavior to change edits config.json or a skill file and redeploys.

What This Costs

Collegium trades throughput and autonomy for supervisability, deliberately. It won’t run unattended overnight, iterate on a coding task in a sandbox, or reach you through whichever chat app you happen to have open. If that’s the job, Hermes or DeepSeek Harness fit it better. Collegium fits the job where every action needs a witness and most can’t be taken back.