scribase
All posts
·Scribaseagentsapicli

What 'agent-native' actually means

Bolting an MCP endpoint onto a dashboard-first product does not make it agent-native. It means every mutation is a typed, idempotent, approvable operation.

"Agent-native" is on its way to becoming the most abused word in developer tooling. A dashboard with an MCP endpoint stapled to the side is not agent-native; it is a dashboard with a new way to click the buttons.

Agent-native is a property of the control surface, not a feature you add.

The four properties

Every mutation in Scribase — human or agent — has:

  1. A CLI flag and an OpenAPI operation. The same binary serves people and programs. There is no "API for agents" that drifts from the real one.
  2. An idempotency key. An agent that retries does not double-create. This is the difference between "mostly works" and "safe to automate."
  3. An operation ID. Every mutation returns one, so long-running work is observable and resumable instead of a fire-and-forget guess.
  4. An approval model. Destructive or production actions demand explicit confirmation. Autonomy without a gate is not a feature, it is an incident.

Why the gate matters most

The interesting failure mode of agents is not that they are dumb — it is that they are fast and confident. A control plane that lets an agent drop a table because it "seemed necessary" is a control plane that has not thought about agents at all. The approval model is where agent-native stops being a slogan and starts being trustworthy.

Read the CLI docs and the control API to see the shape of it.