Kind Support & Resolution

Connectors declare which resource kinds they support via kind_pattern. The platform uses resource policies and these declarations to resolve which connector handles a given kind for read/write.

supports.kind_pattern

In your connector manifest (or supports on the connector class), set kind_pattern to an array of kind names or wildcard patterns. Each pattern is either an exact kind (e.g. core.email.message) or a prefix with .* (e.g. core.email.*).

typescript

import { BaseConnector } from '@human/connector-sdk';

export class EmailConnector extends BaseConnector {
  readonly id = 'connector-email';
  readonly name = 'Email';
  readonly version = '1.0.0';

  supports = {
    kind_pattern: ['core.email.message', 'core.email.thread'],
    store_name: 'vault',
  };

  // ... implement read/write for those kinds
}

store_name

Connectors also declare a logical store_name (e.g. vault, salesforce). Resource policies map kind patterns to a default store; the connector registry matches kinds to connectors that support that store and those kinds.

Pattern matching helpers

The Connector SDK exports kindMatchesPattern, kindMatchesAnyPattern, and mostSpecificPattern so you can test or implement resolution logic that mirrors the platform.

typescript

import { kindMatchesPattern, kindMatchesAnyPattern, mostSpecificPattern } from '@human/connector-sdk';

// Exact match
kindMatchesPattern('core.email.message', 'core.email.message');  // true

// Wildcard: any kind under core.email
kindMatchesPattern('core.email.message', 'core.email.*');        // true
kindMatchesPattern('core.email.thread', 'core.email.*');         // true
kindMatchesPattern('core.calendar.event', 'core.email.*');       // false

// Any of several patterns
kindMatchesAnyPattern('core.email.message', ['core.calendar.*', 'core.email.*']);  // true

// Most specific matching pattern (for resolution order)
mostSpecificPattern('core.email.message', ['core.*', 'core.email.*']);
// => 'core.email.*' (more specific than core.*)

Why not just call my API directly?

If you skip kind support and call your own API from the agent, you couple the agent to one system and one deployment. With kinds and connectors: agents stay kind-based, so the same agent works with vault, Salesforce, or a self-hosted store depending on policy. You implement one interface; the platform routes requests to you. That is less work for agent authors and fewer moving parts for operators.

How resolution works

When an agent (or the API) requests a read or write for a kind, the runtime: (1) finds resource policies that match the kind (and org/human), (2) gets the default store and optional connector_id from the policy, (3) finds connectors that support that store and match the kind. If multiple connectors match, the most specific pattern wins. Connectors never see "which database" — they see kind + store and handle the I/O.