--- title: "Autonomy Where It Pays Off. Control Where It Counts." description: "Long-running autonomous agents bring new risk. Learn when open-ended autonomy pays off, and why most business processes need a governed specialist instead." url: "https://www.datarobot.com/blog/long-running-agent-autonomy/" authors: - "Carson Gee, Senior Principal Engineer for AI Applications and Experience" - "Amit Purohit, SVP of Engineering" - "Andrii Kislitsyn, Staff Software Engineer" - "Oleksandr Yakovchenko, Senior Software Engineer" published: "2026-10-22" updated: "2026-10-22" category: "AI for Practitioners" language: "en-US" --- # Autonomy Where It Pays Off. Control Where It Counts. *Our position on long-running, autonomous agents, and why most business processes need a specialist instead.* Picture the person who has to sign off on your first autonomous agent. It might be your head of audit, your CISO, or the risk lead for the business unit that wants it. They ask one question: when this agent does something, who authorized it? If nobody can answer that cleanly, the agent stays in pilot. That chair is where a lot of agentic AI gets stuck. In DataRobot’s [Unmet AI Needs Survey 2026](https://www.datarobot.com/resources/unmet-ai-needs-survey-2026/) of 413 agentic AI stakeholders, the question of whether existing access controls and catalogs are adequate to govern agents came out a coin flip: 49% said yes, 51% said no. Governance also topped the list of challenges companies expect when scaling from one agent to 100 or more, cited by 61%. And launch isn’t the finish line, since 94% of organizations hit Day 2 operational issues after deploying agentic AI. The workaround most teams reach for is a human clicking approve on every meaningful action. That doesn’t automate anything. It adds a new interface to the same bottleneck. And the problem just got bigger, because a new class of agent has gone mainstream. These agents don’t wait to be invoked. They keep memory across restarts, run a loop between your messages, and act on their own initiative. Open-source projects like [Hermes Agent](https://github.com/NousResearch/hermes-agent) popularized the pattern, and the big labs have followed: xAI shipped [Grok Bot](https://www.reworked.co/collaboration-productivity/xai-launches-grok-bot-ai-agents-in-beta/) in August, Meta shipped [Muse](https://explainx.ai/blog/meta-muse-personal-agent-launch-sentinel-vm-security-2026) in September, and OpenAI launched [Dots](https://www.nbcnews.com/tech/tech-news/openai-launches-dots-ai-agents-safety-questions-rcna600338) on September 29, and Anthropic launched [Claude Duet](https://claude.com/resources/articles/claude-duet) on October 21. That’s useful, and it’s a very different risk surface from a bounded pipeline that runs, answers, and exits. Our view is that the right level of autonomy depends on the problem, and you shouldn’t need a different platform for each answer. Here’s how we think about it. ## Long-running and autonomous are two different properties People tend to lump them together, but they’re worth separating. A long-running agent never turns off and keeps state across sessions, so it gets better at your environment over time instead of starting cold on every run. An autonomous agent can decide to act without a human approving that specific action: pick up a task, call a tool, spend tokens, write to a system of record, or message someone. A dedicated agent flow, like a RAG pipeline or a ticket classifier, is usually neither. It’s invoked, runs a mostly fixed set of steps, returns an answer, and remembers only what was in the prompt. Hermes-style agents are both. You’d want both when the problem is a standing responsibility instead of a single request. Take month-end close: pull the reconciliations, flag exceptions, chase owners, and escalate only what needs a person. You could stitch that together with scheduled jobs calling narrow pipelines, but you’d be hand-building the scheduling, the state, and the judgment about what’s worth escalating. A long-running agent handles that natively, and its context compounds as it learns your systems and conventions. The trade is explicit. You give up a small, auditable surface area for a bigger one that can do more without you. That’s worth it for judgment-heavy, long-horizon work. It usually isn’t worth it for a well-defined, high-volume, cost-sensitive task that a guarded flow already handles at a fraction of the token spend. ## The generalists have arrived Grok Bot, Muse, and Dots make the same bet from three different labs: give every user an agent that keeps working on their behalf, with broad access and a standing goal. Grok Bot and Muse each give the agent its own cloud machine, and Dots connects to more than 4,000 apps and is pitched as able to do nearly anything. That breadth is the point. These are generalists, the office administrators of the agent world, and they’re impressive precisely because they aren’t specialized for anything. That’s a fine trade for a person delegating their own errands. It’s a shakier one for a business process. A generalist reaches for a frontier model because it can’t know in advance which step is hard, so work a small model could do reliably runs on the most expensive one, on a loop. Breadth of access is also breadth of blast radius, and the vendors say so themselves: Grok Bot itself calls its shared machine, logins, and files “a real blast radius.” Consumer-first products also come with consumer-first defaults on data use and regional availability, which is a different bar from what your regulator expects. And their guardrails lean heavily on per-user approvals, while an enterprise needs policy that applies to every agent and every action whether or not someone remembered to click deny. The alternative is a specialist. Compare a general-purpose coffee machine with a barista trained for one job: the same drink, made the same way, quickly, at a known cost, every time. A specialist agent knows its process, uses only the tools that process needs, and runs each step on the model that step actually needs. ## What autonomy asks of your security team An agent that acts on its own, remembers things, and keeps running between check-ins needs controls a stateless pipeline never did. It holds long-lived credentials because it has to act later, unattended, which makes those credentials a permanent target. Prompt injection turns into privilege escalation: a pipeline that reads a poisoned document produces a bad answer, but a long-running agent that reads one can open a PR, leak a secret, or message a customer. Memory becomes a durable attack surface, since one false fact written into it shapes every future session. And because behavior drifts as memory and skills evolve, a one-time code review isn’t enough; tracing has to be always on. Then there’s identity, which nobody has solved cleanly yet. A human teammate logs in as themselves, and their access leaves when they do. A team agent is provisioned once and used by many, so when something goes wrong, “who authorized this?” has no clean answer. Its permissions tend to ratchet up and never come back down. It can spawn sub-agents or act on automated triggers, producing actions with no human originator at all. And it often ends up on one shared service identity, which erases per-user attribution right when an incident review needs it. The right posture looks like how you’d treat a highly privileged contractor: a named identity where possible, scoped and reviewed grants, short-lived tokens, and an audit trail that separates “the agent did this” from “the agent did this because a specific person asked.” Autonomy is worth having, and governance is what makes it safe to adopt. That’s why it has to come first. ## Where we land We see two ends to this, and we’re building for both. For the problems that are truly open-ended, where a self-learning agent with long-running memory earns its keep, run that agent inside your own governed perimeter: your data, your infrastructure, tracing from day one. Our Labs team is already showing how that works (more on that below). Save it for work where true autonomy is worth the spend. For everything else, and that’s most critical business problems, you don’t need a generalist or open-ended autonomy. You need a specialist that executes the process, not one that drafts suggestions about it, with governance and approval gates built in. That’s the default, and it’s where we lead. ## Decision Agents: the specialist, governed from the first run Decision Agents are DataRobot’s specialists. Each one is built to make and carry out the decisions behind a specific business process, the ones that move a number the business already reports, across the systems, teams, and partners that process touches. Where a generalist is designed to handle anything, a Decision Agent is designed to handle one process correctly, every time, at a predictable cost. Governance comes from the Agent Workforce Platform they run on, so it’s there from the first run instead of added after. Through the DataRobot LLM gateway, you choose the model for each task, which means routine steps don’t have to run on the most expensive frontier model. Guard models check the steps that matter, and human approval gates sit wherever you decide a person needs to sign off. Each agent gets its own identity and a named owner, and its secrets live in the DataRobot credentials store instead of in code. OpenTelemetry traces of model and tool calls give your audit team a record of what the agent did and why. And Decision Agents run where you need them: in the cloud, on-prem, or air-gapped, on your own infrastructure. You get outcomes you can predict and spend you can plan for, without the standing risk surface of a long-running generalist. To see what that looks like, watch a scenario that takes a [$2.5B supply chain crisis to competitive advantage in 72 hours](https://github.com/user-attachments/assets/1fc91835-d00b-4ea6-b28d-d05a09798235). ## See governed autonomy for yourself For the open-ended end of the spectrum, DataRobot Labs has published two experimental open-source projects that show what a governed perimeter looks like in practice. ![Hermes architecture diagram](https://www.datarobot.com/wp-content/uploads/2026/10/architecture-1024x728.png) *Hermes architecture diagram* [Hermes Agent on DataRobot](https://github.com/datarobot-labs/datarobot-labs-hermes-agent) runs the open-source Hermes agent as a DataRobot workload. It’s experimental and community-maintained, not an officially supported DataRobot product, but it shows the full pattern end to end. It deploys from git with the DataRobot CLI, and you can turn on automatic redeploys on every push. The web chat sits behind DataRobot login and sharing, and the optional Slack bot only answers an allow-list of users. Model calls go through the DataRobot LLM gateway, so the agent holds no provider API keys and you can pick the model per job. Secrets live in the DataRobot credentials store, and on GitHub the agent acts as a GitHub App with short-lived installation tokens. Model calls and tool calls are traced with OpenTelemetry. ![Hermes on Datarobot single trace](https://www.datarobot.com/wp-content/uploads/2026/10/hermes-datarobot-tracing-single-trace-1024x610.png) *Hermes on Datarobot single trace* [datarobot-sync](https://datarobot-labs.github.io/datarobot-sync/) is the companion tool, also an experimental Labs project. It copies only what changed between a local directory and DataRobot Files, so an always-on agent keeps its skills, memory, and sessions across restarts. Long-running, autonomous agents have a real future for the problems that are truly open-ended and worth the spend. They need governance, identity, and controls in place from day one, before the first incident rather than after it. For everything else, a specialist running a guarded, reviewable flow is the better engineering and business decision. Autonomy where it pays off. Control where it counts.