Agents
The canonical software-company package models agents as durable role bindings inside teams. This identity and coordination model is package-owned, not required common runtime semantics.
What an agent is in the reference package
A persistent agent is a durable operating identity inside a team. It carries:
- A mandate — What this role is responsible for inside its team.
- Attached skills — Packaged ways of acting that the agent can use. Skills are how the agent inhabits its work with craft.
- Tool access — Specific tools, MCP servers, or component-package capabilities the agent can call.
- Memory scopes — What the agent can read from and write to — its own working memory, its team’s memory, the company knowledgebase.
- Authority — What it’s allowed to do without approval, what requires approval, what’s explicitly off-limits.
- Attention policy — Which signals wake this agent. Heartbeats, triggers, handoffs from other agents, requests from the CEO.
- Continuity policy — When to keep a session going, when to start fresh, when old context has become contamination.
- Harness binding — Which agent harness this role runs on — Claude Code, Codex, Hermes, OpenClaw, or another.
Why agents are durable
An agent isn’t a session. Sessions come and go; chat threads end; runs finish. The agent persists across all of them. It accumulates memory, refines its skills, gets better at the work over time.
That persistence is exactly what makes agents organs of the company rather than employees. An employee comes and goes; an organ stays. A capability scout that’s been running for six months knows what got rejected and why. A memory steward that’s been operating across quarterly cycles knows what stale claims have already been demoted.
Agent vs. role vs. session vs. run
- Agent (persistent role binding) — Durable. Lives inside one team. Has identity. Carries memory, skills, authority across runs.
- Role (the template) — The template the agent is configured from — “capability curator,” “memory steward,” “customer-ops lead.” The template defines defaults; the agent is the instance.
- Run — One bounded execution attempt by an agent. A run has a wake reason, a target, a time and authority budget. The agent may produce many runs over its life.
- Session — Harness-level continuity within a run, or sometimes across runs (a Codex thread, a Claude Code resumed session). Session continuity is a harness detail; the agent’s identity doesn’t depend on it. If a session is reset, the agent persists.
Unusual roles
Some agents map to roles you’d find in any human company: sales lead, customer-support generalist, content producer. Other agents fill roles that don’t translate well from human orgs — durable cognitive functions that only make sense when the role doesn’t need to sleep, get along, or worry about looking dumb.
- Capability Curator — Watches what’s emerging in tools, models, skills, practices. Evaluates them, writes evals, decides where new capability belongs.
- Continuity Steward — Decides when to keep sessions going and when to start fresh. Treats session continuity as a cognitive resource rather than a default.
- Memory Steward — Decides what the company remembers, demotes, supersedes, or forgets. Maintains the long-term shape of what shapes future thinking.
- Attention Steward — Asks whether the company is waking for the right reasons. Manages signal routing and authority on wake.
These are illustrative roles, not a required roster. A company using this package picks the unusual roles that match its actual operating model.
Inspecting agents
Agent inspection is exposed through the company’s runtime API and any operator surface contributed by an installed package. A package may provide agent lists, live status, identity detail, and recent run history, but those views are not required runtime UI.