Python SDK vs. Coded Agents vs. Studio Web: the three-way choice you didn't know you were making

Most developers landing on UiPath hit the same wall I did when I started mapping the pro-developer motion here: three doors, no map. You can build an agent with the uipath-python SDK, with Coded Agents using the UiPath CLI, or in Studio Web at cloud.uipath.com. All three are first-class options, but nothing tells you which to open first, or what you give up by picking wrong. You can watch it play out in the wild.

For example, a UiPath Forum thread titled "UiPath SDK Confusion" has a developer writing, "I am confused about the intention of the SDK . . . I don't see a way to publish a non-agent type process using the SDK . . . I thought the Python SDK would enable me to create a python script/project that actually integrates with queues, assets, jobs...". And they are right—the README describes what he wants it to do, and the examples he wants are in the repo.

However, between the README and the examples, the SDK documentation offered one prominent on-ramp: a quickstart link building your first agent on UiPath . . . and that quickstart didn’t have what he was looking for. That was our miss—and something we fixed. But it’s a problem that goes beyond that SDK. Every product page and doc set in the industry explain how to build the thing, and each of them do it well. But they rarely contextualize whether that’s the solution you should be building.

I hope that this map helps bridge that gap on building agents for UiPath.

The one-line triage for UiPath agent developer entry points:

• Python SDK, self-hosted: you host and run the agent and use the SDK to call UiPath services from your own code. Pick this when UiPath is a dependency rather than your runtime.

• Code-first, UiPath-hosted: you write the same Python agent code as the first option, but UiPath hosts, scales, monitors, and versions it. Pick this when you want your code in production without owning the operational surface.

• Studio Web, browser-built: you build a fully agentic automation using the agent builder canvas at cloud.uipath.com. Pick this when the work has to be co-owned with people who don't live in an IDE, or when it leans harder on platform connectors and tools than on your own code.

The first two options are both the same “code-first” path; it’s the same Python against the same SDK. The difference between the two is who hosts and operates the agent (you vs. UiPath). Studio Web is the “low-code” path. Keep that mapping in mind if you move between this post and the product pages.

Now the details.

Door 1: uipath-python SDK direct – Python agents you host

The uipath-python SDK is the base layer for everything Python at UiPath. Straight from the repo: "A Python SDK that enables programmatic interaction with UiPath Cloud Platform services . . . also features a CLI for creation, packaging, and deployment." Using the SDK, your Python code can reach into UiPath platform services via APIs or via the included uipath command line interface (CLI).

Reach for the UiPath SDK when you have Python code or a service that needs to talk to UiPath Platform™ services (e.g., queues, assets, jobs, connectors); the things Orchestrator has been managing for years, now scriptable from your own code. You're not asking UiPath to host anything. You're asking it to give you the primitives.

The SDK stops being the right door the moment you want UiPath to run the thing. It gives you the primitives and leaves operations to you. If you are writing an agent and you want it running on UiPath, you have opened this door one too early.

Door 2: coded agents via CLI – hosted, scaled, monitored agents from CLI

A coded agent (a code-first approach to building agents), per UiPath Getting Started guide, is "a Python agent deployed on the platform." One CLI command packages your code, and the platform takes over hosting, scaling, monitoring, and versioning.

A note on the UiPath CLIs, because the names will bite you. The Python SDK ships its own CLI, called uipath. Separately there is uip, the UiPath CLI, released this year as UiPath for Coding Agents: it reaches most of the platform rather than just the Python surface, and it is what the coding-agent skill packs drive. Use uip. Keep both installed for now, since uip codedagent forwards nearly every subcommand to uipath underneath.

The loop is short: uip login gets you signed in, uip codedagent setup and uip codedagent init scaffolds the project, uip codedagent run agent exercises the agent locally. When you're ready to ship, uip codedagent deploy bundles it up and UiPath takes it from there. That's the wedge over raw Python SDK for your self-hosted agent: one uip codedagent deploy CLI command sends it from your machine to a hosted, scaled, monitored, versioned agent.

That forwarding is worth noticing. uip codedagent is a thin layer over the SDK's own CLI, which means Door 2 is not a different technology from Door 1. It is the same code with the operational surface handed to UiPath. Moving between them costs very little, and that is the strongest practical reason to start with the SDK if you are not sure yet.

The other thing coded agents do that matters: because the SDK is the base layer, framework-specific runtimes slot in on top. uipath-langchain-python covers LangChain and LangGraph agents, and the growing UiPath Agent Runtime Integrations in the uipath-integrations-python monorepo adds runtimes for LlamaIndex, Google ADK, OpenAI Agents, Microsoft Agent Framework, and PydanticAI. So, if your agent is already built on one of those, that logic keeps working when Coded Agents packages it.

Door 3: UiPath Studio Web – the browser IDE for cross-platform teams

Studio Web is UiPath's browser low-code canvas at cloud.uipath.com. No install, no local environment. The UiPath product page for Studio calls Studio Web a "browser-based IDE for agentic and API-first automation. Best for: AI agents, API workflows, agentic process modeling, apps, and cross-platform teams." The Studio Web docs overview describes the stated audience as broad on purpose: "business users, citizen developers, RPA developers, IT admins, Orchestrator admins."

You might read that and assume Studio Web isn't for you if you live in VS Code. There are two scenarios where Studio Web may be the place you want to build your agent:

• First, the moment your work has to be co-owned by someone who won't ever open a terminal: a process or automation owner, an Orchestrator admin, an ops lead. With Studio Web, you can build the same class of thing, with full agentic capabilities and the ability to call external APIs and tools, but in a canvas that the whole team can see and edit.

• Second, when the agent leans on the platform more than on your own code. Integration Service connectors, API workflows, UiPath Maestro™ flows (our long-running process orchestration layer), and other UiPath capabilities exposed as agent tools are first-class objects in Studio Web. In a coded agent, every one of them is an API call you write and maintain yourself.

If you're a solo pro developer who never collaborates outside your IDE, you'll probably reach for coded agents first and only cross into Studio Web when the org catches up to what you built.

The decision you're actually making

Three questions, in this order.

1. Do I need UiPath to host my agent? If not: take the SDK direct door. You keep the runtime and call UiPath for services like queues, assets, jobs, and connectors. If yes, keep going.

2. Does everyone who owns this work in an IDE? If not, then Studio Web is the door. A canvas that the whole team can open beats a repo that only you can run.

3. Is it mostly my code, or mostly UiPath capability? If it’s mostly your code, including anything already on LangGraph or another framework: go with coded agents, shipped with one command. If you’re using a significant amount of UiPath, meaning Integration Service connectors, API workflows, Maestro flows, and other capabilities as agent tools, then take the Studio Web door, even if you’re a full-code developer.

That's the triage. Where it does not resolve cleanly, the deciding factor is usually organizational rather than technical, and it is worth naming that out loud instead of relitigating the tooling.

How this compares to the OpenAI Agents SDK, LangGraph, Google ADK, and the Claude Agent SDK

Every serious agent platform in 2026 is doing the same thing: splitting the SDK from the hosted and visual layers. OpenAI shipped the Agents SDK in March 2025 as the production version of Swarm: a small, deliberately opinion-light set of primitives (Agents, Handoffs, Guardrails at launch), and provider-agnostic through an official LiteLLM extension that opens the door to LiteLLM's more than 100 supported providers. Google's Agent Development Kit is an open-source, code-first toolkit available across Python, TypeScript, Go, Java, and Kotlin. LangGraph pairs its open-source graph library with a hosted deployment layer and a visual studio - originally shipped as LangGraph Platform and LangGraph Studio, rebranded to LangSmith Deployment and LangSmith Studio in late 2025.

Anthropic's Claude Code is, in their words, "an agentic coding tool that lives in your terminal," and the Claude Agent SDK exposes Claude Code's underlying tools and runtime for developers building their own agents on top.

The UiPath wedge sits on top of that pattern rather than against it. Bring the framework you like. UiPath provides capabilities—orchestration, human-in-the-loop steps, enterprise connectors, and governance layer—that work with whatever agent you’ve built, providing the parts that are also the hardest to reproduce from scratch in a reliable and compliant fashion.

In a workshop I ran at the WeAreDevelopers conference, I framed complex enterprise process as having four phases—ingestion and triage, research and analysis, data entry, resolution and close—and the point is that there's no conductor by default in most agent stacks. Nothing that knows where a case is at any given moment. Execution does the work; orchestration makes sure the outcome happens. That's the layer that UiPath adds on top of whatever agent framework you brought. And that layer also provides RPA reach into legacy and no-API systems, UiPath IXP (Intelligent Xtraction & Processing) for document-heavy work, Maestro for end-to-end orchestration, Action Center for human-in-the-loop, and an AI Trust Layer that has been independently certified to both ISO 42001 and AIUC-1.

Where to start building agents on UiPath

If you walk through one of these doors and it does not lead where this post says it does, tell me. That forum thread at the top is a bug report against our documentation. This map is the first patch.

• UiPath developer hub: https://www.uipath.com/developers

• uipath-python SDK: https://uipath.github.io/uipath-python/

• Getting Started with Low-Code UiPath Agents: https://docs.uipath.com/getting-started/other/latest/developer-guide/agents-lowcode

• Getting Started with Coded Agents: https://docs.uipath.com/getting-started/other/latest/developer-guide/agents-langgraph

• UiPath Skills and CLI: https://github.com/UiPath/skills

Frequently asked questions

Q1. What do I do if I just want to call Orchestrator from a Python script?

The uipath-python SDK is built for exactly this: queues, assets, jobs, buckets, processes, and connections, all reachable from your own Python. You are not building an agent, and you do not need to. If you want UiPath to run that script rather than just be something your script calls, what you want is a coded function, not a coded agent. UiPath defines a coded function as "Python code with typed input and output that runs as an Orchestrator job,” “letting an agent run custom Python code as a deterministic, process-based tool alongside automations and API workflows.” It uses the same SDK, same CLI, no LLM. To get started with Coded Functions, check out the Getting Started with Python Functions documentation.

Q2. What is the difference between a coded agent and a coding agent?

One suffix, but two very different things. A coding agent is a tool like Claude Code, Cursor, or Codex that writes code in your IDE. A coded agent is a code-first approach to building agents, the Python agent you deploy to UiPath and the CLI names it directly in the command you type: uip codedagent.

You can use the first to build the second, which is what UiPath for Coding Agents is for. That is exactly why the two names keep colliding. Throughout this post, coded agent means the thing you deploy.

Q3. Is uip the same as uipath?

No. uipath is the CLI that ships inside the Python SDK and arrives with pip install uipath, and uip is the UiPath CLI, a separate install, and it reaches most of the platform rather than just the Python surface.

Use uip. If you are building coded agents, keep both on your machine for now — uip codedagent forwards nearly every subcommand to uipath underneath.

Q4. Can I keep my LangGraph agent?

Yes. uipath-langchain-python covers LangChain and LangGraph. The uipath-integrations-python monorepo adds runtimes for LlamaIndex, Google ADK, OpenAI Agents, Microsoft Agent Framework, and PydanticAI.

Your graph logic keeps working as written. What changes is the wrapper: UiPath takes over hosting, scaling, monitoring, and versioning, and your agent gains access to UiPath platform services it did not have before.

Q5. Can I move an agent from one door to another later?

Moving between code-first agents (self-hosted or running on UiPath) is easy. It is the same Python against the same SDK, so adopting coded agents is mostly a matter of adding the uip CLI and publishing it into UiPath for hosting.

Moving from a code-first agent to a low-code agent is harder - a coded agent is a Python project running python code; a low-code agent is a Studio Web canvas artifact. Moving between a coded agent to a low-code agent often means rebuilding rather than importing. That is the one boundary in this post without a cheap path, and it is worth knowing before you choose rather than after.

And while you can add a coded agent to a Studio Web solution by creating a ‘coded agent’ project and adding that Project ID to your .env, the agent remains a coded agent project and the code will need to be maintained in your local developer environment (outside of Studio Web).

Q6. Do I need Studio Web if my whole team are developers?

Probably not. If everyone who owns the work lives in an IDE and the agent is mostly code you wrote, UiPath coded agents gives you the same runtime through a workflow you already know. Two things change that answer. The moment someone who will not open a terminal has to co-own the work, or the agent leans harder on connectors, API workflows, and Maestro flows than on your own code, Studio Web stops being the lesser choice and becomes the practical one.