Skip to main content

Adapters

Adapters are how a venue gets its capabilities. Each adapter contributes a family of operations — self-describing, invocable units with JSON Schema inputs and outputs — that any client, agent, or orchestration can call. Out of the box a venue ships with adapters spanning LLMs, HTTP, files, lattice state, federation, and more; operators can add their own.

Available adapters

AdapterOperationsWhat it does
LangChainlangchain:*Call LLMs — OpenAI, Anthropic, Ollama, xAI, and OpenAI-compatible endpoints
Gridgrid:*Invoke operations on local or remote venues (federation)
Orchestratororchestrator:*Multi-step DAG workflows with dependencies
MCPmcp:*Call external MCP servers as grid operations
A2Aa2a:*Call remote A2A agents; serve A2A inbound
HTTPhttp:*SSRF-protected outbound HTTP requests
Filefile:*Root-jailed local filesystem access
DLFSdlfs:*Decentralised, user-signed file system (WebDAV)
Vaultvault:*Simplified, fixed-drive file access
Schedulerscheduler:*Run operations later; deferred and agent wakes
Covia (Venue)covia:*CRUD over the venue's lattice state
JSONjson:*Pure JSON data manipulation (merge, select, …)

Agent execution (agent:*, llmagent:*, goaltree:*) is documented under Agents.

How operations are named and invoked

Operations are written as adapter:op (e.g. grid:run) or as a venue catalog path (v/ops/grid/run). Invoke them over REST (POST /api/v1/invoke), through an SDK, as MCP tools, or as agent tools. Because every operation is self-describing, both humans and agents can discover and call them.