Platform · Agent builder

Build it on a canvas. Ship it through governance.

An agent in Liba is a flow you can see. You drag nodes onto a canvas and wire them together, and what you end up with is a diagram anyone in the room can read, argue with and sign off, rather than a prompt buried in a text box.

That matters more than it sounds. The person who understands the process is rarely the person who can write the code. On a canvas, they can build it themselves, and the compliance officer can review it without learning a framework.

No code is required. A Python node is there when you want it.

The nodes

Intake. Where work arrives: a form, an email, an uploaded file, a queue, a scheduled run, or a call from another system. The intake node tidies up whatever comes in so the rest of the flow can rely on its shape.

Knowledge. Grounds the agent in your documents. Point it at a knowledge base and it retrieves the relevant passages and carries the citations forward, so every downstream answer can name its source. Retrieval respects the permissions the requesting user already holds.

Model. The reasoning step. Each model node is configured independently, so a flow can route a cheap classification to a small model and a difficult judgement to a large one, or to an open model running on your own hardware.

Logic. Branches, loops, conditions and validation. This is where a flow stops being a single question and starts being a process: checking a document against a requirement list, looping over line items, routing by confidence score.

Systems. Reads from and writes to the tools you already run. A flow that classifies a permit application is not much use until it writes the outcome back into case management.

Review. The evaluation step. Check an output against a rule, a policy or a second model before it goes any further.

Human. An approval gate with a named reviewer. Insert it anywhere. Route to it conditionally, so routine cases flow through and the marginal ones land in a queue with the reasoning attached.

Output. The result, in the shape the receiving system expects: a memo, a structured record, a filled template, a call to an API.

Orchestrator. For work too broad for one agent. The orchestrator delegates to specialists, each of which knows one domain deeply, and merges their results. That way broad work gets split up instead of watered down.

Versions, environments and approval

Every save is a version, with a readable diff. You can see what changed in a flow, who changed it and when, in the same visual language you built it in rather than as a JSON blob.

Development, staging and production are separate environments. Publishing to production needs approval. Governance here is the path the work has to travel, not a policy document filed beside the tool.

What you can hand an auditor

A diagram of the process. A version history with diffs and approvers. A complete log of every run, covering inputs, outputs, model calls, tool invocations and approvals, ready to replay and retained for as long as you configure.

Assume the auditor will ask. Build accordingly.