AI Coworkers: Not Just Chatbots or Agents

Overview

Two repositories, written in that order, testing the same idea from opposite ends. ai-coworkers is a TypeScript runtime where each coworker is a directory of markdown role docs plus its own SQLite event log and tiered memory. The docs are the job description: ROLE.md and RESPONSIBILITIES.md for the remit, TOOLS.md and SENSORS.json for capabilities and what it can perceive, WORKSPACE.md for the teams, systems and health signals it watches, RELATIONSHIPS.md for the humans and other coworkers it works alongside, AUTHORITY.md for what it settles alone against what it escalates, BOUNDARIES.md for the hard lines, and RITUALS.md for recurring work. A tick loop senses the world through read-only sensors, skips the LLM entirely when nothing changed, and checks every write action against the boundary docs before it executes. hermes-governance takes one component of that runtime, the boundary check, and rebuilds it in Python as a plugin for Hermes: 529 lines across boundaries_parser.py and __init__.py, hooked on pre_tool_call and on_session_start, parsing the same BOUNDARIES.md into three rule types and blocking the call inside the host. The first asks what a coworker needs. The second asks how much of that an existing agent host will accept.

Problem

I met people running Hermes agents as digital coworkers, one per team member, and the setups work. The agent remembers, it has a personality file, you talk to it in Slack. It is still a chat agent with continuity, and the human is still the one holding the map of the work. What I am after is an entity with a job description: role and responsibilities, sensors and capabilities, a graph of the work it touches (tasks, docs, systems), the customers and business domain it serves, its coworkers and how it relates to each of them, boundaries and rules, escalation paths, and broader goals broken down into tasks. Given that, it can notice work, decide whether it is theirs, and escalate instead of guessing. Chat-native agents act when spoken to, and none of the harnesses already out there (Hermes, OpenClaw, ElizaOS as long-running assistants, CrewAI as a task orchestrator) model the rest of it.

Constraints

• A coworker that runs all day cannot call the LLM every tick, idle cost has to be zero
• Write actions against real systems (Linear, GitHub, Slack) need a hard gate, not a prompt suggestion
• Role tuning has to be editable by a human in markdown, no YAML, no code changes
• Must reuse existing tool integrations rather than invent another plugin format

Approach

Studied the harnesses already out there (Hermes and OpenClaw for SOUL/MEMORY files and skills, ElizaOS for providers-actions-evaluators, Vercel Eve for the filesystem-first agent folder, MemGPT and the CoALA paper for tiered memory) and fused the parts that survive contact with a real backlog. The runtime is a tick loop: budget, sense, perceive, quiet gate, deliberate, boundaries, act, record. The quiet gate is the thesis. If nothing changed and no ritual is due, the tick costs nothing. Everything ships dry-run by default so you can watch a coworker for a day before granting live access. The second track runs the experiment the other way round. Rather than argue that a new runtime is needed, I took the boundary layer to Hermes as a plugin and measured what fitted. Three rule types, one markdown file, the same discovery order a Hermes user would expect, and a missing file left as a no-op warning rather than a hard failure. Where the port stopped tells me as much as where it worked.

Key Decisions

Tech Stack

TypeScript Node.js SQLite FTS5 MCP Vitest systemd Ollama Linear API Python (Hermes plugin)

Result & Impact

• ~4.2k lines TypeScript, 279 tests, 97.8% line coverage
  ai-coworkers runtime
• 529 lines Python, 16 tests, 2 Hermes hooks
  hermes-governance plugin
• MCP, Hermes skills, Eve folders, native
  Tool adapters
• 6 (working to reflective, CoALA taxonomy)
  Memory tiers

The runtime is stable and has been running against a real Linear workspace, triaging a live backlog in dry-run and then live mode. The highlights log interleaves the coworker's private thoughts with its actions, so a human can skim a day of work in one file. The coding coworker is scaffolded but not yet wired to a real coding agent. hermes-governance is at 0.1.0 and enforces the boundary rules it parses, which answers one third of the fit question and leaves the rest open. Where this ends up is undecided: a standalone runtime, a set of contributions to Hermes, or a boundary plugin that outlives the runtime it came from.

Learnings

• Deciding not to act is the hard part. Getting a model to do work is easy, getting it to recognise that a tick contains no work for its role took the quiet gate, the noop action, and an explicit pace signal.
• Job descriptions are a better agent config format than YAML. Writing AUTHORITY.md forces you to decide what the coworker settles alone versus escalates, which is the exact question that makes delegation to a person work.
• A private thoughts channel that threads across ticks does a lot of work. The coworker reads its own recent thinking on the next tick, which turns a stateless loop into something that follows through on what it started.
• Escalation beats guessing. A persistent questions file the coworker sees until a human answers removes the pressure to invent an answer and act on it.
• Meeting people who run one Hermes agent per team member changed what I think the missing piece is. Memory and personality are solved. The map of the work is not, and it currently lives in the human's head.
• Writing the same rules twice, in TypeScript and in Python, is what told me which ideas are portable. Anything expressible as a check on a tool call fits a Hermes hook. The work graph, the relationships between coworkers, and the escalation paths do not, because there is no hook where a model of the agent's own remit lives.