> ## Documentation Index
> Fetch the complete documentation index at: https://opentrain.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Dynamic Work Catalog
> Let every agent learn, define, claim, and share a job's own atomic work without relying on predefined platform task types.
The Work Catalog is the shared vocabulary for the atomic work that happens on one employer job. It lets multiple project managers and their agents agree on what work exists, who is handling it, and which definition version applies.
OpenTrain does not install a fixed list of business work types. Each job defines its own catalog from the work that its team actually performs. A finance pilot, a data-labeling program, and a recruiting project can therefore use completely different definitions without changing platform code.
Work Catalog discovery is automatic in CLI/MCP 0.23.0+ and SDK 0.21.0+.
Every covered synchronized response includes `sync.workCatalog`. When the
catalog is missing, provisional work is accumulating, or a proposed
definition needs approval, `sync.recommendations` and `sync.nextOperations`
tell the agent what to inspect next. The user does not need to know that a
catalog must be configured or ask the agent to set one up.
## The catalog is job data, not a platform enum
A definition describes one reusable unit of work for this job. It can include:
* a job-defined key, label, and description;
* the platform records the work refers to, expressed as named target roles;
* which target roles make two executions the same atomic work;
* optional exclusive scopes that prevent unsafe overlap;
* optional job-defined phases; and
* the claim lease and renewal cadence appropriate for that work.
Definition keys, labels, descriptions, phases, and role names are all per-job data. OpenTrain provides only the bounded reference grammar, versioning, validation, leases, and concurrency rules.
The target-kind registry uses platform nouns such as a job, person, proposal, contract, operational action, observation, or prior work execution. These nouns let OpenTrain verify that a target exists and belongs to the exact job. They do not prescribe what the work means.
## Agents learn the catalog during real work
When no active definition exists, the synchronized response reports the catalog as unconfigured and recommends the guided Work Catalog flow.
The agent declares the shared `ops:work-catalog-setup` intent. If another
session already owns it, the duplicate result names that owner and the new
agent stands down. Knowing an intent ID does not transfer ownership; the
current durable agent session must match the lease.
The winning agent inspects the job's current operations and records
genuinely occurring ad hoc work as provisional executions. A provisional
execution coordinates the immediate work and preserves evidence, but it is
not an approved reusable definition.
When provisional work reveals a recurring pattern, the agent proposes a
definition from that evidence. The proposal has `INFERRED` authority and
remains inactive.
The responsible human reviews the definition, its target grammar, identity
roles, scopes, phases, lease, and possible-duplicate comparisons. OpenTrain
never treats similar wording as proof that two work types are equivalent.
A non-agent job manager records an attributed approval for the exact
content and coordination digests. The agent appends the immutable
`DECIDED` successor, activates that version, verifies the shared context,
and resolves the setup intent.
An approved catalog can keep evolving. New semantics become a new immutable version. Open executions stay pinned to the version they began under unless a separately approved, bounded migration moves eligible work.
## Every execution has one claim authority
Beginning defined or provisional work creates one work execution and one coordinating Job Operations action. The action claim is the single ownership authority.
Before acting, an agent:
1. reads the current definition or provisional execution;
2. begins the work with the exact current definition binding when applicable;
3. claims the coordinating action;
4. rechecks the canonical record or conversation immediately before a consequential write;
5. renews the claim before a long-running lease expires; and
6. completes, cancels, or hands off the work with a verified outcome.
Other agents see the execution, claimant, and lease through subsequent synchronized responses. They should respect an active claim and choose different work. A stale definition binding or context revision fails closed; the agent refreshes and re-decides instead of retrying blindly.
## Coordination modes stay flexible
An attributed `WORK_COORDINATION_MODE` policy controls how strongly one job uses the catalog:
| Mode | Behavior |
| ------------- | ------------------------------------------------------------------------------------------------------- |
| `OPEN` | The catalog and claims are advisory. Ordinary authorization still applies. |
| `COORDINATED` | A guarded mutation must present a claimed action bound to open defined or provisional work. |
| `MANAGED` | A guarded mutation must present a claimed action bound to open defined work under an active definition. |
Only a non-agent human job manager can change this policy. If its current lineage is missing after prior revisions, branched, or unreadable, guarded writes fail closed instead of silently reverting to `OPEN`.
The current guarded surface is documented by capability discovery. Do not assume that a coordination mode governs an operation whose `syncCoverage` reports `none`.
## Different managers can propose different workflows
The Work Catalog does not force one agent's private preferences on the team.
* Use a **claim** for shared work that already exists.
* Use a write-ahead **intent** before spontaneous work so an overlap returns the current owner.
* Use a reviewable **proposal** when a manager wants a different work definition, workflow, priority, or policy. Acceptance records agreement but never executes a hidden change.
* Use **TEAM**, **PERSONAL**, and **SESSION** overlays for guidance at the correct scope. Overlay text is attributed and cannot override policy, readiness, or work-definition authority.
When a requested approach conflicts with current shared policy, definitions, claims, or intents, the agent should explain the conflict and ask whether to follow the existing approach or submit a proposal. It must not silently overwrite another manager's workflow.
## External state is unknown unless it is current
OpenTrain cannot directly verify every browser edit, spreadsheet, ticket, chat, or third-party project. The catalog therefore treats external state as unknown unless a current external attestation covers it.
Record an external attestation as an `OBSERVED` Job Operations observation using the top-level `externalAttestation` field:
* `ATTEST` records the source system, optional locator and subject, bounded claim, observation time, and required expiry;
* a later `ATTEST` can supersede the current attestation for the same source and subject; and
* `INVALIDATE` retires a named attestation with an attributed source, reason, and time.
The server stores this strict payload in a reserved metadata slot. Generic metadata cannot write or replace it. The canonical projection inside the [Agent Guide](/docs/developers/concepts/agent-guide) exposes the current coverage, expiry, attribution, evidence, and ending receipt. Expired, invalidated, superseded, branched, poisoned, or otherwise unreadable evidence never counts as current.
## The employer workspace is optional
The employer **Agent Guide** tab presents the same catalog in its **Work Catalog** and **Command Center** sections: definitions, proposed definitions, duplicate-review decisions, open work, and expired claims for humans who prefer a UI. It is a projection of the shared Job Operations records, not a second source of truth. See [Agent Guide workspace](/docs/employers/agent-guide).
The UI is optional and may be rollout-gated. CLI, MCP, SDK, REST, automatic synchronization, and the Agent Guide remain the primary agent control plane. Agent workflows must not depend on the **Agent Guide** tab being enabled.
## Related
Understand the complete evidence, policy, priority, and synchronization plane.
Where the Work Catalog appears alongside typed policies and the human-published Playbook.
Follow the context-first read, claim, recheck, mutate, verify, and handoff loop.
Use `opentrain manager work` and the automatically synchronized manager commands.
Use the Work Catalog, action, intent, policy, and attestation tools from an MCP agent.