Agents
Every contract has parties, and on this platform a party is never a
name typed into a text box. Authors, publishers, distributors,
resellers, rights holders, licensees — each is an agent: a
first-class record with an agt_ ID, held in a registry the
Contracts service owns. Contracts reference agents by ID,
royalty splits pay agents by ID, and the provenance record attributes
work to agents by ID. One identity, used everywhere the platform asks
who?
An agent record is small and stable: a type (PERSON,
ORGANISATION, or SYSTEM), a display name, an optional contact
email, an optional link to the platform account the agent signs in
with, and — for most records — a reference to the CRM record it
mirrors. That last field is where the story starts.
Three ways an agent is born
- Synced from the CRM. Most of the people and organisations the platform deals with first exist in Attio, the CRM where relationships are managed. A periodic sync mirrors them into the registry automatically — no re-keying, no drift between the CRM and the contracts that name them.
- Created manually. Not every counterparty lives in the CRM. An agent can be registered directly on the platform, and can later be linked to an Attio record if the relationship graduates into the CRM — after which the sync manages it like any other.
- Provisioned.
SYSTEMagents represent the platform's own actors — ingestion pipelines, platform services — so that automated work is attributable too. They are provisioned records, never CRM-synced.
The Attio sync
The sync is one-way: Attio into the platform, on a schedule. Nothing is ever written back to the CRM. Two kinds of Attio record take part:
| Attio object | Becomes | Typically |
|---|---|---|
| Person | A PERSON agent |
Authors, individual rights holders |
| Company | An ORGANISATION agent |
Publishers, distributors, resellers, corporate licensees |
Each run carries changes across by the Attio reference ID stored on the agent. A CRM record the registry has never seen becomes a new agent; a known one has its name and email refreshed; one deleted or archived in Attio has its agent archived — never deleted, because contracts and provenance reference agents forever, so the record must always resolve.
Because the sync is one-way, Attio is canonical for the fields it carries: correcting a CRM-managed agent's name on the platform is futile — the next run restores Attio's version. Corrections belong in the CRM.
Linking a manually created agent is an explicit, operator-driven action: set the Attio reference on the existing agent and the sync takes over. The platform enforces that an Attio record backs at most one agent, and it never auto-matches by email or name — a wrong guess would silently merge two parties' contractual identities, which is exactly the kind of error a rights platform cannot make.
Legal identity: who is really contracting
Real parties rarely contract under their display names. Sole traders sign under trade names, companies re-register in new jurisdictions mid-relationship, and the person named in a filename is not always the person in the signature block. Four platform-owned fields on the agent record keep the registry honest:
- a legal name — the registered name, when the display name is a brand or trade name;
- a jurisdiction and registration number — where and as what the party is registered, so a company re-domiciling under a new parent shows up as an auditable field change instead of a silent rename;
- trading names — every alias the party contracts under, so a contract naming the alias still finds the same identity.
These fields are never touched by the CRM sync — it writes only the display name and email — so a sync run structurally cannot overwrite legal identity.
The contract side carries the counterpart facts, per contract: a party can be marked as represented by another party on the same contract (the loan-out company that contracts on an individual author's behalf), and each party can record its signatories — who actually executed, in what capacity — because the audit of real paper found signers routinely differing from the party of record. The licensing example shows all of these together on an inducement letter.
Signed contracts keep their names
A contract does not just point at its parties — each version embeds the party's name (and email) as they stood when that version was written. The sync updates the registry record; it never rewrites a contract version. Every version is an immutable snapshot, so the platform record always matches the executed document.
A name changes in the CRM
Priya Chandra signs an author agreement as P. Chandra, then updates her name in Attio to Priya Chandra-Rao. The next sync run updates her agent record. What happens downstream?
- Her signed,
ACTIVEagreement still reads P. Chandra on every written version — matching the paper. The next addendum writes a new version that recaptures the registry, so it names Priya Chandra-Rao, while the earlier versions stand as signed. - A
DRAFTshe is still negotiating picks up the new name on its next edit — every edit writes a fresh version, and each version captures the registry at write time. - Anything that needs her current identity — a royalty
statement, an attribution display — joins through her
agt_ID to the live registry record and gets Priya Chandra-Rao.
The embedded name answers "what did this version say?"; the registry answers "who is this, today?". Keeping both means neither question ever has to guess.
A party's name never feeds rights resolution, so none of this triggers rights recalculation — a rename in the CRM is a registry update and nothing more.
One identity for parties and provenance
The same registry that supplies a contract's parties supplies the actors credited on every Activity in the provenance record. The author named on an agreement and the author credited with writing a chapter are one record, so "who is owed?" and "who did this?" resolve to the same identity. When a caller presents a token, the platform resolves it to an agent through this registry — see Tenancy & security.
Related pages
- Contracts & Rights overview — the roles a party can hold on a contract, and where agents sit in the contract record.
- Contract Model — the full term vocabulary contracts are built from.
- Royalties — how royalty splits pay contract parties by agent ID.
- Provenance — how agents are attributed on the platform's record of who did what.