Termlings models your workspace as a file-backed organization chart of humans and agents.
An organization in Termlings is:
- A set of humans (
.termlings/humans/*/SOUL.md) - A set of agents (
.termlings/agents/*/SOUL.md) - Reporting links between them
- Live online/offline state from
.termlings/store/sessions/*.json
The model is local-first and deterministic: edit files, then inspect with CLI.
Reporting relationships are defined in SOUL frontmatter with reports_to.
Supported targets:
human:defaultagent:<slug>
Example:
---
name: Clover
title: Developer
reports_to: agent:pm
---If you think in terms of responds_to, that is the behavioral meaning of the reporting chain (who receives your updates and blockers).
In files and CLI, use reports_to as the canonical key.
Founder (human:default)
└── PM (agent:pm)
├── Designer (agent:designer)
├── Developer (agent:developer)
├── Growth (agent:growth)
└── Support (agent:support)
termlings org-chart
termlings org-chart --json
termlings brieftermlings create qa --name "QA" --title "QA Engineer" --reports-to agent:pmtermlings agents edit developer --reports-to agent:pm
termlings agents edit pm --reports-to human:defaultFor humans, edit .termlings/humans/<id>/SOUL.md directly.
Agents should route operational updates through their manager from termlings org-chart.
Typical flow:
termlings message agent:pm "Starting task-42"
termlings message agent:pm "50% complete; blocker on API auth"
termlings message human:default "Need credentials to unblock task-42"This keeps status updates structured and visible across the chain of command.
After edits:
termlings org-chart
termlings org-chart --json | jq '.edges'Confirm:
- Every agent points to the intended manager (
reports_to) - Roots are intentional (usually
human:default) - Manager spans look correct (direct reports)