In this article
Albato has done one thing for years: connect your product to other applications. More than 1,000 of them, with authorization, actions, triggers and the infrastructure that has been carrying production traffic the whole time. None of that changes in Albato 2.0.
What changes is who sits on the other end of that connection. It used to be a person clicking through a builder. Now it's also agents. An agent can run a single action, assemble an automation that then runs on its own, or hand the whole task to the Albato agent. Same connectors, same credential storage, nothing rebuilt from scratch.
Which of those matters to you depends on where your product is right now. Some partners ship a builder to their users and have no agent of their own yet. Some already run an agent inside the product and need it to do real work in their users' accounts. Some are arming their own team with agents and need one key for all of it.
There's an answer at each of those stages, two of them shipping and one opening up now, so you are not switching vendors every time your roadmap moves one step forward.
Your users build automations by describing them
If your users get an automation builder inside your product, Albato 2.0 gives them two ways to let AI do the fiddly part. Copilot turns a request in plain words into a working automation, and an AI agent runs as a step inside one, reading the incoming data and deciding what to do with it. The same release also changes how their accounts are structured and what language the builder speaks.
Copilot: an automation from a description
Copilot is a chat assistant inside the account. Your user describes the task in words, Copilot clarifies which services are involved, prompts them to create the missing connections, generates the automation and offers to check it before it runs.
It embeds in your iframe and is switched on per contract. By default it stays hidden in frames, both hardcoded ones and ones configured through iFrame settings, and we turn it on for you on request. In the white-label build there's no mention of Albato anywhere in it, only "Copilot", and it works inside your custom iframes.
Copilot is also configurable per partner: your own models and LLM providers, prompt switching, your own RAG, a white-label knowledge base so it builds automations that fit your product specifics, and appearance in your style.
An AI agent as a step inside an automation
This is a separate step that reads the incoming data and decides which action to take, instead of manual conditions and branching. It has four parts: the model (the brain), the instruction (a free-form prompt, in any language), the tools (any actions of connected apps) and memory between runs, which is off by default. Your user adds it as an action after a trigger: a webhook, a schedule, or an event in an app.
A plain example: a new request arrives, and if it is urgent the agent notifies the manager in a messenger, while if it needs a meeting the agent creates a calendar event. One step, no branching. Eight more of these, all buildable by your users, are in the AI agent use cases for SaaS rundown.
On models, the built-in Albato AI model is the default and needs no separate LLM connection. Claude, OpenAI, DeepSeek and Google Gemini run through your own connection. If you ship white label, the built-in model is hidden from your users both as an action and as an agent model, so the agent runs on your own LLM connection, and access is controlled by flags per partner.
Setup got shorter for them too. There are fewer required fields, "Agent instructions" is now optional, and "Input data" is now called "Prompt". Agent tools no longer show up in the router step picker and cannot be triggered around the agent.
With an interface or without one
You can take the ready interface in the iframe of your embedded account, or go headless through the API, build the interface yourself and let Albato run underneath. Either way, user connections, OAuth and credential storage stay on the Albato side. The Headless API describes the headless route.
Teams: a workspace and its spaces
Where Teams is open, the builder your users see is no longer built around a single account. Instead of one user there is now a structure: a workspace (the company space) splits into spaces, which can be departments or an agency's clients, and each space has its own automations, connections, builder apps and solutions, with folders inside.
Details that change how you model accounts:
- The plan belongs to the workspace, not to a user.
- A user has one role at workspace level and a separate role in each space, so the same person can be an admin in one space and read-only in another.
- An agency runs a client in a separate space, the client sees only their own work and keeps the automations when the engagement ends.
- Workspace ID and space ID are visible on the automations page.
- Seat limits come from the plan: Teams is 5 users, Free, Trial and legacy plans are 1 (the owner), and Custom is whatever the plan configuration says. Over the limit the user gets a clear error with the option to remove someone or move up a plan.
For embedded partners, Teams is switched on at contract level and works inside your iframe. If Teams is open on the contract, it's available on every plan of that contract. A white-label user can be added to a space through the API with no email confirmation, and the impersonation link in the Embedded Portal respects both workspace and space.
The interface in the language of your market
The last thing your users see in the builder is the wording, and that is now yours to set. Key and translation tables are served over the API and can be downloaded with a button in the embedded account, separately for frontend and backend. You run an automatic translation, proofread it, then maintain the keys for your own market and terminology. New translation keys land in that table automatically, so new functionality ships with translations.
Field names and hints of builder apps are now translated into all 7 Albato languages, not only the ones the app author picked. The order is author translation first, then automatic translation, then English. Polish was added to the interface language picker with English as the fallback, and that applies to the interface only, not to the website.
Between Copilot, the agent step and the translation tables, most of what your users touch in the builder is now yours to configure.
Your agent works in the systems your users connect
If you already run an agent inside your product, Albato doesn't put a second one next to it. Your agent stays the only thing your user talks to, and Albato becomes its hands in 1,000+ applications.
The MCP server
This is a cloud MCP server that gives your agent 1,000+ Albato applications to act in. For an embedded partner the point is whose accounts the agent acts in: your own end users' accounts, through those users' connections and with those users' rights. You could connect the public HubSpot MCP server without Albato at all. The difference is whose connections these are.
The agent's path through a task is short. It finds the application and action it needs, makes sure a connection exists and creates one if it does not, then runs the action. Actions across several services can go together, with no separate round trip per step. If your team is still mapping out how MCP and iPaaS split the work, the protocol handles the conversation with the agent while the platform keeps the connections, the auth and the execution.
Native MCP servers of the apps themselves
Ready MCP servers of applications are now wired into Albato, and your agent sees their tools as ordinary actions. This is live for HubSpot, Slack, Notion and Stripe.
The reason is coverage and speed. Those vendors have tools that are not in the Universal API, such as CRM analytics, campaigns and landing pages, and a native MCP can be faster. Your agent sees no difference: the request goes to the vendor MCP and service fields are filled in automatically.
A2A: hand the whole automation to the Albato agent
When your user needs a process rather than a single step, your agent passes the task to Albato Copilot over the Agent2Agent protocol. Copilot assembles the automation, and from then on it runs like any other automation: predictably, without an LLM call on every run and without tokens spent per run.
Take a request like "put every new lead into HubSpot and then run two more steps". Your user says it to your agent, your agent says it to the Albato agent, and the automation is ready in minutes.
One key for the agents your team runs
This part of Albato 2.0 is about your own company rather than your users. You connect your systems to Albato once, and your employees and their agents work with those systems through one address and a personal key. This is MCP Hub. It is the one part of Albato 2.0 that is not in production yet, and early access is open.
One MCP instead of dozens of servers
There's no setting up MCP, OAuth and access per application and per agent. One connection to Albato gives your agents 1,000+ applications plus the native MCP servers of HubSpot, Slack, Notion and Stripe. The chain is short: an employee and their agent, one connection, company systems, 1,000+ applications. It works in Claude Code, Claude Desktop, Cursor and any MCP-compatible environment. This matters most when AI agents get access to production systems, since the real system tokens stay with Albato instead of landing in configs, prompts or with the LLM provider.
One account, the whole team
One HubSpot account, four sales reps, an agent each. Each rep gets their own key into that one connection, so HubSpot still sees a single account. When someone leaves, their key stops working and the connection keeps running for everyone else. The same pattern works when your own team manages accounts for someone else: one connection to the ad account, limited keys for the account managers.
One connection instead of dozens of servers, and one place to switch someone off when they leave. If that is worth having before it is in production for everyone, your Albato manager can put you in early access.
A new interface for everyone in November
In November the Albato interface is updated for every client: platform, embedded and white label. The update arrives in your iframe together with the platform, with no separate release and no change of addresses. Staying on the old interface isn't an option.
Before the rollout we check every interface change against your project, your screens, your copy and your iFrame settings. There's no integration work on your side. The one thing worth planning is a screenshot refresh in your help center, and we can take those in your environment for you.
Here's what your users will notice.
Automation by link
An automation link can be handed to another person: a new user registers through it and gets the structure right away, an existing user copies it into their account. The author shares it from the "Share" item in the automation card menu.
- The share window holds the name and ID, the link, "Copy" and "Refresh link", and a short markdown description. Refreshing kills the old link, which is what you want when it reached the wrong person.
- If the automation uses private apps, a warning says the recipient needs access to them too.
- A signed-in recipient sees an import screen, a new one registers first, and the automation editor opens once the import is done.
- The structure copies without connections and custom fields, and the copy does not sync with the original.
Drafts instead of empty automations
"Create automation" no longer drops an empty automation into My automations. It stays a draft until at least one step is added, in both linear and pro mode.
A new step picker
The windows for adding actions and tools were rebuilt on the new design, and every step of every automation goes through them.
Automations as a list
My automations now has two modes, cards and a compact list.
The "changed to" filter
Your user controls the automation memory: data passes exactly once, at the moment a field takes the required value. A deal passes once when the status becomes "in progress" and stays quiet after that, even if the status changes again. This covers "entity status changed" scenarios where the source system does not emit such an event.
Global webhooks without a pointless window
Some apps use a global hook, one address for all of Albato. The interface no longer shows a hook settings window that doesn't exist for them.
Stickers on the canvas
Notes sit right on the automation diagram and can be created, edited, deleted and dragged. Pro mode only.
The line to the "Webhook response" step
It's back on the canvas, drawn as a dashed line.
Smaller changes worth knowing
Two changes that won't make your release notes but save your users a click:
- Connection lists refresh themselves. Opening a field window pulls the lists automatically, with no click on "Update". The spreadsheet and sheet pickers of Google Sheets are the clearest case, and the mechanism is shared with lists in other apps' connections.
- Static custom fields inside line sections. A set of static custom fields, where the user types the keys by hand because the field set is not known in advance, now works inside line sections too. Until now it was only available at action or connection level.
Whichever of the three stages your product is at today, the next one already has an answer waiting, and moving between them is a conversation with your Albato manager. If you want to see any of this against your own setup, that's the place to start.
