# RunAgent's newest release predates its last commit, and its memory feature is coming soon > runagent-dev/runagent is a CLI and set of SDKs for deploying agents written in Python from other languages, with a hosted serverless tier and a self-hosted scheduler as a companion project. The version story is untidy: the newest tag is four months older than the last commit, the platform's memory feature is announced and not shipped, and the SDK table has three empty cells and two duplicated links. **runagent-dev/runagent** — RunAgent simplifies serverless deployment of your AI agents. With a powerful CLI, multi-language SDK support, built-in agent invocation & streaming suppprt. - Repository: https://github.com/runagent-dev/runagent - Website: https://run-agent.ai - Stars: 482 · Forks: 77 - Language: Python - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/runagent-dev-runagent ## The newest release tag is four months older than the last commit The manifest declares version 0.1.49, and the newest release tag carries the same number. The dates do not line up. That tag was cut on 2026-02-04, while the last commit to the default branch is dated 2026-06-27, so the branch has moved roughly four and a half months past the newest release without a tag. What is in those four and a half months matters, because the news items at the top of the documentation describe two architectural changes that postdate the tag. The first, dated March, announces a unified engine intended to run agents both as serverless functions and as always-on services, with one codebase behind both modes, delivered as three named components in Go and Rust. The second, dated December, is a separate self-hosted scheduling project published as its own repository. So the engine described in the news section is not in any tagged release, and installing from the published package gives you the February state rather than the June one. Two smaller oddities sit in the release list itself: two of the three recent tags were cut on the same evening less than an hour apart, and the numbering jumps over one patch release between them. The manifest itself is unremarkable on this point: a beta classifier, a floor of Python 3.9, and classifiers naming four interpreter versions. ## The platform's memory feature is announced and marked as not here yet The description of the platform leads with what it calls stateful self-learning capabilities, with the memory component named after the platform and marked as coming soon. The sentence around it is also where the cross-language claim lives: build an agent once in Python with any of several agentic frameworks, then reach it natively from another language. That memory feature is the part that would change how these agents behave over time, since without it every invocation starts from nothing and a caller has to carry context itself. It is also the part that is not in the repository. A reader scanning the feature paragraph could easily take the self-learning line as a description of the shipped platform rather than of the roadmap, which is why it is worth separating the two: what exists today is the deployment plumbing, the entrypoint configuration, the local server, and the SDKs. The other half of the value proposition, calling an agent from a language other than the one it was written in, is fully present. That part is a config file, a set of entrypoints, and one SDK per language, and it is the part this repository implements. ## The SDK table has three empty cells and two links repeated The header carries a table of six SDK columns, one per language, each linking to a repository, with a second row underneath for the package registry. The second row is where the table falls apart. Three of its six cells are empty, and the remaining three are not all new: the Dart and C# cells repeat, character for character, the registry addresses already given in the first row. So of the twelve registry links the table appears to offer, three are absent and two are duplicates. The languages affected by the missing cells are the first three columns, which are also the ones the prose describes as having native support. A reader looking for where to fetch the package for one of them finds nothing at that position, and a reader looking at the last two sees the same address twice with no indication that anything is missing. It is a small defect in the most prominent element of the page, and it is the kind that survives because the links still work for the four languages that are filled in. Nothing checks the table, and the repository does contain a checklist file for SDK parity, so the intent to track this was there even if the rendered table did not end up matching it. ## Five SDKs live in this repository and two are named differently from the table The top level of the repository holds six SDK source trees side by side: the Python one, plus directories for TypeScript, Rust, Go, Dart and C#. So this is a monorepo, while the table at the top of the documentation links each language to a separate repository, including a Python repository that is not this one. Two of the names do not match between the two views. The Rust column advertises a package abbreviated with two letters while the directory spells the language out, and the JavaScript column advertises one package while the directory is named for TypeScript. Neither is wrong on its own, but a contributor looking for the Rust SDK in this tree will not find it under the name the documentation uses, and the same goes for the TypeScript tree behind the JavaScript label. The Python side is laid out differently again: the package directory sits beside a module entry file at the repository root, which suggests the root file is the console script target rather than a library module. Alongside the SDK directories are a changelog generator configuration, a release script, a clean-build script, a build scripts directory, separate test and test-script directories, and the SDK checklist file, which is a markdown document rather than anything automated. Parity across six languages is tracked by hand. ## Keys go into a project JSON file and onto the command line Every project needs a configuration file, and the example one shows how credentials are handled. The file carries metadata, an architecture block with an entrypoints array, and an env_vars object. In the example, the env_vars object contains a provider API key written out as a literal string value in the JSON. That means the key sits in plain text in the project directory, in a file that a reader would reasonably commit, share, or copy into a template. The documentation does not point at an environment lookup instead, and the project does depend on a dotenv loader, so the pieces for the safer pattern are present and unused in the example. The cloud path repeats the pattern in a different way. Authentication is a command that takes the key as an argument: ```bash # Authenticate (first time only) runagent setup --api-key # Deploy to cloud runagent deploy --folder . ``` A key passed on the command line is visible in the shell history file and in the process list for as long as the command runs, and it is written in the documentation in exactly that form. The install step has the same shape and is a single line: `pip install runagent`. For a tool whose selling point is running other people's agent code, having its own credential handling be the weakest link in the chain is the detail to fix first. ## Six exact pins, two HTTP clients and two prompt libraries The dependency list mixes three pinning styles. Six packages are pinned to an exact version, and they are the ones the local server is built on: the ASGI server, its web framework, an ORM, the websocket library, an HTTP client and a JSONPath implementation. Nine more carry a floor only, including the command line parser, the terminal library, the validation library, YAML support and a version-control library. Exact pins on the four server-side packages are defensible for reproducibility, and they are also the four that will accumulate security fixes without arriving automatically. The two exact-pinned extras are worth a second look for a different reason: both a modern HTTP client and the older requests library are dependencies, and both a declarative prompt library and an interactive prompt library are dependencies as well. So the same two jobs are filled twice, and which one a given code path imports is not something the manifest tells you. Development extras add the usual battery, four pytest plugins, two formatters and two linters, which is unremarkable. The interpreter range is the one other loose end: the floor is open ended while the classifiers stop naming versions at 3.12, so a newer interpreter will install the package without being claimed as supported. ## Sixteen example directories, one retired and one with parentheses in its name The examples directory holds sixteen project folders, and two of them are about status rather than content. One is explicitly marked as deprecated. Another has the word developing in parentheses inside the directory name itself, which is a small but real hazard: parentheses are shell metacharacters, so the path has to be quoted or escaped in any command that touches it, and the same characters have to survive URL encoding for anything that serves the directory. The rest are ordinary agent examples, several of them variations on the same shape: a retrieval agent, a book writer, a trip planner, a lead agent, a journalist agent, a recipe creator, a screenplay writer, a paper-to-flow pipeline, a stock agent, and a persistent variant with the same word in its name twice over. Two smaller items sit alongside. The local server allocates its own port rather than binding a fixed one, which keeps two projects from colliding but means anything that needs to reach the local server has to discover which port was chosen. And the repository description carries a typo in its final word, a small thing that suggests the description was written once and not revisited since. ## Conclusion Use it if you have already written an agent in Python with one of the supported frameworks and want the same functions callable from TypeScript or Go without a rewrite, since that is the part the repository actually implements. Do not plan around the platform features rather than the tooling: stateful memory is announced and marked as not yet available, and the always-on execution mode described in the news items postdates every tagged release. Before you deploy, move your credentials out of the two places the documentation puts them, a key written into the project JSON and a key passed on the command line, and check the version you install against the tag you expected, since the published release is months behind the branch. ## FAQ ### What is runagent-dev/runagent? A command-line tool and SDK for deploying, managing and interacting with AI agents. You build the agent in Python with a framework such as LangGraph, CrewAI or Letta, describe its entrypoints in a JSON configuration file, and then call those functions from other languages through the platform's per-language SDKs. ### How many SDKs does RunAgent publish? Six columns appear in the table at the top of the README, covering Python, JavaScript, Rust, Go, Dart and C#. Five of the six SDK source trees are directories inside this repository rather than separate projects, and two of the directory names differ from the names the table advertises. ### Where does RunAgent keep API keys? In two plain-text places. The example agent configuration carries an env_vars object with a provider key written directly into the JSON file in the project, and cloud authentication passes the key on the command line as an argument to the setup command, which also leaves it in your shell history and in the process list. ### Does RunAgent Memory exist yet? Not yet. The README describes stateful self-learning capabilities through a memory component and marks it as coming soon, so the feature that would let an agent retain context and improve over time is announced rather than shipped. ### How do I run a RunAgent agent locally and then deploy it? Serve the project directory with the serve command pointed at a folder, which starts a local FastAPI server with auto-allocated ports, real-time debugging and logging, WebSocket streaming, and API documentation at /docs. Cloud deployment is separate: authenticate once with the setup command taking an API key, then deploy the folder. ## Sources - [Issues](https://github.com/runagent-dev/runagent/issues) - [Project website](https://run-agent.ai) - [README](https://github.com/runagent-dev/runagent/blob/main/README.md) - [Releases](https://github.com/runagent-dev/runagent/releases) - [runagent-dev/runagent on GitHub](https://github.com/runagent-dev/runagent) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/runagent-dev-runagent