Library & bots

In one line. Two advanced pages in the Assets group: the Library (reusable snippets you drop into pipeline steps) and Bots (automated 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 > Agents > Assets > Library and Studio > Agents > Assets > 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 pair: 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

Studio > Agents > Assets > 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.

Every library item has exactly one entry point — def main(**kwargs). Keep the function small and fast: it runs inside the pipeline step’s own time budget. Long-running work belongs in a Service (LLMs & services) instead.

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 a searchable list of library items; more load as you scroll. 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	If it isn’t there, your access doesn’t allow creating library items.
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. The type menu also covers the other reusable-asset shapes the platform keeps in the same place: Function, Prompt, Javascript, Template, API Endpoint, and UI Card, each holding the reusable asset its name describes.

Tip. When in doubt, you want Python. 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 > Agents > Assets > 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.
• Access-gated. + Library, Edit, Delete, Publish and Convert To Tool each depend on the access you’ve been given — if one is missing, ask your administrator.
• Sandboxed and budgeted. A Python item runs inside the pipeline step’s own time budget — keep it small and side-effect-free; reach for a Service (A2) for slow work.

Bots (RPA)

Studio > Agents > Assets > Bots

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 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. Rows a bot feeds in behave exactly like any other datasheet rows — an agent querying them cannot tell the difference.

By design, today. The Bots page 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 > Agents > Assets > 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 flow (Studio > Agents > Agent Toolkit > Agents, then filter the list to XFlow) and 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

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