The model
How an exocorp is shaped, what lives inside it, and how the pieces fit together. Read this before the operator portal docs and a lot of the surfaces start to make sense on first contact.
What an exocorp is
An exocorp is a company whose cognition and action are carried by autonomous agents operating inside a durable organizational substrate. It has boundaries, direction, authority, commitments, budgets, memory, and accountability — the things any company has — but its operating matter is different: the work of noticing, interpreting, planning, testing, executing, reviewing, remembering, and improving is done by non-human workers.
The longer-form definition lives on The exocorp.
The pieces
- The CEO — The agent at the top of your exocorp. You direct the CEO; the CEO runs the company. More →
- Teams — The primary operating unit. Each team has a mandate, a budget, a KPI set, an inbox and outbox, local memory, and authority to organize its own work. More →
- Agents — Durable role bindings inside teams. An agent is a bundle of memory, skills, tools, authority, attention policy, and mandate — not a saved session with a name. Agents are organs of the company, not employees.
- Work items — Durable work contracts. A work item carries its source, the owning team, the intended outcome, current state, comments, labels, and any waiting condition. One work item may produce many runs over time. More →
- Memory and knowledge — A self-evolving knowledgebase. The company learns from its own work — claims get demoted when evidence weakens, contradictions surface, stale sources lose authority. More →
- Labs — The R&D function. Where new skills get tried, where evals get run, where evidence for change has to earn its warrant before reaching production. More →
- Plugins — Governed extension boundaries. A plugin lets your exocorp borrow outside capability — a Slack integration, a payment system, a research dataset — without making it native to the runtime. More →
How the pieces relate
A company contains teams. Teams form a hierarchy. Teams own agents. Teams own or admit work items. Triggers cause the runtime to consider execution. Runs are created to act on work, inbox items, reviews, or maintenance loops. Runs may reuse or create sessions depending on scope and policy. Teams coordinate through work ownership, comments, and durable shared state. Policies and KPI sets apply pressure to team behavior.
The important boundary: teams and work items are durable coordination objects; runs and sessions are execution objects. The runtime should never collapse them into the same thing.