The Library is a catalog of schemas, agents, workflows, and connector packages you copy and adapt. It sits in your Farna Control workspace and gives you working primitives instead of blank configs: a schema that validates output, an agent with a tested prompt, a workflow wired end-to-end, or an integration package connecting a tool to a pipeline. You browse, copy, adjust, and ship.

In short

A shared catalog of four primitive types - schema, workflow, agent, and integration - that you copy into your workspace and adapt. One click creates an editable instance with provenance metadata.
Use it to start a pipeline, onboard a tool, prototype a flow, or replace a brittle config with something already tested by others.
Skip it when a bespoke primitive already matches your use case and needs no upstream updates, or when there is no community coverage yet.
Copied primitives track forked_from and check for upstream updates by default.

The problem it solves

Say you want an agent that reviews pull requests and posts a structured comment with severity, file path, and a suggested fix. Building it from scratch means defining the schema, writing the prompt, wiring the connector, testing the output shape, and tuning until useful: an afternoon or more of trial and error, with a result nobody else has validated against real pull requests. That afternoon repeats across every team and pipeline. A PR-review schema is not unique to your org, and neither is a workflow that pulls GitHub context and feeds it to an agent. The Library collects these patterns so you copy a working version, adjust it, and ship.

How it works

Primitive types

Four kinds of primitives, each a complete unit with inputs, outputs, and constraints defined:

Type	What it is	Example
`schema`	Schema definitions that validate agent output. Define the shape, constraints, and required fields for any typed artifact.	A schema that enforces a PR review object with `severity`, `file_path`, and `suggestion` fields.
`workflow`	Workflow bundles. A complete pipeline graph - nodes, edges, agent prompts, and gate configurations - you can import into your workspace.	A PR review workflow that pulls a diff from GitHub, feeds it to an LLM, validates the output against a schema, and posts a comment.
`agent`	Agent definitions. A configured node with a prompt, model backend, output schema, and connector binding.	An agent that drafts a PR description from a diff, using Anthropic models and a structured output schema.
`integration`	Connector type packages that define how Farna Control talks to an external tool: needed credentials, supported operations, and the API shape.	A GitHub integration that provides PR read/write, issue management, and webhook bindings.

Copy-to-adapt flow

Browse the Library, find a primitive that matches, and copy it. One click creates a local editable instance: change the prompt, schema, model backend, or workflow graph. Every copy carries forked_from metadata, an immutable record of its origin, and checks for upstream updates by default. When the original improves, a flag appears on your fork; apply the update, or set auto_update = FALSE to diverge and build on your own changes.

Trust tiers

Community primitives carry one of two tiers:

Verified publisher (green badge): signed by a Farna Control-vetted key. No warning on copy; the signature confirms integrity.
Community (amber badge): unsigned or self-signed. A copy warning reads: "This primitive has not been verified by Farna Control. Review the prompt template and schema before use." You can still use it, but you know the provenance.

The tier does not judge quality: a verified publisher primitive has a vetted signing key, and a community primitive may be excellent. The badge says who vouched for the signature, not whether the output is good.

Rating system

Users rate primitives after using them: one rating per user, self-rating blocked, and at least one prior copy-to-adapt before you can rate. Ratings display as a weighted average with a review count - a lightweight signal to help the next person decide whether a primitive is worth copying, not a marketplace or a contribution game.

Battle-tested defaults

The Library is the primary onboarding path. On first boot, the UI surfaces recommended primitives for your declared tool stack, and you start from library primitives before migrating to bespoke. Use what works, then customize as needs diverge.

Journey example: before and after

Before

Team lead Ravi needs a pipeline that triages GitHub issues by severity and tags. He defines a schema (severity, tags, summary), writes an LLM prompt, wires a GitHub connector to read the issue body, and tests against a dozen issues. Half the prompts are inconsistent, the schema needs three revisions, and the connector bindings break when the GitHub API returns a different shape for pull request versus issue events. Two days later it works for his test cases and fails on edge cases.

After

Ravi searches the Library for "issue triage" and finds a schema, an agent, and a workflow bundle. The schema validates the output shape he needs, the agent's prompt has been tested against real GitHub issues, and the workflow wires the connector, agent, and schema together. He adjusts the prompt to his team's tagging conventions, changes the severity options, and reruns the dozen issues. The output is consistent, the schema validates first pass, and the bindings handle issues and pull requests. He ships in an afternoon instead of two days, with a rating and review count showing it has been tested.

When to use it vs. when not to

Use the Library when a primitive already exists for the tool or pattern you need: it is the fastest path to a working pipeline, gives you proven defaults, and lets a new team member learn by adapting a working version. Skip it when your use case is novel. Do not copy a primitive just to change everything, which is building from scratch with extra steps, and do not rely on ratings alone: the rating says how many people used it and what they thought, not whether it works for your pipeline, model backend, or data shape.

Where it fits

The Library is one part of a larger system: schemas validate output, agents produce it, workflows wire the pieces, and gates decide what ships. HITL gates add human review at the right moments - see Feature Spotlight: How HITL gates stop bad agent output before it ships. The Library gives you the primitives; gates give you the governance. For the full picture, see The principles of Farna Control.

Go deeper

Read the Library docs for the full copy-to-adapt flow and upstream update mechanism, or the related docs on schemas and agents. Take the product tour to browse the Library and copy a primitive, or use the contact page to build a pipeline from one.