Low-code agents wired straight into your live data

At Sapphire this year, SAP showed Joule Studio 2.0 generating a complete agent from a single natural-language description — not just the code, but the product spec, the workflow logic, the multi-agent setup, and even the evaluation suite. And the agents it builds are "natively grounded in live business data and end-to-end processes across your SAP landscape." OutSystems shipped a comparable low-code agentic platform. The pitch is the same: describe the agent you want, and it appears, already plugged into your real systems.

This is a real leap, and I don't want to be the person waving it away. Letting a business analyst build a working agent on the production system without waiting weeks in an engineering queue is genuinely valuable. But it's worth being clear- eyed about what just got easy — because building the agent was never the risky part. Wiring it to your live data and letting it act was.

What "low-code on live data" actually means

Strip away the demo magic and here's the arrangement: a person who is not an engineer describes what they want in a sentence, and a tool produces an agent that can read and act on your real business systems — orders, finance, customer records — at machine speed. The grounding in live data is exactly what makes it useful. It's also exactly what makes it dangerous, and those two facts are inseparable.

The thing that determines how much damage an agent can do isn't how smart it is. It's how much it can touch. A recent assessment found that tool execution — what an agent is allowed to actually do — is the single biggest predictor of blast radius, explaining 76% of it. A low-code agent born already connected to live ERP starts life with maximum reach. That's the whole feature, and the whole problem.

Most companies can't contain what they're already running

If the containment story were solid, this would be fine. It isn't. The numbers on organizations already running agents are sobering: 63% can't enforce limits on what an agent is allowed to do, 60% can't quickly shut a misbehaving agent down, and 55% can't isolate it from the rest of the network. Seventy percent have agents in production, and most of those agents have more access than the humans doing the equivalent job.

Now hand the ability to create those agents to people without engineering training, on a platform that connects them to live data by default, and you can see where this goes. You don't get one carefully-scoped agent. You get dozens of ungoverned ones, each with broad reach, spun up by people who were never asked to think about permissions, and which nobody can fully see or stop. That's not a hypothetical; it's the citizen-developer pattern colliding with the exposed-by-default reality I wrote about, at much larger scale.

The boring guardrails matter more, not less

The reflex is to say "then don't let non-engineers build agents." That's both unrealistic and wrong — the productivity is real and the queue was a genuine problem. The right response is that when creation gets democratized, the guardrails have to be built into the platform, not left to the goodwill of whoever typed the sentence. A few things that have to be non-negotiable:

• Least privilege by default, not max reach. An agent should start with the narrowest access that does its job and earn more deliberately — the opposite of "born connected to everything." If the platform defaults to broad access, that's the bug.
• A kill switch that actually works. If 60% of orgs can't stop a misbehaving agent, that's the first thing to fix. You should be able to pause any agent instantly, no matter who built it.
• A real boundary between deterministic systems and agent judgment. This is the same lesson as redesigning workflows for agents: the rules, limits, and approvals that protect live data should be hard, deterministic gates the agent reasons within, not things it can freely act across.
• Sandboxing as a procurement gate. The same research found tested sandboxing cuts residual risk roughly 2.6×. If a low-code platform can't show you how it isolates what its agents can touch, that's your answer.

The bottom line

Low-code agents on live data are going to be everywhere, fast, because the upside is obvious and the demo is irresistible. I'm not telling you to avoid them — I'm telling you that the easy part just got easier and the hard part didn't move. Generating an agent from a sentence is solved. Making sure that agent can't quietly wreck your live business data, and that someone can see and stop it, is exactly as hard as it always was.

So when a platform offers to let anyone build an agent wired into your real systems, ask the unglamorous questions before you celebrate: what can it touch, who can stop it, and where's the wall between its judgment and your source of truth? If the platform has good answers, this is a gift. If it doesn't, you're not democratizing agents — you're democratizing the blast radius.