Mikel Studio · Issue #4
Run Agents Like Managed Dependencies
Separate authority from reasoning—and make runtime upgrades deliberate.
Production agents introduce two kinds of change at once: they can request consequential actions, and the platforms they run on can evolve underneath them. This edition focuses on the operating disciplines that keep both manageable: a clear decision boundary for actions, and a release process for the runtimes that enable them.
What We Learned
Put a policy decision between intent and execution
Misalignment reporting is a useful reminder that an agent incident is not always an incorrect answer. It can involve an attempted action: using credentials outside scope, uploading a file, or communicating through an unintended channel.
The practical design move is to treat the model as a requester, not an authorizer. Let it propose a tool call, but send that call through deterministic policy infrastructure that decides whether the operation may run. The decision should be based on the operation, target, account or environment, risk level, and time window—not on the model’s confidence or explanation.
Start where consequences are hardest to undo. Issue short-lived, scoped credentials rather than exposing raw secrets. Restrict outbound destinations. Isolate each run’s filesystem workspace. Classify writes: drafts and internal tasks may need logging and policy checks, while customer messages, public uploads, production deployments, deletions, and billing changes may require destination validation or human approval.
This is also a product-design question. If an agent can prepare a reply but not send it, the workflow needs a clear review and handoff state. Build those boundaries early, then expand permissions only when operational evidence supports doing so.
The Signal
Give the agent runtime a release-management home
Google’s antigravity-preview-09-2026 replaces the May managed coding-agent preview and adds native search and line-range file-editing tools. That is more than a feature update: when a managed runtime changes its tools, tool contract, or editing behaviour, integrations around it can change too.
Treat the runtime like any other versioned platform dependency. Pin the production version rather than silently inheriting a new preview. Keep a small compatibility suite that exercises the tool names, parameters, response formats, error cases, and file operations your workflow actually relies on. Record deprecations with an owner and migration date.
Then make upgrades a routine release path: test the new runtime in staging, compare behaviour on representative tasks, check permissions and observability, and retain a rollback option before moving production. Native tools can affect wrappers, evaluation suites, and failure handling even when no prompt has changed.
The objective is not to freeze the stack. It is to make runtime changes deliberate, observable, and reversible—before a deprecation deadline turns an upgrade into an incident.