Home / Use cases / Embed an agent in a native app
C ABI embeddingEmbed an agent in a native app
Drive the agent from C, C++, Rust, or any language with FFI by linking libtokenworm — no runtime to bundle, no subprocess to manage.
The problem
Most agent SDKs assume a Node.js or Python runtime is present. Embedding one inside a native desktop app, a game engine, or a systems daemon means shipping that whole runtime alongside your binary — hundreds of megabytes of interpreter and dependencies for a single feature.
How tokenworm handles it
- ▸tokenworm exposes a stable C ABI in src/lib/ffi.zig: tokenworm_init, tokenworm_run, tokenworm_cancel, plus the session functions. Any language with FFI can drive the agent.
- ▸You link libtokenworm.so on Linux or libtokenworm.dylib on macOS — a single shared library, zero runtime dependencies, ~960KB per the README.
- ▸The agent loop, providers, tools, and sandbox all live inside the shared library, so the calling app stays thin.
- ▸Sessions produced through the C ABI are .tworm files that resume in any other surface — CLI, Python, TypeScript, or Go.
# Build the shared library from source (Zig 0.16) zig build -Doptimize=ReleaseSmall # Link against it from a C program cc app.c -ltokenworm -o app # The agent core runs in-process — no subprocess, no runtime bundle
- ·The C ABI is the architectural centre: every language SDK is a thin binding over this same boundary.
- ·A fix in the Zig core propagates to every embedding without re-implementation.
Questions
+ Which languages can call the C ABI?
Any language with C FFI. tokenworm ships idiomatic SDKs for Python, TypeScript, and Go over the same boundary, and anything that can call a C function — C, C++, Rust, Swift, and more — can link libtokenworm directly.
+ Do I need a Node or Python runtime to embed it?
No. The shared library is a self-contained Zig-compiled native binary with zero runtime dependencies. You only need the runtime for a specific SDK if you choose to use that SDK.