Thinking about replacing your current RPA platform? We'll migrate your existing automations to Robomotion for free. Let's talk: [email protected]

Robomotion Agent Teams is more than a place where AI agents collaborate. Its their workspace. Hire ready-to-use AI agents from the Robomotion Store, clone and customize existing ones, or build your own from scratch. Your agents. Your teams. Your workspace.

Let's talk.

We have been working on Robomotion 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 for a while, and this course finally shows the whole picture Not just OCR From raw documents to structured data, validation, human review, automation, measurement, and even training your own models

Robomotion Apps combine a UI frontend with automation flows running on your Application Robots in the backend. You build them simply by describing what you want. Easy to build, easy to deploy, and they run locally. Every app comes with built-in MCP support and an Assistant. You can connect them to Claude Code, Codex, or Copilot via MCP and let your agents use them directly. Or you can use the app through its UI. Either way, everything stays in one shared place, so you can follow your clients, manage your pipeline, and keep the whole process in sync.

The direction Robomotion is taking is getting really exciting. And there is so much more coming soon. I think we are going to slow down on videos explaining the platform itself. Instead, we will start showing the outcomes. The apps. The agents. The work they actually do. Because the platform itself is becoming almost invisible. You describe what you want, and AI builds it. With one prompt, you can now create an application and the automation behind it. Ask Robomotion to create a CRM. Now you have a real CRM application inside the platform. But it is not just a UI. It immediately has automation behind it, its own Assistant, and an MCP interface that lets you connect it to Claude Code or other AI agents. And then it gets even more interesting. You can create AI agents inside Robomotion too. So now you have two completely separate things: An application with its own flows. And an AI agent with its own flows, tools, memory, and instructions. Then you give the application to the agent. Think about that for a second. You created your own CRM with one prompt. Humans can use it. But your digital workers, your agents, can use it too. Now give that agent another tool: a LinkedIn automation built with RPA. Then tell it: Work through my sales pipeline slowly. Research each lead. Reach out when appropriate. Move the cards. Update the timeline. Keep the CRM clean. And send me a summary of what you accomplished today. The agent can operate the tools and applications you created for it. And with Agent Teams, humans and agents can work together in the same Slack-like environment. Agent Teams is still in Early Preview and moving toward Beta, but this is where things start getting really interesting. You are no longer just automating tasks. You are creating applications, creating digital workers, and giving those workers software to use. We have a lot to build. And a lot to show. Follow @robomotionio

Robomotion Designer can build the app for you without Claude Code or Codex. This opens a new direction for Robomotion: apps as the interface to automation. Soon, we’ll start adding more apps to the Robomotion Agent Hub. Every app we build can be connected to an AI agent through MCP, and every app comes with its own Assistant. Building with AI is becoming incredibly powerful. We can now point it to a screenshot or a video demo we liked on social media and turn that idea into a working app we can actually use on the Robomotion platform. And there is no shortage of ideas. Especially after the recent Jev release, new automation examples are showing up everywhere. We’ll start building some of them, adding them to the Agent Hub, and sharing them here soon. Follow @robomotionio

Jev is not a traditional LLM. It is a new model architecture from TypeSafe, built for fast, structured decisions rather than generating text token by token. We have wanted to add a Browser → Act node to Robomotion for a long time. The problem was never just getting AI to understand what to do. It was making a decision at every step fast enough that the automation still feels like automation. When we saw Jev, we thought: this is it. TypeSafe even demonstrated Jev playing Doom by continuously deciding what to do next from structured game state. That gives you an idea of how quickly these decisions can happen. Our Browser → Act node uses the same idea for browser automation. Traditional Computer Use systems are generally screenshot-based: capture the screen, send it to a model, get back where to click or type, then repeat. With Browser Act, Jev works inside the page. It looks at the page state and decides what the robot should do next: where to click, what to type, which option to choose. Then it does it again. And again. It is fast enough that it feels like the automation is simply running locally, even though AI is continuously deciding the next action. The economics are just as interesting. Jev currently costs $0.042 per million input tokens on OpenRouter, with $0 output-token cost. That changes where AI can be used. Instead of calling an expensive generative model only for a few important steps, you can start using intelligence throughout the automation. AI picks. Robot acts. Code verifies. This is exactly the kind of model I think AI automation has been waiting for.

🚨 Teaser Alert: 𝐑𝐨𝐛𝐨𝐦𝐨𝐭𝐢𝐨𝐧 𝐀𝐩𝐩𝐬 is coming! The Invoice Inbox app you see in the video is _not_ a built-in Robomotion product. It’s what we built with Robomotion using just 𝐨𝐧𝐞 𝐩𝐫𝐨𝐦𝐩𝐭. Now you can create frontends for your flows, deploy them directly to the Agents dashboard, and launch them just like Chat Assistants. The best part: every UI comes with an AI Assistant, so you’re building an agentic app from the start. And every app comes with its own MCP, so you can connect it to Copilot, Claude Code, or Codex and interact with your agent outside the platform. Whenever you need to, just open the UI and see what your agent is doing for yourself. The backend is a regular Robomotion flow. #Agents #MCP #Robomotion #AgenticAutomation #Apps

Most of the "AI agents" we see today are just workflows with a thin layer of AI on top. Gartner has a name for this: 𝐚𝐠𝐞𝐧𝐭 𝐰𝐚𝐬𝐡𝐢𝐧𝐠. A document arrives. An LLM extracts the fields, understands the email, or classifies the request. Then a predefined workflow takes over: Validate the data. Update the ERP. Send an email. Ask for approval. Continue to the next step. And there is nothing wrong with that. In enterprise automation, deterministic execution is probably what you want most of the time. The irony is that today, if you call it automation or RPA, it sounds legacy. Call essentially the same system an "AI agent", and suddenly it sounds cutting edge. But that does not make it agentic. The simplest test is: 𝐖𝐡𝐨 𝐝𝐞𝐜𝐢𝐝𝐞𝐝 𝐭𝐡𝐞 𝐨𝐫𝐝𝐞𝐫 𝐨𝐟 𝐭𝐡𝐞 𝐬𝐭𝐞𝐩𝐬? If a developer already defined: Step 1 → Step 2 → Step 3 → Step 4 then you have AI inside an automation, but very little agency. A real agent works differently. You give it a goal. It evaluates the situation, decides what to do next, chooses among available tools, acts, observes the result, and adjusts its plan when necessary. The execution path is not fully predefined. It emerges at runtime. This is also why I do not think RPA is disappearing. Agents still need ways to act on real business systems. If there is an API or MCP tool, great. But many enterprise applications still have no usable API, no MCP server, or expose only part of what the agent needs. That is where RPA becomes a tool in the agent's execution layer. Deterministic workflows handle reliable execution. The agent decides 𝐰𝐡𝐚𝐭 𝐭𝐨 𝐜𝐚𝐥𝐥, 𝐰𝐡𝐞𝐧 𝐭𝐨 𝐜𝐚𝐥𝐥 𝐢𝐭, 𝐚𝐧𝐝 𝐰𝐡𝐚𝐭 𝐭𝐨 𝐝𝐨 𝐧𝐞𝐱𝐭 𝐛𝐚𝐬𝐞𝐝 𝐨𝐧 𝐭𝐡𝐞 𝐫𝐞𝐬𝐮𝐥𝐭. AI for reasoning. Deterministic automation for execution. Orchestration connecting the two. At Robomotion, this is exactly how we think about AI agents and RPA. Our next challenge is making that automation layer dramatically easier to build. Describe what you want in a prompt, and get a working visual automation back. It stays visual, so you can follow exactly what it does. And when AI creates or updates it, you can inspect the visual diff to see exactly what changed. #AIAgents #Automation #AgenticRPA

Kids have always had endless imagination. What changed is that AI is starting to remove the barriers between imagination and creation. Until recently, a child who wanted to build a computer game had to learn programming, understand complicated tools, and maybe even overcome English as a second language before they could turn an idea into something interactive. Now, a kid who spends hours playing Roblox can also start building games, characters, worlds, and experiences using AI Agents. That changes something important. They can start creating much earlier, while their imagination is still largely unconstrained. I'm very curious to see what these early adopters will grow up being able to do. What will become second nature to them after spending their childhood not only consuming digital worlds, but creating them? #AI #ArtificialIntelligence #AIAgents #FutureOfLearning #Creativity #Roblox

RAG gets better when the agent decides what to search for. Usually, RAG works like this: take your company documents, put them in a vector database, retrieve the relevant pieces, and give them to the model. But in this example, retrieval is not fixed. The DeepSeek Harness gets a search tool built with Robomotion flow nodes, then decides for itself how many searches it needs. The same question resulted in 5 searches, then 7, then 9 across different runs. It searches for one idea at a time, combines facts across multiple documents, and cites the source file in every answer. The infrastructure is also surprisingly simple: LanceDB is embedded, so the database is just a directory. No server, no container, no connection string. Our 11 PDFs became 82 chunks. At that size, we deliberately skip the vector index and let LanceDB scan the embeddings directly. So the interesting part here is that the agent is not just retrieving context. It is deciding how to retrieve it.

RPA has always had a switching-cost problem. Once you have dozens or hundreds of automations running on one platform, moving somewhere else means rebuilding and retesting everything. AI changes that equation. Coding agents can now understand existing automations, rebuild them on another platform, and dramatically reduce the cost of migration. Migration is becoming less of a barrier. That’s why we can offer free migrations at Robomotion. Start with one process, run both side by side, and decide for yourself.

Robomotion RPA and DeepSeek Harness, with AI Agents in action. This is how we combine AI Agents and RPA. Anything that needs to stay deterministic, SAP, Salesforce, Dynamics, or even a web portal without an API, can be exposed to the AI Agent as an RPA tool. You define the tool and its input parameters. The AI Agent is forced to pass those parameters as defined, and RPA uses them as regular deterministic inputs. The agent decides what to do. RPA executes it exactly as designed.

Turning an empty folder into a learning agent with Claude Code is possible. Claude Code has two memory systems: CLAUDE.md contains the instructions you write. Auto memory contains notes Claude selectively writes for itself based on your corrections, preferences, ongoing work, and things it decides are worth remembering. Auto memory lives under: ~/.claude/projects/-your-project-folder/memory/ MEMORY.md acts as an index to separate markdown files per each thing to remember. Because the memory is just Markdown files, you can also copy accumulated memory into another project. It becomes a simple form of knowledge transfer between agents. This creates an interesting pattern. Create a separate project folder for each role, such as marketer/, video-editor/, or graphic-designer/, then start Claude inside that folder. And it doesn't have to be a coding project. Over time, Claude running in these folders starts behaving more like a specialized agent that learns by doing. Then add skills. Skills are reusable procedures. A skill can also contain code: .claude/skills/video-crop/ SKILL.md scripts/crop.py This is where things get powerful. When Claude solves something with a script, such as scraping, fetching, cropping, blurring, an ffmpeg pipeline, or a Remotion render, you can ask it to save the solution as a skill into this project folder. SKILL.md explains when and how to use it. Instead of rediscovering remotion usage, ffmpeg flags every time, your agent now has an ability it can reuse. Next time, it already knows how to do it. For harder problems, I also like keeping an append-only ISSUES.md file. When a problem consumes multiple context windows, have Claude record what the problem was, what it tried, what failed, why it failed, and what finally worked. This is especially useful because auto memory is selective and may skip debugging details that Claude can derive from the codebase or does not consider worth preserving. So the pattern becomes: CLAUDE.md for standing instructions. Auto memory for what Claude learns on its own. Skills for reusable procedures and the scripts that implement them. ISSUES.md for hard-won debugging knowledge. The result is an agent that gets better over time by accumulating memory, reusable abilities, and hard-won experience.

The Year of Linux on the Desktop will finally come true. 🚀 The Omacom Foundation has launched with $8 million in funding from eight Founding Patrons, each contributing $1 million to the mission: Tobi Lütke, CEO of Shopify Patrick Collison, CEO of Stripe Michael Dell, Chairman and CEO of Dell Technologies Jack Dorsey, Block Head and Chairman of Block Matthew Prince, CEO of Cloudflare Brendan Iribe, Co-founder of Sesame and Oculus Jason Fried, CEO of 37signals David Heinemeier Hansson, CTO of 37signals omarchy.org/news/2026/08/oma…

𝐃𝐞𝐞𝐩𝐒𝐞𝐞𝐤 𝐇𝐚𝐫𝐧𝐞𝐬𝐬 dynamic skill learning example added to our 𝐠𝐨-𝐝𝐞𝐞𝐩𝐬𝐞𝐞𝐤 library. We created go-deepseek, an open-source Go SDK for using and embedding DeepSeek Harness in your Go applications. We are now integrating this library into 𝐑𝐨𝐛𝐨𝐦𝐨𝐭𝐢𝐨𝐧 𝐑𝐏𝐀, where we want to give RPA robots the ability to explore a task, learn how to complete it, save that knowledge as a skill, and reuse it on future runs. Our new 13th example demonstrates exactly this: github.com/robomotionio/go-d… We created a fake telephone banking service with a deliberately complicated menu, similar to the phone menus we all know. The task is simple: "Find my credit card balance." But the route is not. Several menu options sound correct. Some lead to dead ends. One even gives a rewards points balance instead of the actual credit card balance. Run 1️⃣: the agent starts with no knowledge of the menu. It calls the bank, listens to the prompts, explores different branches, makes wrong choices, goes back, redials, and eventually finds the correct route. 17 wrong turns. More than 6 minutes of airtime. Once it succeeds, it saves what it learned as a reusable skill. It even records details such as: "Do NOT press 2. The balance is NOT under card services." Run 2️⃣: a completely fresh session starts with only the learned skill. This time, there is no exploration. One call. One key sequence. 44 seconds of airtime. Done. We also change the credit card balance between the two runs on purpose. This makes sure the agent cannot simply memorize the answer. It has to use the learned route, call the service again, and retrieve the new balance. The agent did not learn the answer. It learned how to get the answer. And every claim is verified against the phone system's own call logs, not just what the agent says it did. There is also a visual demo with a touch-tone keypad and real DTMF tones, so you can watch the agent navigate the phone system live. This is what we are now bringing into Robomotion RPA: Explore once. Learn the skill. Reuse it on future runs. #RPA #AIAgents #Golang #DeepSeek #Automation #OpenSource

We are very close to building 𝐬𝐞𝐥𝐟-𝐥𝐞𝐚𝐫𝐧𝐢𝐧𝐠 𝐑𝐏𝐀 𝐫𝐨𝐛𝐨𝐭𝐬. Imagine an 𝐑𝐏𝐀 𝐫𝐨𝐛𝐨𝐭 running in production. It notices that something has changed in the automation, figures out what changed, and updates its own flow for the next run. This is not self-healing selectors, it is self-fixing automations! This is now very possible, and surprisingly easy to build if your product can be used with agent skills. Now take it one step further: imagine hiring an RPA Developer Agent from the Robomotion Agent Hub. You send it a video of the process you want to automate. It watches the video, learns the process, creates the PDD, got approval from you or the client, and then builds the automation, tests it and emails you a video of the working automation. How? DeepSeek recently open-sourced its DeepSeek Harness: deepseek.com/harness/en/ It comes with a Python SDK. Today it supports only Linux and Apple Silicon Macs. Under the hood, the SDK bundles a prebuilt, platform-specific Node.js executable inside the Python wheel, spawns it as a subprocess, and communicates with it over JSON-RPC. 😮‍💨 In other words, the Python package is mostly the driver. The actual harness runs inside the bundled Node.js binary. We didn't like the SDK architecture. Also, our RPA robots run on Windows, macOS, and Linux. And not just on paper. Linux and macOS are first-class citizens at Robomotion. So we built go-deepseek: github.com/robomotionio/go-d… A Go SDK for DeepSeek Harness that works across platforms. It uses Robomotion's goant, our own JavaScript engine: github.com/robomotionio/goan… What makes DeepSeek Harness especially interesting is its architecture. Everything is a plugin, and skills can be created and injected dynamically. No hardcoded skills. No agent restarts when a new skill is added. You can explain a task with screenshots, or simply share a video showing how it should be done. Isn't that basically how we teach new employees? You teach it something, it writes and keeps that skill, and the next time you ask, it can use what it learned. Check out our 12th example, advanced-learning, in the go-deepseek SDK. We are now currently working on our DeepSeek Agent package for Robomotion, which will bring these learning capabilities directly into Robomotion RPA robots. We already support Google ADK and Hermes Agent, but the DeepSeek Harness architecture opens up something much more powerful. Follow @robomotionio for more.

Introducing 𝐠𝐨-𝐝𝐞𝐞𝐩𝐬𝐞𝐞𝐤, a pure-Go SDK for the DeepSeek Harness. DeepSeek recently open-sourced the 𝐃𝐞𝐞𝐩𝐒𝐞𝐞𝐤 𝐇𝐚𝐫𝐧𝐞𝐬𝐬, a real coding agent harness with one architectural idea that immediately caught our attention: 𝐄𝐯𝐞𝐫𝐲𝐭𝐡𝐢𝐧𝐠 𝐢𝐬 𝐚 𝐩𝐥𝐮𝐠𝐢𝐧. The model adapter. The session log. The filesystem the agent can access. Every tool it can call. A deployment is simply a list of plugins. There is no second configuration surface. That is a very interesting architecture for embedding agents. Then we looked at the official Python SDK. And this is where things got interesting. Do you know what the Python SDK does? 𝐈𝐭 𝐫𝐮𝐧𝐬 𝐍𝐨𝐝𝐞.𝐣𝐬. More precisely, the Python SDK is a subprocess driver. It spawns a prebuilt single-file Node.js executable and drives the TypeScript harness over JSON-RPC. So your Python program starts Node.js to run the agent. The runtime is shipped inside platform-specific Python wheels. 196 MB unpacked. Three platforms: Linux amd64. Linux arm64. Apple Silicon macOS. No Windows. No macOS on Intel. For many applications, that is perfectly fine. But if your application is written in Go, the shape is a little strange: Go → subprocess → Node.js → agent We wanted: Go → agent So we took a different route. We compiled the DeepSeek Harness itself, all 64 modules and 12.5 MB of it, directly into the Go binary. Then we ran it on 𝐠𝐨𝐚𝐧𝐭, our pure-Go JavaScript engine. No Node.js runtime. No subprocess. No cgo. No second executable to ship. Just the Go binary. Today, 𝐠𝐨-𝐝𝐞𝐞𝐩𝐬𝐞𝐞𝐤: • is pure Go: no cgo, no Node.js, nothing to install beside your binary • cold-boots the agent in 0.37 seconds with 58 MB of Go heap • runs on Linux, macOS and Windows, on amd64 and arm64 • lets you mount Go tools, policies and components alongside the harness's own • gives the agent a filesystem fence you control • ships with twelve runnable examples • is MIT licensed 𝐠𝐨-𝐝𝐞𝐞𝐩𝐬𝐞𝐞𝐤 is not trying to replace the official SDKs. If the Python SDK and its Node.js subprocess fit your architecture, use them. It is built for a different problem: Putting the DeepSeek Harness 𝐢𝐧𝐬𝐢𝐝𝐞 a Go program while keeping the binary-in, binary-out simplicity Go gives you everywhere else. github.com/robomotionio/go-d… If you are embedding agents in Go, we'd love to hear what you think. #DeepSeek #Harness #Agents #Go