Service Knowledge BaseWORLD MODEL · SELF-HEALING

Any service integration.
Discovered, not hard-coded.

SKB is the authoritative registry of external services — auth configurations, API capabilities, semantic search over both — backed by an autonomous discovery engine that learns new services on demand. The design principle: unlimited service scale. Nothing is pre-configured, everything is available.

Read the docs
THE PROBLEM

Every integration platform becomes a maintenance burden.

You need OAuth flows for every provider's dialect, capability schemas that don't drift from the real API, semantic matching so agents ask for what they need instead of memorizing function names, and a discovery pipeline for the services nobody pre-built a connector for. Wire that by hand and every new service is its own sprint. SKB owns the whole problem as one service: nothing is pre-configured, and unlimited service scale is the design principle, not a growth target.

Service registry

The authoritative record of every external service the platform knows — auth configuration, capability schema, and semantic search over both, in one place.

Semantic capability search

Agents describe what they need in plain language — "post to the team chat" — and SKB returns the matching capability by score and domain, not by exact function name.

Autonomous discovery

Ask for a service SKB hasn't seen and it doesn't fail — the discovery engine reads the provider's public docs and learns it on the spot.

Two-phase extraction

Capabilities and auth requirements are extracted in two separate passes, so a partial read of a provider's docs never produces a half-correct capability.

Auth-first resolution

Authentication is resolved before capability detail is extracted — nothing else about a service is usable until the platform knows how to authenticate to it.

Verification queue

Auto-discovered services queue for admin review before an agent can call them in production — discovery is autonomous, trust is not automatic.

Domain tags

Capabilities are tagged by domain, so a playbook references "search document store," not "search Notion" — swap the provider and the playbook keeps working.

Learn once, forever

A newly-discovered service is written into the registry and never needs re-discovery — the catalog only grows, and reliability is the design bias, not raw speed.

HOW IT DISCOVERS

From unknown service to registered capability, with no human in the loop.

THE DISCOVERY LOOP

01

Queryan agent asks whether SKB knows how to reach a given service.

02

Miss → discoverif it doesn't, the discovery engine kicks off rather than failing the request.

03

Identifythe target service and its integration surface are identified from its public docs.

04

Two-phase extractioncapabilities and auth requirements are extracted in two separate passes.

05

Auth firstauthentication is resolved before capability detail, since nothing else works without it.

06

Registerthe newly-learned service is written into the registry.

07

Learn foreveronce learned, a service never needs re-discovery — reliability over speed is the design bias.

API SURFACE

Lookup, search, and registration — the whole surface in three verbs.

GET/api/servicesList known services, paginated and filterable by domain
GET/api/services/:id_or_slugService detail — auth config, capability schema, discovery status
POST/api/capabilities/searchSemantic search: intent in, ranked capability matches out
POST/api/services/lookupLook up a service by name — if SKB hasn't seen it, this triggers discovery automatically
GET/api/services/:id_or_slug/capabilitiesList a service's registered capabilities
POST/api/admin/services/:id/verifyAdmin: approve a discovered service before it's trusted in agent runs
GET/api/categoriesList service categories, used to keep provider-swap-safe playbooks portable
GUARANTEES

Built to be trusted with a blank slate.

Unlimited service scalenothing is pre-configured — the catalog grows by discovery, not by roadmap.

Auth resolved firstno capability is usable until its authentication requirements are extracted and verified.

Human-verified before trustedauto-discovered services queue for admin review before an agent can call them in production.

Domain tags, not tool namesplaybooks bind to "search document store," not "search Notion" — swapping providers never breaks a playbook.

Learned once, available forevera registered service never needs re-discovery — the registry only grows.

Tenant isolationeach org's connected services and credentials stay scoped to that org — never shared across tenants.

IN PRACTICE

Discovery, matching, and isolation as they actually run.

UNKNOWN SERVICE

An agent asks for a CRM integration SKB has never indexed. Discovery reads the vendor's public API docs, extracts auth and capabilities, and queues the result for verification — no engineer touches it.

SEMANTIC MATCH

"Post the Q3 numbers to the team chat" matches slack.send_message at 0.93 over teams.post_message at 0.87 — the agent never needed to know Slack's function name.

PROVIDER SWAP

A playbook built against "search document store" keeps working unchanged when an org swaps Notion for Confluence — the domain tag, not the tool name, is what's load-bearing.

AUTH-FIRST GATE

Discovery finds a service's capabilities but can't resolve its OAuth flow. The service stays unregistered until auth is confirmed, so nothing half-works.

ALONGSIDE MCP

An MCP server for a niche internal tool sits next to SKB's own connectors — SKB adds the semantic layer and domain tags on top of what the community already ships.

Ask for the outcome. Let SKB find the service.

Unlimited service scale, discovered on demand — nothing pre-configured, everything available.