Library & bots

In one line. Two advanced Asset Builder surfaces: the Library (reusable sandboxed Python snippets you drop into pipeline nodes) and Bots (RPA workers that feed structured data in). You’ll be able to. Write a tiny derivation function once and call it from any XFlow node, and recognise what an RPA Bot is and where its data lands. Where this lives. Studio ▸ Asset Builder ▸ Library and Studio ▸ Asset Builder ▸ Bots (/studio/asset_builder/library, /studio/asset_builder/bots).

Why this corner exists

Most of this Academy is no-code. This page is the small, optional corner where a little code buys a lot of reuse. When two XFlow nodes need the same bit of logic — normalise a date, reshape a JSON payload, compute a derived field — you don’t paste it twice. You author it once as a Library item and reference it from every node that needs it. Bots are the other half of this surface: pre-built RPA workers (think: a robot that opens an Excel file and types its rows into the platform) that get structured data in without a connector. Both are advanced and optional — skip this page until a pipeline actually needs them.

The Library

What a derivation library is (and isn’t)

A Library item (full name: derivation library) is a Studio-authored, sandboxed Python callable — a single function with the shape def main(**kwargs) — that you reuse inside XFlow and mesh nodes. It is not a public PyPI package, not something you pip install, and not a standalone service. It is a named snippet the platform runs in a sandbox when a pipeline node calls it, passing the node’s inputs in as kwargs and using the function’s return value as the node’s output.

Under the hood. Library items are stored in legacy Azure-Table storage and resolved by the orchestrator at run time. The contract is exactly one entry-point: main(**kwargs). Keep the function pure and fast — it runs inside the pipeline’s execution budget, not as a long-running worker. Long-running external work is a Service (LLMs & services), not a Library.

The page

┌ Library ──────────────────────┐┌ normalise_date            v2                             ┐
│ search    Custom (Type)       ││                                                          │
│ ───────────────────────────── ││  Publish   Edit   Delete   [ Convert To Tool ]           │
│ ▸ normalise_date     v2       ││ ──────────────────────────────────────────────────────── │
│   reshape a date to ISO       ││  Access Level   Private                                  │
│ ▸ vendor_lookup      v1       ││  Library Type   Python  (def main(**kwargs))             │
│ ▸ score_risk         v3       ││  Version        v2                                       │
│   …                           ││                                                          │
│ ── No more libraries ──       ││                                                          │
│ [ + Library ]                 ││                                                          │
└───────────────────────────────┘└──────────────────────────────────────────────────────────┘

The left rail is the searchable, lazily-loaded list of library items (server-side lazy-load under the search). Each row shows the name, a version chip (V1/V2…), and a description; items with history show an “N Past Versions” expander. The list ends with a “No more libraries” marker; the empty state reads “No Libraries found. Create new Library.” The details panel shows the selected item’s header actions plus the detail rows Access Level (Public/Private), Library Type (icon + label), and Version. A Delete header action removes the item.

Control	What it does	Notes
+ Library (footer)	Opens the create-library editor	Permission-gated (createLibrary).
Custom ▸ Type filter	Narrows the list to chosen Library Types	Multi-select chips; Clear / Apply.
N Past Versions	Expands prior versions of an item	Each version is selectable and inspectable.
Publish	Publishes the item to a Hub	Ships the snippet for reuse elsewhere (Hubs & distribution).
Edit	Opens the item for editing	Every edit creates a new version.
Convert To Tool	Wraps the library item as an agent Tool	Bridges Library → the agent world (Tools & functions).

The Library Type options

You’ll author Python most of the time — a sandboxed def main(**kwargs) callable, the focus of this page — or Function, the Function flavour of a reusable callable. The type menu also covers the other reusable-asset shapes the platform stores in the same place: Prompt, Javascript, Template, API Endpoint, and UI Card, each holding the reusable asset its name describes.

Tip. When in doubt, you want Python (or Function). The other types exist so the Library can be the single catalogue for all reusable assets — and so any of them can be Converted To Tool for an agent to call.

Create a Python library item

1. Go to Studio ▸ Asset Builder ▸ Library.

2. Click + Library (footer, or the empty-state CTA).

3. Give it a name (e.g. normalise_date) and a short description.

4. Set Library Type to Python.

5. In the body, write a function with the required entry point:

   def main(**kwargs):
       raw = kwargs.get("value", "")
       # reshape, look up, compute
       return {"normalised": raw.strip().upper()}

   The node’s inputs arrive as kwargs; whatever you return becomes the node’s output.

6. Save. The item appears in the list with a V1 chip.

Calling it from an XFlow node

Libraries don’t run on their own — a pipeline node invokes them. In the XFlow editor (XFlows & pipelines), the Python Library node (palette) is the node that calls a library item: drop it onto the canvas, open its config, and pick your library item. At run time the platform passes the node’s inputs in as kwargs and uses the return value downstream. One snippet, every pipeline that needs it.

Watch out. Editing a library item creates a new version. Nodes reference an item by identity — confirm which version a critical pipeline picks up before you change shared logic, or you may quietly alter every flow that calls it.

Behaviours to know

• Versioned. Every edit bumps the version; old versions stay inspectable via Past Versions.
• Access Level. Items are Private by default; Publish is how a snippet leaves the project.
• Permission-gated. + Library, Edit, Delete, Publish and Convert To Tool each obey your role.
• Sandboxed and budgeted. A Python item runs inside the pipeline’s execution budget — keep it small and side-effect-free; reach for a Service (A2) for slow work.

Bots (RPA)

A Bot is a robotic-process-automation worker whose job is to feed structured data into the platform — most classically, an Excel → datasheet path: a robot opens a spreadsheet and pushes its rows in as structured records, without you wiring up a connector for it. Bots are managed on the Bots page so a solution builder can see which RPA processes exist and what data they’re producing.

The page is a two-pane view: a left rail listing the RPA processes/bots (with a loading state while it fetches), and a bot card hosting a bot-details table that shows the structured data the selected bot has produced — rows of fields, with a status per row. That table is the substance of the page: the worker’s output.

How Bots relate to datasheets

The data a Bot feeds in lands as structured rows — the same flat, SQL-queryable shape as a Datasheet (Drive & datasheet). So the mental model is: a Bot is an input mechanism for the structured-data layer, in parallel with materialising a datasheet from a View or sourcing one from a spreadsheet/DB. Once the rows are in, an agent can query them with SQL exactly as it would any datasheet.

Under the hood. The Excel-from-bot path lands rows via the platform’s RPA bot helper into a datasheet table — so downstream, bot-fed data is indistinguishable from any other datasheet.

By design, today. The Bots surface is a thin management view — you inspect processes and the data they’ve produced. Authoring and operating the RPA robots themselves happens outside this page; treat Bots as visibility over RPA inputs, not a full RPA studio.

Library vs Tool vs Skill — which do I reach for?

These three feel similar (all “reusable capability”), but they live in different worlds:

You want…	Reach for	Why
A bit of logic reused across pipeline nodes (reshape, derive, normalise)	Library (this page)	It’s the snippet a Python Library XFlow node runs.
A callable an agent can invoke during its reasoning (search, an API, a function)	Tool / Function (A5)	Tools live in the agent’s toolbelt, not in a pipeline node.
A named, catalogued capability bundle shared across many agents	Skill / Skill Pack (A6)	Skills are higher-level, packaged, and discoverable across agents.

Tip. They’re bridges, not silos: a Library item can be Convert To Tool-ed to hand it to an agent, and packaged capabilities flow up into Skills. Start at the lowest level that solves your problem — a Library snippet — and promote only when a real second consumer appears.

Try it yourself

Author a trivial derivation and call it from a pipeline:

1. Studio ▸ Asset Builder ▸ Library → + Library. Name it shout, set Library Type = Python, body:

   def main(**kwargs):
       return {"text": str(kwargs.get("text", "")).upper()}

   Save — it appears as V1.

2. Open any XFlow (Studio ▸ Automation ▸ XFlow), drag a Python Library node onto the canvas.

3. In the node config, select your shout library item and wire an input that supplies text.

4. Execute the flow with a sample input and confirm the node returns the upper-cased text.

5. Bonus: back on the Library page, select shout and click Convert To Tool — you’ve just turned a pipeline snippet into something an agent can call.

Where to go next

• Shaping the experience — turn your built solution into the surfaces your end-users actually see.
• XFlows & pipelines — the Python Library node inside a pipeline.
• Tools & functions — promoting a snippet to an agent capability.
• Glossary — Library / Derivation Library and Bot (RPA) in one place.