Dynamic Work Catalog

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.

​

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. 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: 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 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. 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