SmythOS SRE puts one API in front of eighteen connectors, and its root package metadata is still blank

The kernel metaphor is the pitch, and the connectors are the payload

The readme calls this project the Linux of AI agents, and the title is doing real work rather than decoration.

The argument is analogy. An operating system manages resources and exposes stable interfaces so applications do not have to know what is underneath. This project does the same for the resources an agent needs: language models, vector databases, storage and caching. You get one API that behaves the same across providers, and the stated goal is writing agent logic once and running it anywhere.

What is bundled alongside that abstraction is the unglamorous part, and it is what makes the abstraction usable in production. Forty plus components, built-in security, built-in observability, and a component set for data processing and integrations rather than for model calls only.

The architecture is a monorepo of three packages, mapped one to one onto the operating system picture. The core package is the kernel, the runtime that other things run on. The SDK is the application-facing layer over it. The CLI is the installer and scaffolding tool.

So the pitch is not that agents need better prompts. It is that agent software has the same portability problem ordinary software had, and this is one answer to it.

Five resource families and eighteen named connectors

The connector table is the part to read, because a resource abstraction is only as good as its implementations.

Five families are covered. Storage has four: local disk, S3, Google Cloud and Azure. Language models have six: OpenAI, Anthropic, Google AI, AWS Bedrock, Groq and Perplexity. Vector databases have three: Pinecone, Milvus and an in-memory one. Caches have two: in-memory and Redis. And secret storage has three: a JSON file, AWS Secrets Manager and HashiCorp.

That is eighteen connectors across five families, and the distribution is informative. Language models are the widest, which matches the audience. Storage is broad because it is the easiest thing to get wrong by hand. Caches are narrow because RAM and Redis cover most real use.

The vault family is the one that deserves attention. Secrets management is listed alongside storage and model access rather than being left to your deployment, and it is backed by the same interface, so an agent reading a credential goes through the same abstraction as an agent calling a model.

The in-memory options matter too. A vector store and a cache that live in RAM mean you can develop and test an entire agent with no external service at all.

Access control is a named subsystem, not middleware you bolt on

Security is one of the four reasons the project gives for existing, and it is described as built in rather than added.

The mechanism is named: a candidate and access control list system for securing resource access, living in the core package. In an agent system, the interesting question is not whether a model can reach a file, it is which component is asking. Identity that lives in the runtime rather than in a gateway means the check happens where the request is made.

The stated benefit is enterprise security through built-in access control and secure credential management, and the second half of that is carried by the vault connectors. A credential is retrieved through the same interface as a model is called, so the path that reads a secret is a path the runtime can see and gate.

One of the four principles is worth quoting because it is unusually honest for a platform readme: autonomy and control can, and must, coexist. That is the tension every agent framework has to answer, and stating it as a design constraint rather than a feature is a better sign than claiming to have solved it.

The fourth principle, that an internet of agents should stay open and accessible, is the reason the whole thing is MIT licensed.

Two install paths, and the CLI exists so you do not have to configure one by hand

Getting started is two commands, and the readme tells you which one to use.

The recommended path installs the command line tool globally and then creates a project:

npm i -g @smythos/cli
sre create

The alternative adds the SDK straight into an existing project, which is the whole install command. That route is for people who already have a codebase and want the abstraction without a generated project around it.

The reason the CLI is recommended is stated plainly: it guides you through creating a project with the right configuration for your needs. In other words, the configuration is part of what you are getting help with, which implies it is not something you can guess from the readme.

There is also a separate open source repository for a visual drag and drop agent builder, and the SDK can load agents produced by it. The two installation paths therefore span a spectrum from a graphical builder through a scaffolding CLI to a library you import yourself.

One troubleshooting note is worth keeping: if the CLI or your code misbehaves, set the log level environment variable to debug, run it again and share the logs. That is a small thing that tells you debugging is expected rather than exceptional.

The examples teach every resource twice, once raw and once through an agent

The examples directory is numbered and ordered, and the numbering encodes a teaching method.

Three pairs repeat the same structure. Vector databases appear twice, once with no agent and once with an agent. Storage appears twice, in the same shape. Cache appears twice, again in the same shape. The pattern is deliberate: the resource is introduced as a plain API first, and then used through an agent, so you can see what the abstraction costs before you depend on it.

Around those pairs sit single-topic directories covering agents written in code, agents loaded from a file, workflow components, custom runtime configuration, local models, a scheduler, observability, secrets, a web application in worker mode, and a numbered set covering SDK core features.

The numbering has gaps and one outlier. Two numbers in the single digits are missing, and the web application directory is numbered one hundred, which puts it after everything else regardless of how simple it is. Small, and the kind of thing that tells you the list grew by accretion rather than by design.

The directory list also includes one vendor-specific realtime meeting integration, which is the clearest sign that connector work for commercial products is part of the plan rather than an accident.

The root package metadata is empty while the readme is finished

The repository root has a package file with several fields nobody has filled in, and it is the only place a version number exists.

The description field is an empty string and the keyword list is empty. The author is a single named person. The licence is MIT, matching the readme and the licence file, and there is a notice file beside it.

The version is 0.5.0. There are no published releases for the repository, so that number exists only in the package file and in whatever has been published to the registry. If you install from the registry you get a version the repository has never tagged, which means you cannot map an installed version back to a commit without reading the registry metadata.

Two other details are worth noting for anyone building on it. Workspace configuration appears in two places at once, once in the package file and once in the workspace file that the package manager actually prefers. And the prepare script installs git hooks, so a plain install in a fork of this repository writes to your hooks directory.

None of that blocks use. All of it is the residue of a project whose public face is polished and whose package metadata has not caught up.

A .smyth file is the handover format between the builder and your code

The one architectural decision that affects how you work is where the model is chosen.

An agent built in the visual builder is saved as a file with a particular extension, and the SDK loads it by path while being handed a model at the same moment. The import call takes the agent path and an options object containing the model, constructed through a factory for a specific provider and model name. The agent is then prompted and returns a result.

So the workflow definition and the model are separate. One artefact carries the graph of steps that a person drew, and the other carries the intelligence that executes it. That means the same saved agent can run against a cheap model for testing and an expensive one for production, and it means swapping providers is an argument at the call site rather than a configuration file.

Streaming is the other detail. The same prompt call can return an event stream instead of a final result, with separate events for content as it arrives, for the end of the run, and for usage. Usage as a first class event is what makes token accounting possible without instrumenting the provider client yourself.

Editorial conclusion

This is worth a look if your agent code is full of provider-specific branches, because the abstraction is the product and the connector list is the evidence that it is real rather than aspirational. Two things to check before you commit. The abstraction is not free: every resource you route through it inherits the interface's shape, so a provider with an unusual capability will be awkward to expose. And the project's own signals are mixed, with a polished readme and video tutorials next to a package file whose description field is empty and a repository with no published releases at all. Judge it on the code and the examples, and pin the package version yourself.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. SmythOS/sre on GitHub