Not an assistant — a system of agents. The harness around any language model gives them tools, keys to your systems, rules and a log. As many agents as you need, each one its own: its own model, its own instructions, its own access, its own skills — and none of them ever sees a key.
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. The toolbox.
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. Without it the agent holds the hammer without knowing what for.
A connection's credentials stay on the platform side. The agent only ever gets tool descriptions and calls them by name — no key, no token, no password reaches the model.
In plain words: The agent doesn't know your passwords. It never sees them: it says "send the email", and the harness supplies the 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, not after.
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. Not "it seems to have broken something", but a line with the parameters and the answer.
An agentic team over a shared task board, updating live in the dashboard.
In plain words: One agent isn't enough for the job — put a second one beside it. You can see who took what and where it stands.
An agent can be talked into things — it is a language model, after all. But it cannot hand over a key: it doesn't have one. The most it can do is try to call a tool, and that runs into the rules and stays in the log.
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. 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, WhatsApp or Slack. 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.
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.
One agent holding every key and every tool is exactly the all-or-nothing problem. A system of narrow agents is safer, more accurate and cheaper.
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 holds the keys to email, another to the spreadsheets, and nobody holds keys 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 keys. What they share is the harness: one set of rules, one log, one board.
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, and there is nowhere else to get them. 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.
One agent is not the ceiling: assemble a team 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 — no markup from us
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 already cover almost anything. The catalog of ready-made integrations keeps growing.
The phone and desktop apps are connectors you can't get anywhere else: 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 platform can be deployed on your own server: data, model keys and logs stay with you. Repositories and deployment instructions are on GitHub; server-side components are opened up as they pass security review.
Sign in with GitHub, Google or Yandex — the account is created on the first login.
Self-hosted · Your own model key · Every call logged