On September 21, Apache Fluss shipped 1.0. The next day, AWS published Strands harness under Apache 2.0, and covonaut released v1.1.4 under MIT. Three projects, three different layers of the same stack, all landing inside 48 hours.
They are not competing for the same slot. Strands gives you the agent loop. covonaut gives you a Go runtime for running it in production. Fluss gives you the data those agents read. Reading the three announcements side by side says something about where the rough edges are right now.
AWS Strands harness packages the loop
Strands is an open-source framework for building general-purpose AI agents. It ships with context management, tool handling, and the execution loop already wired up, so you don't rebuild orchestration for every agent. It runs locally or in cloud environments, works with multiple model providers, and AWS says you can get it going with a single line of Python or TypeScript.
The token claim is the part I care about. AWS says Strands uses fewer tokens, and context management is where agent bills actually go. If you run 10,000 agent invocations a day at 40,000 tokens of context each, shaving a third off that context is worth more than any amount of framework ergonomics. But the announcement didn't include benchmark numbers, just the assertion. Before restructuring anything, run your own workload through it and check the bill. Token efficiency claims depend heavily on how repetitive your tool schemas and system prompts are, and yours may not look like the demo.
What AWS is actually selling here is a default. Once Strands is the path of least resistance for Bedrock users, the surrounding services (AgentCore, Knowledge Bases, Step Functions) get stickier. The Apache 2.0 license is real, and the code is portable. The gravitational pull is in the documentation.
covonaut v1.1.4 changes scheduling semantics
covonaut is a Go agent framework aimed at production. MIT licensed, covering the agent main loop, tool calls, graph orchestration, and multi-protocol interoperability. Version 1.1.4 adds a rolling execution pool, full multi-modal reading, and isolation work. Deleted files can be recovered from a recycle bin, which is a small feature that tells you the authors have been burned by an agent deleting something it shouldn't have.
The release notes claim no breaking interface changes, and technically that's true. Bump the module version and everything compiles. But the scheduling semantics of parallel mode changed from full concurrency to a rolling pool with a relaxed policy. Your interfaces are intact; the runtime behavior of your parallel tool calls is not.
That is the kind of change that shows up as a rate-limit spike against a downstream API at 2am, or as a race condition in a service that assumed all tool calls in a batch fired simultaneously. If you want the old behavior, you switch to the newly added hybrid mode, and the framework wants your tools to have declared concurrency safety. I'd read those declarations carefully. A tool that mutates shared state without saying so will now behave differently under the rolling pool, and nothing in the type system will stop you.
Shipping this as a minor version is defensible if the maintainers consider the old semantics a bug. It's also the exact category of change that erodes trust in semver across the ecosystem.
Apache Fluss 1.0 and the stale context problem
Fluss is a streaming storage layer, and 1.0 is its first release since graduating from the Apache Incubator to a Top-Level Project. The numbers are large: over a thousand commits and 450,000 new lines of code, roughly three times what previous releases added.
Two features matter for agents. First, a new Gateway component, a lightweight REST service written in Rust, giving agents HTTP access to metadata, table management, and batch writes. Second, native Python access to context and features, so a Python service can look up user profiles and feature values directly. The Rust, Python, and C++ clients now live in the main repository and release alongside the Java client.
The stale context problem is underrated. Orchestration failures get the blog posts, but a user profile that is six hours old produces a confidently wrong recommendation, and the agent has no way to know it. Fluss sits between incoming events, real-time features, and training data, with Flink for continuous processing and Spark for dataset preparation.
The Rust gateway is the part I find interesting. Agents talking HTTP is a lowest-common-denominator interface that works from any language, including ones Fluss doesn't have a client for. Having the Python client maintained in the same repo as the Java client is a real improvement over the usual pattern, where the second-class client lags by three releases and nobody notices until a protocol change breaks it.
What I'd do with this
For covonaut users: read the parallel mode notes before bumping the module version, and audit your concurrency safety declarations. The upgrade is one line; the debugging session is not.
For Strands: try it on a workload you already have numbers for. If the token savings hold, the framework is worth the dependency. If they don't, you've spent an afternoon and learned something about your own prompts.
For Fluss: the gateway lowers the cost of experimenting. Pointing a Python agent at a test table through HTTP is an afternoon of work. Rewriting an orchestration layer is a quarter. If your agents currently query a warehouse table that refreshes nightly, the experiment is worth running.
One thing I'd like to see that none of these announcements provided: latency numbers. Agent frameworks love to talk about token efficiency and ergonomics, and almost never about p99. For interactive agents, a 200ms context lookup is the difference between usable and not, regardless of how few tokens you burned.