Kinds & Namespaces: A Shared Language for the AI Economy
If every agent and every connector invents its own way to name "an email" or "a meeting transcript," nothing composes. You'd have one system calling it EmailMessage, another core.email.msg, and a third storing it in a table named notifications. The AI economy needs a shared language—one that humans and machines can rely on to mean the same thing everywhere.
That language is kinds and namespaces.
The Problem: Naming Chaos
In a typical integration, every team names types differently. The CRM says "Lead," the email provider says "Message," and your agent has a type ProcessedEmail. Mapping between them is custom code every time. When a new system joins, you write more mappers. When a schema changes, you fix five places.
We wanted one set of names that everyone can use: agents that produce "meeting notes," connectors that store "meeting notes," and policies that say "store meeting notes in the vault." Same name, same meaning, everywhere.
What a Kind Is
A kind is a dot-separated type name. Examples:
core.email.message— a single email messagecore.meeting.transcript— a meeting transcriptcore.health.ct_scan— a CT imaging study (for healthcare use cases)agent.socratic.interview.session— an interview session produced by a specific agent
Kinds are lowercase, with segments like segment.segment.segment. They're the vocabulary for the Resource Graph: every resource has a kind, and every schema is registered for a kind.
Namespaces: Who Owns the Name
The first segment of a kind is the namespace. It tells you who is allowed to define and evolve that type:
core.*— Platform canonical types. Shared across all deployments. Owned by the protocol.std.*— Standards-based types (e.g. FHIR, HL7). Interoperability with external standards.org.<orgslug>.*— Your organization's types. Only your org can define and change them.agent.<publisher_slug>.*— Types defined by a marketplace agent publisher. That publisher owns the schema.ext.<reverse_dns>.*— Bridge types for external ecosystems (e.g. Slack, Salesforce). The bridge maintainer owns them.
So when you see core.email.message, you know it's a platform-standard type. When you see org.acme.contract.draft, you know it's specific to the Acme org. Namespaces prevent collisions and make authority clear: only the owner of a namespace can register or change schemas for kinds under it.
A Schema Registry, Not a Free-For-All
Kinds don't exist in a vacuum. Each kind has one or more schemas—JSON Schema definitions that describe the shape of the data. The schema registry stores them, keyed by kind and version. When an agent writes a resource of kind core.email.message, the platform can validate the payload against the registered schema and reject invalid data.
Orgs can also pin a preferred schema version for a kind (e.g. "for us, use core.email.message.v2"). That way, the same kind can evolve over time while different orgs choose when to adopt new versions.
Why This Makes Life Better
For agent authors: You declare "I consume core.meeting.transcript and produce core.meeting.notes." You don't care where the transcript came from or where the notes are stored. The platform resolves that. You stay in one vocabulary.
For connector authors: You declare "I support core.email.*." You implement read/write for that shape; the platform routes requests to you when policy says so. You don't invent your own type names—you implement the shared ones.
For operators: You write policies like "store core.health.* in the vault." One policy, all resources of that family. No per-app configuration.
The result: fewer mappers, fewer bugs, and a single place to look when you ask "what is this type and who owns it?" That's the shared language the AI economy needs—and kinds and namespaces are how we get there.