A library of ready-to-use AI agents. Create a new agent in three steps. In the cloud, with fine-grained access control.
Until a connection is bound to an agent, its tools don't exist for that agent. Bindings are visible from both sides: on the agent and on the connection.
Allow or deny a specific tool, constrain its parameters, close a connection entirely. The rule fires before the external service is ever contacted, and the denial goes to the log.
Who called what, when, with what result. Errors and policy denials are collected separately, so you know where to look.
A language model does one thing — write text. Everything that turns text into work sits around it. One harness for the whole system; the settings belong to each agent.
The concrete calls that connections bring in: MCP servers, your own API behind a key, connectors to Telegram, your phone and your computer. A tool appears for an agent together with the binding.
In plain words: What the agent can do at all: send a message, file a task, read a spreadsheet.
A skill is written know-how for using tools: the order of steps, the rules, and the connectors it needs. It is versioned, reused across agents, and picked from a shared catalogue.
In plain words: Tools are what an agent can do. A skill is how well it handles them: which one to reach for, in what order, when to stop and ask.
A connection's credentials are held on the platform side. The agent gets tool descriptions and calls them by name, and the connector key is supplied outside the model. The LLM provider key is a different matter: it is what reaches the model at all, and it goes to the platform worker.
In plain words: The agent does not know the passwords to your services. It says "send the email", and the harness supplies the connector key, outside the model.
Allow or deny an individual tool and its parameters, up to closing a connection entirely.
In plain words: "Reading is fine, deleting isn't." Checked before the agent touches the service.
The run, its steps, every call with parameters and result, token spend per model.
In plain words: You can see what the agent actually did and why: a line with the call parameters and the service's answer.
The agent is executed on the platform side: in the project cloud, or on your own server when self-hosted. Devices attach as companion connectors and never become the place the agent runs.
In plain words: So every call has a point where it can still be checked: the platform itself. An agent running on your own machine talks to the system directly, with no such checkpoint on the way.
How it works
A trigger arrives from a connector or a device. The platform checks it against the agent's rules and hands it to one agent. Having done its work, the agent calls a tool back through the core — and that call goes through the same check. Credentials are attached inside the core and never reach the agent, and every trigger and every call lands in its own log: allowed and denied alike.
Flow diagram. On the left are the sources: tools and triggers, grouped into connectors and devices. A trigger travels from a connector or a device into the AgiMate core. There it is checked by the Policy block: is it allowed for this agent or not. A denied trigger goes no further and lands in the trigger log. An allowed one passes to Trigger routing, which hands it to one specific agent. Having worked on the trigger, the agent reaches back into the core and calls a tool on a connector or a device. That call is checked by the same rules and lands in the tool call log. Connector credentials stay in the core and are never passed to the agent. The agent's answer returns through the core, surfaces in the User Channel block, and leaves for the messenger the conversation is in: webchat, Telegram, the phone app or an IDE. On the diagram each connector and device carries its own name (Mail, Laptop, Calendar, Android), each agent carries the name it was given, and each packet in flight carries a Greek letter. The trigger log lists the time, the connector or device, the trigger name, the Greek name of the packet that carried it, and the verdict. The tool call log lists the time, the agent that asked, the connector or device it went to, the tool, and the verdict.
An instruction is a request, and a request can be argued with. A connection binding is a boundary: the agent does not get past it, however it is persuaded. Each agent has its own.
The provider and the priority list of models are set on the agent, separately for chat, vision and image generation.
In plain words: An expensive model where thinking is needed, a cheap one where it's shuffling data. You pay per job, not one flat rate for everything.
Each agent carries its own instruction text — from a ready-made role or from scratch.
In plain words: Each has its own manner and its own ground rules. One answers a customer briefly and politely, another works through the numbers in detail.
Connections are bound to a specific agent, and inside a binding there are rules for individual tools and their parameters.
In plain words: Like clearances for staff. One has access to email, another to the spreadsheets, and nobody has access to everything.
The skill set is assembled on the agent; another agent's tools never show up in it.
In plain words: An agent can do exactly what its role needs. Less lying around means less chance of reaching for the wrong tool.
| Agent | Model | Instructions | Access | Skills |
|---|---|---|---|---|
| Analyst | strong | “go deep, show your working” | data and reports — read only | summaries, charts |
| Assistant | cheap, fast | “remember what matters, remind me early” | calendar over MCP, push to the phone | fact notes, reminders |
| Designer | vision and image generation | “show three options, then refine one” | files: read and write | image editing, generation |
| Language tutor | mid-range | “correct gently, praise a streak” | Telegram, a vocabulary file | vocabulary, error review, motivation |
| Home accountant | mid-range, careful with numbers | “count from receipts, ask when they don't add up” | the expenses sheet in files | expense tracking, monthly summary |
Five agents, five token bills and five separate sets of access. What they share is the harness: one set of rules and one log.
A ready-made role brings its own instructions and skills. Everything it prefills stays editable — before creation and at any point after.
A gallery of ready-made roles: the description, instructions and matching skills are already written. Or start from scratch if the job is your own.
The role's skills are already ticked. Drop the ones you don't need, add your own — or just move on and come back to it later.
The agent exists and answers in the dashboard chat. Everything else gets connected when you need it, not before the first message.
Scenarios made of parts that already exist in the dashboard — each one shows what it's assembled from
Set up a channel: the Telegram connector, an incoming-message trigger, a reply tool. The agent answers per your instructions and the conversation is stored as sessions you can read in the dashboard.
A connector job runs on a schedule: the agent visits an external service, checks what matters and writes to you. Jobs can be paused or run right now.
An external system sends a webhook — the agent parses the event and takes the next step. Every delivery and every tool call stays in the trigger logs.
The Android and desktop apps are connectors to your own hardware. Notifications, calls and device events become triggers, and the agent answers with a push, spoken text or a command carried out on the device.
Over the ACP protocol the agent plugs into your editor and works next to the code — with the same skills, access rules and log as everywhere else.
Connect your API as a key-authenticated app or an MCP server — its methods become the agent's tools. What exactly it may do is up to your rules.
Assemble a team of agents and give it a shared board: tasks with statuses, an assigned agent, comments in the thread. Changes reach the dashboard in real time.
Tokens are billed by your provider at your rate
Connect a provider with your own key and pay it directly. The model list is pulled from the provider, and unavailable ones are flagged.
Chat, vision, image generation — each job gets its own priority list of models. If the first doesn't fit, the next one is used.
How many tokens went out, from which agent, on which model. No key of your own yet — start on the platform free tier.
Talk to your agents wherever suits you
MCP servers and your own API behind a key connect today. The catalog of ready-made integrations keeps growing.
The phone and desktop apps: the agent sees what happens on your hardware and acts on it.
An agent on your phone: intercepts notifications, calls, and events — and passes them to your AI agents for processing
Learn moreAn agent on your computer: monitors files, events, and desktop notifications, executes commands from AI
Learn moreThe source is open in full: the core, the dashboard, the chat app, the connectors and the n8n nodes. Running it yourself is free, company use included; a licence is only needed to sell AgiMate as a service to others. Your data, model keys and logs stay with you.
Sign in with GitHub, Google or Yandex — the account is created on the first login.
Self-hosted · Your own model key · Every call logged