AI Agents, Skills and MCP

Classic RPA automates work you can write down as rules. A great deal of real work is not like that: read this invoice and decide which cost centre it belongs to has no rule set, only judgement.

Robomotion's answer is not to replace flows with agents. It is to let a flow delegate the judgement and keep the determinism everywhere else. This page explains how the pieces — agents, tools, skills and MCP servers — relate, because the words are easy to confuse.

Flow or agent?

Not a stylistic choice. It follows from whether the work has a decidable rule.

Use a flow when	Use an agent when
The steps are the same every time	The next step depends on judgement
A wrong answer is a bug	A wrong answer is a possibility to design around
You need the same result every run	You need a reasonable result over varied input
Auditors need to read the logic	Explaining the reasoning is enough

Most good automations are both: a flow that runs on a schedule, does the deterministic work, and calls an agent for the one step nobody can specify. Keeping the split explicit is what makes the result debuggable — you can see exactly where determinism ended.

The four things, and how they differ

Nodes

The building blocks of a flow. Open Browser, Read File, Send Message. Each does one specified thing and is documented in Packages. Nothing AI about them.

Tools

A tool is a node an agent is allowed to call itself. Same node, same properties, same implementation — the difference is who decides when to invoke it.

In a flow, you wire Send Message into position three. As a tool, the agent decides whether sending a message is the right move. Package pages mark these: "This node is also exposed as an AI Agent tool."

Many packages also ship a single Toolkit node that exposes the whole package's operations at once, which is usually what you want rather than wiring twenty tools individually.

Skills

A skill is written instruction, not code. It tells an agent how your organisation does something — the approval thresholds, the naming conventions, which exceptions matter.

Skills are versioned, discoverable and installable, with an author and a category, from skill repositories you register. They are how an agent stops being generically capable and starts being useful in your specific business.

The distinction worth holding on to: a tool is a capability, a skill is judgement. An agent with a Google Sheets tool can write to a spreadsheet. An agent with your "month-end close" skill knows which spreadsheet, in what format, and what to do about a row that does not balance.

MCP servers

MCP (Model Context Protocol) is how an agent reaches capabilities that are not Robomotion packages. An MCP server is the MCP counterpart of a skill: discovered from a registered repository, carrying the same attribution and versioning, plus a launch specification and an environment contract describing which variables it needs.

Use MCP when a capability already exists as an MCP server and you would rather adopt it than write a package. Use a package when you want a node your flows can use directly too — an MCP server serves agents, a package serves both.

Putting it together

A realistic invoice pipeline:

Schedule (07:00)
  → Mail: fetch unread attachments          flow, deterministic
  → For Each attachment                     flow
      → Document Processor: extract text    flow, deterministic
      → Agent: "which cost centre?"         judgement
           tools:  Google Sheets (lookup the chart of accounts)
           skill:  "Acme cost centre rules"
      → Switch on confidence                flow
           high   → post to the ERP         flow
           low    → queue for a human       flow
  → Mail: send the run summary              flow

Note what is not delegated. Fetching mail, looping, posting to the ERP and reporting are all deterministic and stay in the flow. The agent is asked one question it is actually suited to. And the answer is routed by confidence, so an uncertain classification becomes a queue item for a person instead of a wrong posting.

That last point is the one most worth copying. Design for the agent being wrong. A confidence threshold and a human queue turn an unreliable step into a reliable process.

Where things live

What	Where
Agents	Designer → Agents; Admin Console → Agents for runs and review
Skills	Designer → Skills, from registered skill repositories
MCP servers	Designer → MCP, from registered MCP repositories
Tools	Marked on each node's page in Packages
Knowledge	Designer → Knowledge Base, for grounding an agent in your documents

Programmatically, agents are at /v1/agents.* and the hosted agent hub at /v1/agent.hub.* — both in the API Playground.

Choosing a model

Robomotion is not tied to one provider. There are packages for Claude, OpenAI, Google Gemini, Ollama for local models, and OpenRouter for many behind one interface.

Two practical notes. Local models via Ollama matter when input must not leave your network — the same reasoning as deployment topology, applied to prompts. And a cheap model with a good skill frequently beats an expensive model without one, because most failures come from missing context rather than insufficient capability.

Next

• Tutorials — the flow fundamentals an agent gets embedded in
• Robot — where agents run
• Security Model — what an agent's tools can reach