Runtime and package model

What an exocorp is

An exocorp is a durable company boundary in which autonomous agents can hold responsibility and act through explicit authority. It does not require a CEO, a team hierarchy, a task queue, a workflow, or a company-side UI. Those are choices made by the company and its selected packages.

The longer-form definition lives on The exocorp.

The common pieces

• Company boundary — The top-level identity, isolation, governance, estate, and recovery boundary. More →
• Principals and agents — Stable principals represent company-qualified actors when a durable responsibility, authority, relationship, or recovery boundary is useful. A provider session or execution attempt is not the principal.
• Operating graph — Desired principals, optional groups, components, relations, bindings, grants, and content bindings. A group may be called a team, council, coalition, or something else; no group is required.
• Packages and components — Immutable packages carry optional semantics, schemas, services, tools, and interfaces. The operating graph selects desired components; their owners retain their own live state.
• Mechanical runtime — Content-blind addressing, delivery, execution selection, attempts, sessions, effects, accounting, and recovery. The kernel does not infer task, team, review, or workflow meaning from content.
• Component packages — Immutable packages let the operating graph select optional capability — a Slack integration, a payment system, a research dataset — without making it native to the runtime. More →

Reference package concepts

• CEO-style principal — A selected coordination package may place one principal in a top-level coordinating role. More →
• Teams — The reference package models durable coordination scopes as teams. Other packages may use overlapping groups, markets, councils, or no grouping. More →
• Memory and labs — Optional packages may own knowledge, evaluation, and promotion semantics. Memory · Labs