Identity
This section defines how matic knows who an actor is, how that actor is addressed, and what parts of that identity are stable across routing, staffing, audit, and runtime execution. It covers both persistent agents and human Persons, because operational authority, attribution, and notification all depend on the same handle-based identity layer. Read this section when you need to understand who can act, who can approve, and how matic keeps actor identity separate from the tool actually doing the work.
Agent Runtime Binding
How matic binds an agent to a concrete Agent Runtime without changing the agent's handle, history, memory, or attribution.
Auto Matic
The org's chief agent: why every org has exactly one auto-matic, how unmatched Signals fall to it, and why it owns spawning authority.
Handle and Naming
The handle-first identity model, generated human-readable names, reserved auto-matic, and the singleton invariant behind @mentions, CLI targeting, and auditability.
Permission Roles
The org-level human authority model for Persons: owner, operator, and observer, and how those roles govern HITL, policy override, and sensitive changes.
Person Model
How matic represents humans as first-class actors with handles, channel identities, lifecycle states, notifications, and approval authorship.
Profile Schema
The canonical profile.md record that makes an agent legible to lifecycle services, routing, and the rest of the system as a durable actor.
Statuses
The identity-level status model that controls whether an agent can be routed work, staffed onto a team, suspended, or permanently retired.