Core Concepts

The key abstractions in DataGrout and how they fit together.

Servers

A server is your multiplexed endpoint. It aggregates all your integrations behind a single URL. Your agents connect to the server, and the server handles routing to the right integration.

Each server has:

  • A unique UUID and MCP endpoint URL
  • Its own set of integrations
  • Its own policy configuration (side effects, redaction, access controls)
  • Its own access tokens

You can create multiple servers for different purposes: one for production, one for staging, one per team.

Integrations

An integration connects an external system to your server. This can be:

  • A cloud service (Salesforce, QuickBooks, HubSpot) via OAuth
  • Any MCP-compatible server via URL
  • An on-premise system via a Private Connector

Each integration exposes tools that your agents can call. When you add Salesforce, you get tools like salesforce@1/get_lead@1, salesforce@1/create_opportunity@1, etc.

Tools

A tool is a callable operation with a typed schema. Every tool has:

  • A name following the pattern {integration}@{version}/{action}@{version}
  • A description in natural language
  • An input schema (JSON Schema) defining required and optional parameters
  • Annotations including Semio types, side effect classifications, and cost estimates

DataGrout also provides its own tools (discovery, prism, logic, flow, inspect) that are always available on every server.

Discovery

The Discovery Engine is how agents find and plan with tools. Instead of requiring agents to know which tools exist and how to chain them, Discovery provides:

  • Semantic search: Find tools by describing what you want to accomplish
  • Planning: Build multi-step workflows automatically and verify them before execution
  • Guided exploration: Navigate the tool mesh step-by-step with decision trees

Discovery uses a symbolic planning engine that searches exhaustively over your tool graph. Plans are verified for safety (no cycles, type compatibility, policy compliance, budget constraints) before any tool is called.

Policies

Policies control what agents can do. Every server has a policy configuration that includes:

  • Side effect controls: Restrict tools to none (read-only), read, write, or delete operations
  • Destructive operation blocking: Prevent delete/drop/purge operations
  • PII controls: Enable automatic detection and redaction of personally identifiable information
  • Field-level redaction: Mask specific fields (emails, phone numbers, SSNs) using configurable strategies

Policies cascade through a hierarchy: server-level defaults, integration-level overrides. A child policy can tighten restrictions but never loosen them.

Cognitive Trust Certificates

A CTC is a cryptographic proof that a workflow plan has been verified. When the planning engine validates a multi-step workflow, it issues a CTC containing:

  • Compile-time assurances: The plan is cycle-free, type-safe, policy-compliant, has available credentials, consumes all required inputs, and executes deterministically
  • Runtime assurances: Added after execution to confirm the plan ran as expected

CTCs can be saved as reusable skills: verified workflows that can be executed again without re-verification.

Credits

Every tool call through DataGrout has an associated cost in credits. The system provides:

  • Estimates before execution so your agent knows what a call will cost
  • Receipts after execution with the actual cost, broken down by component
  • Budget controls to prevent agents from exceeding spending limits

Credits cover the cost of DataGrout’s intelligence layer (discovery, planning, verification, redaction). Bring Your Own Key (BYOK) discounts apply when you use your own API keys for upstream services.

Transports

DataGrout supports two transport protocols:

  • MCP (Model Context Protocol): The standard protocol for AI tool access. JSON-RPC 2.0 over HTTP with Server-Sent Events for streaming. Use this if your agent framework supports MCP.
  • JSONRPC: Plain HTTP POST with JSON-RPC 2.0 payloads. No SSE required. Use this for legacy applications or any system that can make HTTP requests.

Both transports provide identical access to the full intelligence layer. The Conduit SDK supports both.