When people talk about AI agents and infrastructure, the conversation often jumps straight to tools. Give the agent a terminal. Give it a cloud API key. Give it MCP. Let it fix the deployment.
That skips the part where most production incidents actually go wrong: the agent needs to know which path is safe to follow before it calls anything. Should it plan or apply? Is it allowed to create external resources? Does it need a scoped token? Which readback proves the app is live? If a server is not ready, should it repair the runtime, retry a deployment, or stop and ask a human?
In Appaloft, an AI skill and an MCP server solve different problems. The skill is the operating protocol for the agent. MCP is one callable transport into the control plane. Neither one should become a separate deployment product hiding beside the CLI and Web Console.
This post continues the idea from A deployment control plane for the AI era: AI should call the same deployment path as humans and automation. It should not get a private shortcut.
The skill tells the agent how to think
An AI skill is not an API wrapper. It is closer to a runbook written for a model.
For Appaloft, the skill starts by classifying the user’s intent: deploy, observe, recover, configure a resource, manage domains, inspect runtime usage, handle organization/auth work, or run maintenance. Then it chooses the surface available in the session: CLI, HTTP/API, Web Console, repository configuration, or MCP tools.
That procedural layer matters because deployment is full of decisions that are not obvious from a tool schema:
- check product context before using a hosted control plane
- use a scoped token or an existing profile instead of driving browser login from an agent
- plan before executing when an operation may create infrastructure
- read logs, events, diagnostics, and recovery readiness before retrying
- never print
.envvalues, private keys, tokens, cookies, raw connection strings, or unmasked secrets - clean up through Appaloft lifecycle commands instead of deleting provider state by hand
Those rules are not exciting, but they are the difference between an assistant and an unbounded script runner.
The skill should also stay small enough to load. Long command tables, deploy protocols, surface selection notes, and MCP details can live in references. The top-level skill should tell the agent what kind of work it is doing, which facts to gather, and which boundaries it must not cross.
MCP gives the agent stable calls
MCP solves a different problem: a host can expose typed tools, read-only resources, and reusable prompts to an agent. For a deployment product, that is useful because the agent should not scrape terminal output or guess HTTP routes when a structured tool exists.
In Appaloft’s model, MCP tools map to operation catalog entries. A deployment plan operation, a resource diagnostics operation, a runtime log operation, or a system doctor operation should keep the same meaning whether it is called from CLI, API, Web, or MCP.
That one-to-one mapping is not just implementation tidiness. It prevents a second product from forming.
If MCP had a hand-written quick_deploy_create tool that did not exist in the operation catalog, several things would immediately become unclear:
- which authorization and tenant rules apply
- whether the action is idempotent
- how audit records are emitted
- whether destructive behavior requires confirmation
- how secrets are redacted
- which UI or CLI command can explain the same result to a human
The safer rule is boring and useful: MCP tools should be generated from or checked against the same operation catalog used by the rest of the product. MCP can improve how agents call Appaloft, but it should not invent hidden agent-only behavior.
Resources and prompts are not command handlers
MCP has three concepts that are easy to blur.
Tools execute operations. Resources provide context. Prompts describe reusable workflows.
For Appaloft, an operation catalog snapshot, a deploy protocol reference, or a skill guide can be an MCP resource. The agent can read it to understand available tools and safe workflow context. But a resource should not mutate deployment state, decide policy, or silently repair infrastructure.
Prompts are similar. A prompt such as first deploy, recover a failed deployment, configure a resource, observe runtime usage, or publish a static artifact can sequence existing operations. It can remind the agent to inspect state before acting. It should not own business state, bypass confirmations, or become a new command surface.
This distinction is small in docs and large in production. If resources and prompts start doing command work, the safety model fragments. Operators can no longer answer the basic question: which command changed the system?
Auth is part of the product boundary
AI auth should not be a clever browser trick.
A human can run an interactive login command in their own terminal. An agent should not drive the user’s browser, copy authorization codes, read cookies, or ask someone to paste a long-lived token into chat. The agent path needs a scoped, expiring, revocable credential handed off through a trusted UI, secret manager, environment variable, or CLI-approved token import flow.
That is less magical than “the agent logged in for you.” It is also easier to audit and revoke.
Once authenticated, the same product rules still apply. Hosted Cloud can add team permissions, entitlement checks, tenant context, audit, and policy. Self-hosted Appaloft can keep local control-plane ownership. Enterprise deployments can use private gateway and customer-managed credential patterns. Those differences belong in composition and adapters, not in a new agent-only deployment model.
Plan-first is what makes AI operations reviewable
AI agents are useful because they can turn vague intent into concrete next steps: deploy this repository, install PocketBase, diagnose why the generated URL is down, add storage, inspect a failed rollout.
The dangerous version of that workflow is direct execution. The agent guesses a Docker command, calls a provider SDK, edits state, and then tries to explain what happened afterward.
Appaloft tries to make the intermediate fact visible:
- Identify the project, resource, server, environment, Blueprint, or static artifact.
- Produce a plan when the operation can create or change durable state.
- Show missing secrets, permissions, dependency bindings, and external-resource impact.
- Execute only after user or policy acceptance.
- Observe through events, logs, health checks, diagnostics, and access readback.
- Recover through explicit retry, redeploy, rollback, or repair commands.
That sequence is useful for humans too. AI is not the reason to build a control plane; AI makes the need harder to ignore.
The shape we want
The target architecture is plain:
- Skill: the agent-facing operating protocol
- MCP tools: typed calls into existing operations
- MCP resources: read-only context and documentation
- MCP prompts: reusable workflow sequencing
- Operation catalog: the shared product contract
- CommandBus and QueryBus: the application boundary that actually changes or reads state
- CLI, API, Web, and MCP: peer entrypoints into that same model
That shape leaves room for different deployments. A local developer may use the CLI. A GitHub workflow may use a deploy token. A desktop agent may use MCP stdio. A hosted agent may use a remote tool gateway. Cloud may add authz, audit, and entitlement. Enterprise may run a private gateway.
The important part is that deployment semantics do not fork at the moment an agent enters the picture.
The cost of keeping the boundary
This design creates work.
The operation catalog has to stay current. MCP descriptors need tests. Skill references need evals so the model does not drift into unsafe shortcuts. Auth guidance has to be explicit. Dangerous operations need annotations, confirmations, redaction, and idempotency rules. The CLI and Web Console must be able to explain the same facts that MCP returns to an agent.
That is a better cost than debugging an agent-only path at 2 a.m.
AI agents should be able to deploy, observe, and recover software. They should do it through the same control plane everyone else uses. In Appaloft, the skill teaches the route, MCP gives the callable surface, and the operation catalog keeps the product honest.