Separate interfaces should not create separate products
One of the easiest ways to make infrastructure feel unreliable is to give every surface a different concept of what a runtime is. A dashboard creates one thing, a CLI manages another, and an SDK wraps a third. The result is needless friction and uneven documentation.
We are pushing Tennant in the opposite direction. A sandbox should be the same sandbox whether it is created from the dashboard, the CLI, or a TypeScript, Python, or Go SDK.
Consistency unlocks better docs and better automation
Once the lifecycle is unified, examples get dramatically simpler. Create a sandbox. Deploy from GitHub. Execute a command. Close it when done. Those steps are understandable in every interface, which means docs can stay tight and agents can use the system more effectively too.
That same consistency is why we split the SDKs into their own parent-level package structure. The goal is not just language support. It is a stable API shape that developers can rely on regardless of tool choice.
The control plane should feel smaller, not bigger
Good platform design reduces the number of concepts users need to learn. Tennant is at its best when a team can move from UI to CLI to API without translating terminology or rebuilding context each time.
That is the experience we are aiming for across the sandbox dashboard, HTTP endpoints, and multi-language SDKs: one product surface, several access points.