What Counts as Agent-Native?
CLI-Anything is easiest to misunderstand when any one of its features is treated as the whole achievement. A command list is not enough, a generated project file is not enough, and a passing process is not enough. The useful judgment at this point is whether discovery, state, backend execution, feedback, and verification form one continuous path from an agent's intent to a trustworthy result. That test connects the command contract, the source-to-harness lifecycle, and the semantic boundary established so far.
The distinction matters because “agent-native” can describe either an interface or an operating system for work. An interface gives an agent a way to call something. An operating system for work also tells the agent what it can inspect, what persists, which component owns the meaning of an operation, what failure looks like, and what evidence closes the loop. CLI-Anything's architecture is valuable to the extent that these responsibilities reinforce one another instead of merely appearing beside one another in a repository.
The minimum loop has several conditions
A proposed harness becomes meaningfully agent-native only when an agent can first find out what the tool can do, then inspect the current situation before changing it. It must be able to express a bounded operation in terms the target software understands, receive a result that distinguishes success from failure, and reach the real semantic engine when processing or rendering is required. Finally, it needs a way to check the resulting state or artifact instead of treating the harness's own report as conclusive.
These conditions are sequential, but they are not interchangeable. Discovery without introspection produces commands the agent can name but cannot safely target. Introspection without a faithful backend produces accurate descriptions of a state that may never become a correct artifact. Backend execution without verification produces outputs that may exist while silently missing the requested semantics. Verification without persistent state can confirm one operation but leave the agent unable to reproduce or continue the workflow. The strength comes from the connection among the conditions.
Discovery answers “what is available?” A skill document, help command, or catalog entry can identify a harness and its broad purpose. Inspection answers “what is true now?” It may report the current project, objects, tracks, profiles, or session state. Mutation answers “what change should be attempted?” It should be scoped enough that the agent can relate the response to a single decision rather than to an opaque batch. Backend execution answers “which software is allowed to decide what this operation means?” Verification answers “what observable evidence supports the claim that it worked?”
This sequence also makes state ownership visible. The agent owns the intention and the next decision. The CLI owns the interaction contract and often coordinates a project or session model. The target application owns the semantics of rendering or processing. A verifier owns a narrower observation: whether a file exists, has a valid format, contains expected content, or exhibits a requested measurable property. Confusion begins when one layer silently speaks for another—for example, when a wrapper reports a render as complete without checking the backend's output.