Key concepts
Everything in Anter Flows is built from four building blocks: agents, sub-agents, skills, and tools. This page explains what each one is, how they relate to each other, and the decisions you'll make when configuring them.
Agents
An agent is the core unit of work. When you create one, you're defining a persistent configuration that the runtime uses every time a conversation starts.
The configuration has four parts:
| Setting | What it controls |
|---|---|
| Model | Which LLM powers the agent — Claude, GPT-4, Gemini, and others are supported |
| System prompt | The instructions that shape how the agent reasons, what it knows, and how it responds |
| Skills and tools | The capabilities it can draw on during a run (covered below) |
| Permission mode | How much the agent can do without pausing to ask for human approval |
Every agent you create is a root agent — the entry point for a conversation. A message arrives, the root agent picks it up, and it either answers directly or routes work to sub-agents.
Sub-agents and multi-agent routing
When a task is too broad for one agent to handle well, you add sub-agents. Each sub-agent is a specialist with its own model, system prompt, tools, and skills — entirely independent of the root. A billing specialist and a technical support specialist can have completely different instructions and capabilities.
The root agent orchestrates them. It reads the incoming message and decides which sub-agent should handle it. Sub-agents hand work off in one of two ways:
| Mode | What happens |
|---|---|
| Transfer | The sub-agent hands control entirely to another. The original stops; the new one takes over with full context of the conversation so far. Use this when a question clearly belongs to a different domain — a triage agent transferring to a billing specialist, for example. |
| Delegation | The sub-agent keeps control and fans work out to one or more specialists in parallel. Each specialist gets a specific sub-task, returns a result, and the delegating agent synthesizes everything before responding. Use this when a task requires input from multiple domains at once. |
One job per sub-agent
The most reliable multi-agent setups give each sub-agent a narrow, well-defined responsibility. An agent that tries to cover every scenario becomes hard to tune and hard to debug. Keep them focused.
Skills
A skill is a bundle of specialist instructions that an agent can activate on demand. Rather than writing one large system prompt that tries to cover every topic, you assign skills — and the agent loads the right one when the conversation calls for it.
When a skill activates, two things happen:
- The skill's specialist instructions are added to the agent's active context
- Any tools that belong to that skill become available for that turn
The agent manages this automatically. It has access to a directory of the skills you've assigned to it, and it requests the one that best matches what the user is asking. You don't write rules for when each skill fires — the model decides based on the conversation.
Skills versus a longer system prompt
A longer system prompt loads all instructions upfront, whether or not they're relevant to the current message. Skills load only what's needed for the topic at hand. For agents that cover multiple domains, this keeps the context focused — the agent isn't carrying instructions about billing when someone asks a technical question.
Tools
Tools let agents take action. Without tools, an agent can reason and respond in text. With tools, it can query a database, send a message, call an API, look up a record — anything you expose to it.
There are two ways to connect tools:
HTTP tools — you configure a URL and define the input schema the agent should use. When the agent calls the tool, Anter posts to that URL with the inputs the model selected. Secrets and API keys are stored encrypted and injected into the request automatically — the model never sees them.
MCP servers — the Model Context Protocol is an open standard for exposing tool catalogs to AI agents. Connect an MCP server and Anter discovers every tool it exposes automatically. This is the fastest path to giving an agent a large set of related capabilities — like all the tools in your internal platform — without defining each one individually.
Every tool carries a risk category that the permission system uses to decide whether to run it automatically or pause for approval:
| Category | What it means |
|---|---|
read_only | No side effects — queries, lookups, reads |
destructive | Creates, updates, or deletes data |
open_world | Crosses your organization's boundary — third-party APIs, email, payments |
Permission modes
The permission mode is your primary control over an agent's autonomy. It determines how much the agent can do before stopping to ask you.
| Mode | Behavior |
|---|---|
| Always ask | Every tool call pauses for your approval, regardless of risk category |
| Ask for actions | Read-only tools run automatically; destructive and open-world tools pause for approval |
| Autonomous | All tools run without approval — designed for scheduled or unattended runs |
| Tools disabled | No tools are attached; the agent reasons and responds in text only |
When a tool call pauses, you see the tool name, the inputs the agent wants to use, and its risk label. You can approve, deny, or let it time out — if no decision is made within five minutes, the call is skipped and the agent is notified so it can explain or try another path.
Per-tool overrides
The agent-level permission mode applies by default, but you can override it for individual tools. An agent running in autonomous mode can still require explicit approval for a specific tool — like one that sends emails or modifies production data.