Evidence note: this article draws on two kinds of material and keeps them apart. The first is primary publication by the party making the claim — a vendor engineering blog, a project’s own repository documentation, a company announcement. Those are reported here as what the party said, with the party named. The second is claims that are circulating without any primary publication among the sources available for this article as of 2026-09-22; those are marked unverified where they appear and are not treated as established. Every specific figure — parameter count, licence, benchmark multiple, price threshold, star count — carries its evidence level at the point of use. The short answer up front: the local-agent tooling layer is filling in quickly, while the layer that would let a developer verify an agent’s identity, behaviour, and cost is being retrofitted afterwards, and much of the reporting about that second layer is still thinly sourced.
Agents Everywhere, and the Question Nobody Was Answering
The Wall Street Journal’s framing of the moment is that AI agents are simultaneously everywhere and nowhere — widely announced, unevenly present in actual production work. That gap is the useful lens for the week’s releases. Almost every item below is a piece of supply: weights, runtimes, frameworks, SDKs, edge inference. Very few are pieces of assurance: identity, behavioural testing, cost accounting. A developer choosing a stack today is choosing mostly among things that make an agent run, not things that make an agent checkable.
The Scale Already Reached: 180,000 Stars and 2.3 Million Agent Accounts
Two numbers are being passed around as evidence that agent adoption has already crossed into mass scale: roughly 180,000 GitHub stars for the OpenClaw project, and 2.3 million agent accounts on a platform called Moltbook. (Evidence level: unverified — no primary announcement or repository page for either figure appears among the sources available for this article; both should be treated as claims, not counts.)
The asymmetry between the two is worth noting even so. A star count is independently checkable by anyone in about ten seconds against the repository page. A platform’s internal count of "agent accounts" is not externally auditable at all, and the definition — registered, active, distinct, human-supervised — changes the number by an order of magnitude. Developers citing that second figure in a design document are citing a definition they have not seen.
The Weights Came Down First: Muse Glimmer, a 30B Multimodal Model Under Apache 2.0
The most consequential claim in circulation is that Muse Glimmer — described as the first open model from Meta Superintelligence Labs — is a 30-billion-parameter multimodal model released under the Apache 2.0 licence and aimed specifically at local coding agents, with runtime instructions published on Ollama’s model blog. (Evidence level: unverified — the parameter count, the licence, the "first open model" status and the coding-agent positioning are not independently corroborated here.)
If the licence term holds, it is the part that matters most. Apache 2.0 is permissive about commercial use and redistribution in a way that most "open weight" model licences of the last two years were not, and a permissively licensed 30B multimodal model is small enough to sit on a single workstation. The question of what such a model actually executes on has a separate answer worth reading alongside this one — see the earlier look at how Muse Glimmer runs on ExecuTorch and who had already built bindings for it.
And the Runtime Met Them: Ollama’s MLX Engine, DFlash, and Image Input
The companion claim is that the model is immediately runnable through Ollama, accelerated by Ollama’s MLX engine, with native DFlash support and image input, per Ollama’s own post. (Evidence level: unverified — the acceleration path and the two feature claims have not been independently confirmed, and no throughput figure is available at all.)
Note what is absent: there is no published tokens-per-second number, no memory footprint at any quantisation, and no hardware baseline. "Accelerated" without a figure is not a performance claim a developer can plan against. Anyone sizing a machine for this should expect to measure it themselves.
Frameworks Built for Your Own Hardware: OpenJarvis v1.0 and LFM2.5-2.6B
Two framework-layer items point the same direction. OpenJarvis v1.0 is described as an open-source framework for building personal AI agents that run on the user’s own hardware, with Ollama support built in, again via Ollama’s blog (evidence level: unverified — the version number, the licensing posture and the scope of built-in support are uncorroborated here). Separately, Liquid AI has published LFM2.5-2.6B, a 2.6-billion-parameter model positioned for deploying agents across devices (evidence level: unverified — the device-deployment positioning is Liquid AI’s own framing and the parameter figure is not independently checked).
The pairing is the interesting part. A 30B model and a 2.6B model are not competitors; they are two ends of a placement decision. The 2.6B class is what fits on a phone or an embedded board with room left for the application; the 30B class is what a developer workstation can hold. A stack that assumes one size will not survive contact with the other.
Levlex Left the Cloud Above $100 Per User
Levlex is reported to be a local AI agent application for personal computers that pivoted away from a cloud model, with the stated reasons being cloud usage costs above $100 per user and user demand for local execution on performance and privacy grounds. Running it locally is said to need 16GB–32GB of RAM and to permit custom local models rather than a single fixed provider. The claim traces to a community discussion thread rather than a company announcement. (Evidence level: unverified — the $100-per-user figure, the RAM range and the stated motivations are all single-source and second-hand; no vendor post corroborates them here.)
The $100 figure, if real, is the number most worth arguing about, because it is a per-user average, and agent workloads are notoriously long-tailed: a handful of heavy users can carry most of the bill. A pivot justified by an average may be a pivot justified by a tail. The "local" label also deserves the scrutiny applied previously to Perplexity’s Portable Computer, which runs on the user’s machine while its own browser agent still does not — partial locality is the norm, not the exception.
Type-Safe Tool Calling on the Device: ADK for Kotlin 1.0 and LiteRT-LM
Google has announced version 1.0 of the Agent Development Kit for Kotlin, described as reaching full feature parity with the Python and Java ADK cores, built on Kotlin Multiplatform, and using Kotlin Symbol Processing to generate zero-reflection, type-safe function calling, with Android extensions that integrate local models through LiteRT-LM, according to the Google Developers Blog announcement. (Evidence level: vendor announcement, reported here as Google’s own statement; the parity claim in particular is not independently verified.)
The compile-time angle is the substantive engineering choice. Tool calling is where agents fail most expensively — a malformed argument, a hallucinated parameter name, a type mismatch discovered at runtime on a user’s device. Moving schema generation to a compiler plugin instead of runtime reflection converts a class of runtime failure into a build failure, and removes reflection from a path that Android’s build tooling has historically punished. Whether the generated schemas actually constrain a model’s output is a separate question that code generation cannot answer.
Past the Laptop Entirely: 6.4x on Jetson AGX Thor
NVIDIA reports that TensorRT Edge-LLM completed the MLPerf Edge Agentic benchmark 6.4x faster on Jetson AGX Thor, framing the result around agents moving out of cloud data centres and into vehicles, robots and other edge devices, in its own developer blog post. (Evidence level: vendor-reported benchmark, not independently reproduced; the 6.4x multiple is relative to a baseline defined by NVIDIA, and a speedup ratio without the named baseline cannot be compared against any other vendor’s figure.)
The direction is consistent with the hardware story on the other end of the wire — the data-centre side of the same build-out was examined in this site’s earlier piece on what NVIDIA’s BlueField-4 is actually carrying, and developers who want to understand where such multiples come from at the kernel level may find the step-by-step GPU optimization walkthrough more useful than the headline ratio.
What Cisco’s Security Team Is Reported to Have Found Inside Third-Party Agent Skills
A reservation applies to this section specifically, because it carries the article’s heaviest claim on its thinnest evidence: the report that Cisco’s security team found data exfiltration inside third-party AI agent skills has no primary source among the material available for this article. No Cisco advisory, blog post or paper is available to cite, and nothing here should be read as confirming that such a finding was published, what products it concerned, or what was exfiltrated. (Evidence level: unverified, no primary source located.)
What can be said without relying on that claim is structural, and it is enough to act on. A third-party "skill" for an agent is not data; it is instructions plus code that inherits the agent’s tool access — file reads, network calls, credentials in the environment. An agent that can read a repository and make an HTTPS request already has an exfiltration path, and a skill that asks it to use that path looks, to the agent, like a task. No vulnerability is required for this to work, which is why the plausibility of the reported finding is high even though its sourcing is absent. Treating installed skills as untrusted code with the same review a dependency gets is defensible on the architecture alone.
Identity and Reputation, Added Afterwards
Two projects are attempting to supply the missing assurance layer. Agent Passport is described as an MIT-licensed identity verification layer for AI agents using Ed25519 challenge-response authentication, revocable JWT identity tokens with a 60-minute TTL, and a 0-100 risk score; the claim comes from a single developer post (evidence level: unverified and single-source — the cryptographic design, the licence, the 60-minute token lifetime and the risk-score range are all as described by the project’s author). A2Apex is presented as a testing and reputation platform for agents built on Google’s A2A protocol, running over 50 automated compliance checks and issuing a 0-100 trust score (evidence level: unverified — the check count and the scoring scale are the platform’s own description, with no published methodology available here).
Both are worth reading skeptically in the same way. Ed25519 challenge-response is a solved, well-understood primitive; it proves that a caller holds a key. It does not prove that the agent behind that key will behave. A 0-100 score compresses an unpublished methodology into a number that looks comparable across agents, and neither project publishes the weighting that produces it. The honest reading is that the identity half is technically credible and the reputation half is, for now, a claim about a number.
Testing Behavior Instead of Trusting It
The more durable answer in this week’s material is not a scoring service but an evaluation practice. Google’s engineering write-up on harnesses argues for evaluating, iterating on and guarding coding agents as a build-time discipline rather than a launch-time one, in its anatomy-of-harness-engineering post. NVIDIA’s guidance covers the same ground from the measurement side, arguing for evaluating agents from tool calls through to task completion rather than on final answers alone. (Evidence level: both are vendor engineering guidance — reported as their published positions, not as validated results.)
The common recommendation is the actionable one: assert on intermediate actions. A fast, local, unit-style evaluation that fails when an agent calls the wrong tool, calls it with the wrong argument, or makes a network request it was not supposed to make catches a different failure class than an end-to-end task score such as SWE-bench, which is satisfied by any trajectory that arrives at a passing patch. Why aggregate benchmarks can rank systems without distinguishing them was examined separately in this site’s look at BenchMIRT and the case for behavioural evaluations.
No such evaluation suite was run for this article. Building one against a third-party skill and asserting on its outbound network calls is a proposed follow-up, not a completed test.
Counting the Bill Offline
Cost verification has a matching tool. According to its own repository documentation, Frugon is a local, MIT-licensed command-line tool that reads OpenAI-style logs offline to identify LLM calls a cheaper model could handle, prices its estimates against LiteLLM’s pricing data, gates substitutions by LMArena tiers, and reports savings in bands derived from RouteLLM research. (Evidence level: the project’s own stated description; the tool’s behaviour and the accuracy of its estimates are not independently verified here.)
Two properties make it interesting beyond the category. It runs offline, so audit logs containing prompts do not leave the machine to be analysed — which is a meaningful difference from hosted cost dashboards. And it reports bands rather than a single number, which is the correct presentation for a savings estimate that depends on a routing decision nobody has made yet. Any figure it produces is a derived calculation from published price tables, not a measured bill; it should be treated as a hypothesis to test against an actual invoice.
Developer Takeaway: A Local Stack You Can Actually Check
Assembled from this week’s material, a local agent stack is now plausible end to end: permissively licensed weights in the 30B class for a workstation and the 2.6B class for a device, a runtime that loads them, a framework for the agent loop, a type-safe tool-calling SDK on Android, and edge inference for hardware past the laptop. Every layer of that is announced. The assurance layers — identity, behavioural evaluation, cost accounting — exist as early projects, thin sourcing, or practice recommendations rather than defaults.
The concrete thing to do with that is to add the checks the stack does not ship with. Treat third-party skills as reviewable dependencies. Write unit-style evaluations that assert on tool calls before trusting a task-completion score. Measure throughput and memory on the actual target machine, because no vendor here published a figure for the local case. And read "local" as a spectrum: News Radar, described as an AI news aggregator that selects and summarises articles and can be run as a self-hosted instance with user-customised sources, still requires an OpenAI key to do the summarising (evidence level: unverified — the self-hosting and customisation claims come from the project’s repository and have not been independently confirmed). A local instance that calls a hosted model is a deployment choice, not an independence claim.
The Follow-Up Question That Remains Open
The unanswered question is narrow and testable: does a skill-level behavioural evaluation actually catch exfiltration, or only the clumsy version of it? A skill that asks an agent to POST a file is caught by a network assertion. A skill that asks the agent to include a summary of the environment in a legitimate outbound request is not obviously caught by anything currently proposed — the call is expected, the endpoint is expected, only the payload differs. Until someone runs that test against a real harness and publishes the failure cases, the honest position is that the industry has shipped a great deal of capability and one promising discipline, and does not yet know how much of the exfiltration surface that discipline covers.