Browse documentation
Extend with native Rust
Connect the managed core to the wider Rust ecosystem through an explicit integration boundary.
The code agents write inside Septa is already Rust. Native Rust integration gives work beyond the managed profile a deliberate place in the same system.
Keep domain decisions and durable progress in the core when its guarantees are useful. Put transport handling, an existing SDK or platform-specific work behind an explicit interface, with its own authority and failure contract.
A concrete integration shape
The Services architecture uses an ordinary Rust host for transport framing, authentication ingress and adapter wiring. Its operations, validation and business rules are original Rust in the managed profile.
The host reaches the runtime through the public CLI and structured ops/v1 JSON. It is built as a native component, independently of the application edit loop.
HTTP / CLI / MCP
│
▼
Native Rust host
transport + authentication ingress + adapter wiring
│ public runtime interface
▼
Managed operations
typed inputs + decisions + durable progress
This diagram describes responsibilities. It is not an SDK signature or a promise that arbitrary native code can be imported into the managed core.
Make the boundary useful
For each integration, define the request and result types, the authenticated identity passed into the core, and the authority required on both sides. Specify what a timeout means and how a retry finds an existing outcome.
An existing SDK can serve a useful role in a native adapter. Its dependency graph, credentials and operating-system permissions belong to that adapter’s trusted boundary.
Guarantees follow the execution route
Native components use their own build process. Code that runs outside the managed core does not automatically inherit its bounded values, deterministic arithmetic, durable continuations or effect enforcement.
A host that has network or filesystem access still has that access. A typed interface is an important contract, but it is not an operating-system sandbox.
Choose the actual supported route
Use the host integration and public runtime interfaces supplied by the component you are extending. A specification for a separate native-driver lane is not, by itself, a shipped SDK for arbitrary physical handlers. Authoring a capability interface does not implement its external operation.
If the required library fits the supported Rust profile, it can participate in the managed library workflow. If it relies on ambient I/O, unsupported constructs or platform facilities, treat it as an integration design rather than assuming Cargo compatibility.
The result is a disciplined core with an explicit connection to the wider Rust ecosystem. Both sides remain understandable because the boundary says what crosses it and which guarantees apply.
Build software you can reason about.