What Autonomy is not

Autonomy’s scope is deliberately narrow. Knowing what it refuses to become is as useful as knowing what it does — it tells you what to expect (and not expect) when you connect an agent to it.

Before adding any feature, the project asks one question: does this help an agent better support a disabled person through their real accessibility setup? If the answer is no, it is treated as drift, not a roadmap item. The boundaries below are the direct output of that filter.

Mental model: the one filter every feature passes through

Autonomy will not become

A generic desktop clicker. Coordinate-based, screenshot-guessing automation is the fallback path, never the default mental model. If a task can be done through the accessibility tree, keyboard focus, or a typed contract, that path wins over pixels every time.

A silent screen-control agent. An agent driving the screen through Autonomy is expected to narrate what it is checking, what it found, and what it is about to do — especially before anything irreversible. Silent control defeats the entire premise for a screen-off user.

An autonomous credential, payment, or account-recovery actor. Entering credentials, completing 2FA, spending money, and recovering an account are not “elevated, ask first” actions — they sit in an unconditional deny set that no trust level, operating mode, or configuration can override. Autonomy will tell an agent that this is blocked; it will not do it on the agent’s behalf.

A product-claim engine without measured evidence. Every piece of runtime output distinguishes what was observed, inferred, user-declared, unknown, or not measured. A tool call succeeding is not the same claim as “the user heard this” or “this was verified visually” — see the accessibility model for how that distinction plays out in spoken output specifically.

A private surface hiding accessibility-critical contracts. The protocol types, MCP tools, CLI, and consent model are public core, on purpose. A disabled user’s safety should never depend on reading a paid tier’s source code.

A dumping ground for unrelated agent experiments. Autonomy’s repository boundary is enforced structurally, not just by convention — features that are merely “useful in the abstract” but don’t serve the accessibility mission belong somewhere else.

What was retired, on purpose

Earlier, Autonomy hosted its own in-app agent conversation: the app would spawn a codex exec subprocess directly, parse its output, and render a reply. That path — internally called nightgram — is retired from the app and build. It is not bundled, signed, or launched, and its source is excluded from the Rust workspace. The reasons matter for understanding today’s shape: that path coupled Autonomy to each agent’s CLI plumbing, added a heavy indirection chain, and implied Autonomy would keep reimplementing what agent ecosystems already build themselves. See MCP-native architecture for what replaced it.

Not yet, and said plainly

Autonomy is macOS-first today. Linux and Windows accessibility backends exist in the core runtime, but they are less validated and are not the packaged operator experience yet — don’t assume cross-platform parity from the existence of the code. iOS and Android are future targets, not current surfaces.

A quick self-check

If you catch yourself describing a feature idea as “just automate this click” or “just let the agent handle it quietly,” that is usually the signal you’ve stepped outside these boundaries. Compare it against the safety-class model and the accessibility model before building it.