Strict actions, then agentic, then MCP

The timeline we optimize for

Starting at MCP or “fully agentic” first usually means burying product logic in prompts and rewriting when you want a simple button again. We want the opposite: each stage reuses the last.

1. Strict actions on the canvas (known verb, known credit cost, known file out)
2. In-app agentic once those actions are proven (Agentic Transform chooses tools + vision QA)
3. MCP so other agents can call the same tools after we trust them

The coding habit: one contract for every action

The trick is not “think about MCP early” as a slogan. It is making every action look the same at the boundary, whether ImageMagick, FFmpeg, or an OpenAI call lives underneath.

Inputs stay structured and named:

• content / file / labeled artifacts
• prompt or tool arguments (a small JSON object)
• automation / project context when the product needs it

Outputs stay structured the same way:

• deliverable: always a file (image, video, audio, or text document)
• agentic log: steps, tool calls, vision QA pass/reject, and critique-style feedback from prior turns when available
• type / label so the next step (or MCP client) can find the file

In code, mid-loop tools speak a shared shape (ToolResult with labeled Artifacts). The product boundary stays simple: file out, logs explain how you got there. Canvas transforms lean the same way, with action-level activity when something fails.

Stage 1: strict actions

Canvas automations are verbs: text-to-image, text overlay, merge layers, lipsync, and so on. Each one calls a focused service. Humans wire them; the platform never improvises which node runs.

Because I/O is consistent, we get easy wins:

• easy specs (fixture in, assert type/file out)
• credit costs keyed by action name
• DAG chaining and workflow presets that only care about edges and states

If overlay rendering is wrong, fix the transform. Do not teach an agent ImageMagick.

Stage 2: agentic in the app

Agentic Transform did not invent new media code. It wrapped the same capabilities as tools with JSON schemas, then let a runner choose among them.

• tools stay thin: parse args → call the service → pack a ToolResult
• runner stores labeled artifacts and passes them to the next tool
• at the end: a file deliverable, plus an agent log of steps and critiques

Shared I/O is why this felt incremental. Retries, Activity, and later MCP can read that log as history. None of it replaces the deliverable file. See also Building Agentic Transform.

Stage 3: MCP for other agents (shipping later)

MCP is how external agents will discover and invoke the same tools. The in-app agent already runs through a shared registry and session; a thin MCP gateway (Ai::Mcp::Server) is the next wrap once we want other agents to call those tools. Public auth and transport are edge work — not shipped yet.

• auth and transport at the edge
• map protocol calls onto Session (same allowlist / artifact bus as the in-app agent)
• expose only tools that already survived in-app agentic use

Keep credits, project scoping, and QA policy outside the action core. MCP should not become a second implementation of compose. Tools define a canonical name + input schema; LLM tool-calling and MCP shapes are adapters.

Why the next step stays easy

Natural evolution is a property of code shape. If each stage needs a new I/O model, you were not ready for agents. If wrapping is almost mechanical, you can ship MCP when the product asks.

• same nouns: action / tool / MCP tool
• same verbs: structured args in, file (+ log) out
• same registry: name → class → execute
• policy outside the tool (Session; Runner adds LLM + vision QA, MCP adds protocol)

Checklist

Before promoting a capability up the timeline:

1. structured inputs and a file deliverable?
2. agentic log for steps / critiques when needed?
3. canvas node works with no LLM in the stack?
4. agent tool is a thin wrap, not a copy of media logic?
5. MCP could list the same name + schema without a rewrite?