Integrations

Toolang keeps a small integration boundary. The runtime owns lifecycle, scheduling, prompt traces, and local execution state, while integrations handle domain-specific input and output.

Plugin families

Toolang currently treats these areas as pluggable:

memory
channel
sandbox

That keeps the runtime stable even when the surrounding systems change.

Memory

Memory plugins provide:

recall
remember
health

Toolang decides when memory is used. The memory plugin returns structured data and diagnostics, but it does not rewrite scheduling or become the primary execution truth.

Example:

[memory]
plugin = "sqlite"
 
[memory.config]
path = ".toolang/agents/ship-docs/memory.db"
max_recent_items = 50

Memory augments a turn, but it is not the source of execution truth. If a memory write fails, the runtime can still complete the turn and record the failure in diagnostics.

Channels

Channel plugins handle message ingress and egress. In practice that includes:

polling
hook decoding
outbound delivery
health checks

Toolang still owns Message creation, thread persistence, turn scheduling, and bus projection writes.

Long-lived channel bindings usually live in:

channels.toml
hooks.toml

Sandboxes

Sandbox plugins provide execution environments for one-shot invocations and long-lived runtimes.

Example:

[sandbox]
plugin = "docker"
 
[sandbox.config]
image = "python:3.13"
network = "bridge"

Service capabilities still matter

Task systems and other external business tools are usually exposed to an agent through service capabilities. Runtime plugins stay small and structural. Domain actions such as reading a GitHub issue or updating a Linear ticket should live behind capabilities or chore logic, not inside the runtime core.

What plugins cannot change

Plugins can change domain-specific behavior, but they should not replace core runtime rules.

Toolang runtime still owns: