SmythOS SRE: a TypeScript runtime that treats LLMs, vector stores and caches as OS resources
The SmythOS Runtime Environment (SRE) is an open-source, cloud-native runtime for agentic AI. Secure, modular, and production-ready, it lets developers build, run, and manage intelligent agents across local, cloud, and edge environments.
At a glance
- What is it?
- SmythOS Runtime Environment is an MIT-licensed TypeScript monorepo that puts a kernel, an SDK and a CLI around agent workloads, with provider-swappable connectors for storage, LLMs, vector databases, cache and secrets. The judgement: the provider abstraction is the real product, and the ACL layer is what you are actually adopting.
- Who is it for?
- Adopt SRE if you are writing agent logic in TypeScript and you expect to move between LLM, storage or vector providers, because the connector layer is where the work has gone. Do not adopt it if you need a visual builder (that is the separate Studio repository) or if you cannot accept an MIT-licensed runtime whose release history the repository metadata does not expose.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 166 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem SRE targets: provider churn inside agent code
Most agent codebases start with one LLM vendor and one storage backend, then acquire a second of each. The swap is rarely a config change, because the vendor SDK leaks into the business logic: message shapes, streaming callbacks, retry semantics, credential handling. SRE's stated goal is to remove that leak. The README describes a unified interface where all providers expose the same functions and APIs, and it extends the claim past storage to VectorDBs, cache (Redis, RAM), and LLMs (OpenAI, Anthropic). The intended reader is a developer who already writes agent logic in TypeScript and wants the provider choice to be a runtime decision rather than a rewrite. The README frames this as an operating system parallel: a kernel manages resources and exposes APIs, and SRE manages AI resources and exposes an SDK. That framing is marketing, but the underlying claim is testable, because a unified interface either holds across providers or it does not. The secondary audience is the operations side: the repository lists a Candidate/ACL system for secure resource access and credential management under a Vault connector family (JSON File, AWS Secrets Manager, HashiCorp), which suggests the project expects agents to run with scoped access to secrets rather than a flat environment file.
Kernel, SDK, CLI: how the monorepo is actually split
The repository is a monorepo with three packages, and the split matters more than the feature list. packages/core is the runtime, described as the kernel of the AI agent operating system. It owns the connectors, the Candidate/ACL access model, memory and storage management, and agent lifecycle. packages/sdk is the developer-facing abstraction over that kernel. packages/cli is the project scaffolder. The connector inventory is the concrete part of the architecture: Storage across Local, S3, Google Cloud and Azure; LLM across OpenAI, Anthropic, Google AI, AWS Bedrock, Groq and Perplexity; VectorDB across Pinecone, Milvus and RAMVec; Cache across RAM and Redis; Vault across JSON File, AWS Secrets Manager and HashiCorp. A connector per service family, with one interface per family, is the data flow: agent code calls the SDK, the SDK resolves the configured provider through the kernel, and the kernel enforces access before the provider call happens. The README also claims 40+ production-ready components for AI, data processing and integrations, which is a count, not a specification; the repository does not enumerate them in the material available here, so treat that number as a claim to check against packages/core before you plan around it. What the layout does establish is that provider code is quarantined behind connectors, which is the property that makes the swap claim plausible.
Installing it: two documented paths and one debug flag
The README gives two install paths. The recommended one installs the CLI globally and scaffolds a project:
npm i -g @smythos/cli sre create
The second adds the SDK to an existing project:
npm install @smythos/sdk
That is the whole of the documented setup in the material. There is no config file schema, no environment variable list beyond one, and no example of wiring a connector. The one operational key the README does name is LOG_LEVEL. The note recommends setting LOG_LEVEL="debug" and re-running your code when the CLI or your code misbehaves, then sharing the logs. That is a support instruction, not a configuration reference, and it is the only knob the material documents. Everything else, including how you declare which LLM or storage provider an agent should use, is deferred to the SDK documentation site and the examples directory. The README also points at a separate repository of code templates. If you are evaluating SRE for a real project, the honest sequence is to run sre create first and read the generated configuration, because that generator is where the connector wiring is actually expressed and the README does not reproduce it.
The Candidate/ACL model is the part worth scrutinising
SRE lists a Candidate/ACL system under its security-first feature, and the README's third design principle states that security is not an add-on. The term Candidate is not defined anywhere in the supplied material. It appears once, in the feature list, with no explanation of what a candidate is, how it is declared, or how an ACL references one. That is the largest documentation gap in the repository as presented. It matters because credential handling is the difference between a runtime you can put in front of production systems and one you cannot. The Vault connector family implies secrets are resolved through the same connector abstraction as storage and cache, which would be the coherent design: an agent requests a secret, the kernel checks the ACL, the vault connector returns it. But the material does not confirm that chain. If you are evaluating SRE for anything that touches customer data, the first thing to read is the core documentation on access control, not the quick start. A security layer you cannot describe from the README is a security layer you have to verify from source.
Where SRE is the wrong tool
Two cases stand out. First, if you want to build agents by dragging boxes on a canvas, SRE is not that product. The README explicitly redirects those users to the separate SmythOS Visual Agent Studio repository, and describes SRE as the SDK and CLI path for creating agents with code. Choosing SRE means choosing code as the authoring surface. Second, if your agent stack is Python, the abstraction is unavailable to you. SRE is a TypeScript project with an npm-distributed SDK and CLI, and the README's install instructions are npm commands. The unified-interface argument does not transfer across language runtimes; you would be reimplementing the connector layer yourself. A third, softer limitation: the provider abstraction only pays off if you actually switch providers or run the same agent against more than one environment. A single-vendor prototype gains little from a kernel, and pays the cost of learning the ACL and connector configuration. The README's own pitch is scaling from development to production, which is a statement about the second half of a project's life, not the first afternoon of it.
How this differs from LangChain and the other frameworks in its topic list
SRE lists langchain, autogpt, n8n and mcp among its topics, so it is fair to place it against that field. LangChain's centre of gravity is the chain and the prompt: composable steps, integrations with model providers, and a large catalogue of retrievers and tools, all expressed in Python and JavaScript libraries. SRE's centre of gravity is the resource, not the chain. The README's repeated claim is that every provider in a service family exposes the same functions and APIs, so swapping OpenAI for Anthropic or Local storage for S3 does not touch business logic. That is a narrower promise than a framework makes, and it is aimed at a different pain: not how do I express this pipeline, but how do I stop my pipeline from being welded to a vendor. The ACL and vault connectors reinforce the operational framing. The trade-off is scope. A resource layer gives you less out of the box for prompt orchestration, evaluation and retrieval strategy than a framework with a large integration catalogue, and you will write more of that yourself. If your problem is composing reasoning steps, a framework is a better fit. If your problem is that the same agent must run against three providers and two storage backends, the resource layer is the more direct answer.
Maintenance, licence and what the release metadata does not show
The licence is MIT, declared in the repository and in the README badge, which permits commercial use and modification with the usual attribution and warranty disclaimer; that is a description of the licence text, not legal advice, and you should read LICENSE before shipping. The repository is not archived, the default branch is main, and the last push recorded is 2026-04-03, which indicates active work. What the metadata does not provide is a release history: the recent releases field is empty in the supplied material, so there is no changelog to read for breaking changes, no version cadence to plan upgrades around, and no way to judge from this data alone whether the SDK surface is stable. For a runtime that sits under your agent logic, that is the maintenance question that matters most, and it is unanswered here. The practical consequence: pin the version of @smythos/sdk and @smythos/cli you install, and read the SDK documentation for the version you pinned rather than the version currently published, because the README gives no compatibility statement between the two packages. The upgrade cost is likely concentrated in the connector interfaces, since those are the contract the SDK exposes; a change there propagates into every provider you have configured.
Editorial conclusion
Adopt SRE if you are writing agent logic in TypeScript and you expect to move between LLM, storage or vector providers, because the connector layer is where the work has gone. Do not adopt it if you need a visual builder (that is the separate Studio repository) or if you cannot accept an MIT-licensed runtime whose release history the repository metadata does not expose. Verify three things first: that the connector you need is listed in packages/core, that your provider credentials fit the Candidate/ACL model rather than a plain environment variable, and that the version of @smythos/sdk you install matches the SDK documentation you are reading.
Community notes