Google's ADK for Kotlin Hits 1.0, Meta's Muse Lands on Mac: The Permission Question

What actually shipped

Google's Agent Development Kit for Kotlin reached 1.0 on September 9 — Google's framing is 'complete alignment with ADK Python and Java,' meaning the same orchestration, tool-calling, and memory primitives Google's server-side agent SDKs already had are now idiomatic Kotlin. The Android-specific parts are the more interesting half: on-device inference via LiteRT-LM and ML Kit (beta), hybrid cloud/on-device routing through Firebase AI Logic, and state persistence across process restarts using Room and AppSearch. It also ships hierarchical multi-agent delegation — a parent agent handing sub-tasks to children — plus built-in human-in-the-loop confirmation hooks and KSP-generated, type-safe tool schemas at compile time rather than runtime reflection.

On the same beat, Meta pushed its Muse assistant onto macOS. Muse for Mac can organize a downloads folder, track down a lost file, or summarize messages and notes — but only across data sources the user has explicitly granted it permission to touch. Coverage of the rollout also surfaced friction: some users reported Muse reading direct messages on Mac, which Meta says only happens under consent the user already gave, not a bypass. That gap between 'technically permissioned' and 'felt like a surprise' is the actual story.

Why this matters beyond the release notes

Neither release is really about Kotlin syntax or a to-do-list assistant. Both are vendors answering the same question agentic-dev teams keep re-deriving from scratch: does the agent get standing access and move fast, or does it have to ask before every sensitive action and stay auditable? Google's answer, at the SDK level, is to make human-in-the-loop confirmation a first-class primitive — so the developer building on ADK has to actively decide to skip the ask, rather than bolt permission-checking on after the fact. Meta's answer, at the product level, is consent scoped per data source — but the Mac rollout shows that 'the user granted this at some point' and 'the user expected this right now' are not the same thing, and the complaints landed exactly in that gap.

That distinction is the one worth stealing if you're building any agent that touches consequential state — a codebase, a trading position, a customer's account. A framework can give you the *primitive* for a confirmation gate; it can't decide *which actions* deserve one. That's a product and risk decision, not an SDK default, and it's the same decision an LLM-in-the-loop trading system has to make explicitly: which calls execute autonomously, and which pause for a human, every time, regardless of how confident the model sounds.

• Treat 'the framework supports human-in-the-loop hooks' as necessary, not sufficient — you still have to enumerate the specific actions that get gated.
• Scope permission per action type, not per session — a one-time grant to 'read files' is a different risk than a one-time grant to 'send money' or 'place an order.'
• Expect the same complaint Meta got: technically-consented access that still surprises the user (or the trader) erodes trust faster than an outright bug.

The bigger pattern

Zoom out and this is where agentic dev tooling is actually heading in late 2026: less about which model powers the agent, and more about the scaffolding around it — on-device inference to cut latency and cost, structured multi-agent delegation instead of one giant prompt, and permission models that are explicit enough to audit after something goes wrong. That scaffolding is exactly what separates a demo agent from one you'd trust with production data or a live order book.