Agent operating model

One loop governs every external agent — Claude Code, Codex, Cursor, your own scripts — and it is the same loop the human admin uses, because there is only one write path (ADR 0027).

Token kinds decide execution

The credential decides what a call does; the client is irrelevant. An Ajan (agent) token is propose-only: every live mutation it issues is recorded into a proposal instead of executing, and it is bound to exactly one workspace for design work. A Geliştirici (developer) token executes directly under rev-guarded compare-and-swap. Both call the identical commands, routes and MCP tools — see Tokens for the scope model.

Discovery first

Start every session by asking the platform what exists; never assume from memory:

1. tokens.whoami (GET /v1/tokens/me) — which store, kind, scopes, expiry and workspace this credential resolves to.
2. meta.get (GET /v1/meta) — the platform build and registryHash; compare against your project lock (Version pinning).
3. commands.list and routes.list — the scope-filtered registry and catalog, each entry with JSON Schemas.
4. extensions.list and extensions.ops.get — installed extensions and their live agent contracts (Extensions for agents).

Over MCP the same discovery is tools/list plus the mzk://store and mzk://proposal/current resources.

Parity is CI-enforced

Everything an owner can do in the admin panel, an agent can reach: every admin mutation is a registered command or a catalog route, and CI fails the platform build if the admin uses a capability agents cannot see (G-PAR/G-ROUTES guard families). There is no privileged side channel to miss — if it is not in Commands or Routes, the admin panel does not have it either.

Nothing goes live without the owner

Ajan mutations answer HTTP 202 {proposed: true, auditId: null} — recorded, not applied. The owner reviews the proposal in the panel (Öneriler), and approval is an owner session action: no token of any kind can approve, and self-approval by an agent is structurally impossible. Apply re-checks every recorded preview against the current world before executing (Working with proposals).

Workspaces isolate drafts

Design work happens in the token's own workspace draft, never in the builder's main draft. The workspace has a stable preview URL; the owner adopts the result with one click ("Taslağa al"). The server never merges — see Workspaces.

A stale client is refused, not surprised

Every CLI/Dev-MCP request carries X-Mozaik-Client; a build below the platform floor gets HTTP 426 with the exact upgrade command (mozaik exits 3; MCP answers -32001). Projects pin the platform build in .mozaik/base.lock, so drift is a visible refusal — see Version pinning.

The loop, end to end

1. Owner mints an Ajan token (Getting a token) — for design work, creating the workspace mints the bound token in the same step.
2. The agent discovers (whoami, meta, commands, routes), reads freely, and works: catalog mutations record as proposal items; design edits go to its workspace.
3. The agent submits: proposal.submit with a title and summary; the owner is mailed a review link.
4. The owner reviews previews item by item and approves; the platform applies in order, re-checking each preview, and both proposer and approver land on one audit row.
5. The agent verifies via reads (orders.list, audit.list, proposals.get) — never by assuming success.