Stacklink

Architecture

How a request flows, the subsystems, and the deployment shape.

Under the boundary, every tool call takes a predictable path — and the credential never leaves the server.

How a tool call flows

Your agent selects an exact contract

The six-tool router searches server-side, loads an exact signed contract, and calls STACKLINK_EXECUTE_TOOLS. A specialist session can expose up to ten exact direct tools.

It picks the connected account by accountId/accountAlias (or the session default), loads the active encrypted credential version, and refreshes it if expired.

The provider executor runs

A provider-specific client calls the real API with credentials that never leave the server. Signed URLs and large payloads are captured as Stacklink artifacts.

Results come back sanitized

The model receives a sanitized response (secrets and signed URLs redacted). Everything is recorded in tool_execution_logs and linked to the originating platform_request_logs row.

Demo placeholderA tool call: discover → resolve account → execute server-side → sanitized result

Subsystems at a glance

SubsystemOwns
SessionsThe per-tenant/user scope: exact model surface, accounts, Knowledge, Memory, and MCP.
CatalogOne versioned provider registry projected into application summaries, search documents, exact contracts, and execution bindings.
ConnectionsAuth configs, connected accounts, encrypted credential versions.
KnowledgeVersioned packs, hybrid retrieval, evidence receipts, structured rules.
EventsWebhook ingress, polling, the normalize → deliver pipeline.
WorkbenchBackend control plane over a secure, isolated code/bash sandbox.
Billing & usagePlans, operation classes, metered usage, cost ledger.
Observabilityplatform_request_logs and tool_execution_logs.

Background workers

Stacklink uses four bounded process roles: web, provider-runtime, webhook-delivery, and platform-background-jobs. PostgreSQL owns durable jobs and events; Redis provides cache and post-commit wake signals. Empty polls are not persisted.

Deployment shape

The backend is a single Fastify service that can also serve the built dashboard from the same origin. The remote workbench runs in a separate isolated sandbox runtime. Knowledge runs from a separate runtime database, built offline and promoted as approved releases.

On this page