Docs

Mental model

How Orchet knows your tools.

Orchet stores contracts, not your DB schema. It reads your public capability contract, snapshots it during review, and uses that approved snapshot to plan and invoke tools from chat.

Contract, not database schema.

Developers own their databases. Your agent keeps its own tables, migrations, queues, provider credentials, and business logic. Orchet stores only enough metadata to understand what the agent can do and how to call it safely.

Your agent ownsOrchet stores
Provider API clients and secretsAgent id, version, display copy, and runtime listing metadata
Private database schema and migrationsTool names, descriptions, JSON Schema inputs, and output hints
Business rules and execution codeAuth metadata, scopes, risk, and confirmation policy
Queues, retries, cache, and observabilityDiscovery URLs, approval state, and approved contract snapshots

A schema only matters when it is a tool input.

If your expense tool accepts group_id, amount, currency, description, and split, Orchet needs that JSON Schema. It does not need the tables behind your expense service.

Three protocols normalize into one registry.

SDK/API, remote MCP, and A2A submissions all become the same internal Agent Contract shape before they are used at runtime.

TS

interface AgentContract {
  contract_version: "2026-05-20";
  agent_id: string;
  version: string;
  protocol: "sdk_api" | "mcp_remote" | "a2a_peer";
  display_name: string;
  description: string;
  categories: string[];
  intents: string[];
  auth: AgentContractAuth;
  locator: AgentContractLocator;
  tool_discovery: AgentToolDiscovery;
  capabilities: AgentContractCapabilities;
  tools: AgentContractTool[];
}
  • SDK/API agents provide a manifest and OpenAPI document.
  • Remote MCP agents provide a server URL and Orchet discovers tools through MCP tools/list.
  • A2A peers provide an Agent Card and Orchet normalizes skills into callable tools.
  • Tool input and output schemas come from Agent Contract snapshots, OpenAPI, MCP tools, or A2A Agent Cards; they never come from private database introspection.

Runtime flow.

The model never calls a random endpoint. Every tool call is constrained by the approved contract snapshot.

  1. 1A user asks for a task in Orchet chat.
  2. 2The planner selects candidate tools from approved agent contracts.
  3. 3Orchet validates generated arguments against the tool's object-shaped input schema.
  4. 4If the agent is not installed or connected, Orchet renders the install or connect card inline in chat.
  5. 5If the tool is write, side-effect, or admin risk, Orchet asks for the configured confirmation before executing.
  6. 6Orchet invokes the agent using the approved locator and passes user-scoped credentials only when the connection allows it.
  7. 7The agent returns structured output. Orchet renders text, cards, and follow-up actions in the same conversation.