"Feature Spotlight: How the Library gives you proven primitives to start from"
Modulo Team
Feature Spotlight: How the Library gives you proven primitives to start from
You should not have to build every pipeline from scratch. The Library is a catalog of schemas, agents, workflows, and connector packages you can copy and adapt. It sits inside your Modulo workspace and gives you working primitives to start from instead of blank configs. Each primitive is a complete, functioning unit - a schema that validates its output, an agent with a tested prompt, a workflow wired end-to-end, or an integration package that connects a tool to a pipeline. You browse, copy, adjust, and ship.
In short
- What it does: 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.
- When you'd use it: starting a new pipeline, onboarding a new tool, prototyping a flow, or replacing a brittle hand-built config with something that has already been tested by others.
- When you wouldn't: you already have a bespoke primitive that matches your exact use case and does not need upstream updates, or you are working on something with no community coverage yet.
- Copied primitives track
forked_fromand check for upstream updates by default.
The problem it solves
You want an agent that reviews pull requests and posts a structured comment with severity, file path, and a suggested fix. You could build one from scratch. That means defining the schema, writing the prompt, wiring the connector, testing the output shape, and tuning it until the reviews are actually useful. It works, but it costs an afternoon or more of trial and error, and the result is yours alone - nobody else has validated the prompt or the output against real pull requests.
The Library exists because that afternoon repeats across every team, every pipeline, every time someone needs a primitive that somebody else has already built and tested. A schema for PR review output is not unique to your org. A workflow that pulls context from GitHub and feeds it to an agent is not unique to your pipeline. The Library collects these patterns into a catalog where you copy a working version, adjust it to your context, and ship. The alternative is building from scratch every time, which is not slower in theory but is slower in practice because it means you are debugging prompts, output shapes, and connector bindings that others have already solved.
How it works
Primitive types
The Library holds four kinds of primitives. Each is a complete, functional 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. Bundles that define how Modulo talks to an external tool - what credentials are needed, what operations are supported, and what the API looks like. | A GitHub integration that provides PR read/write, issue management, and webhook bindings. |
Copy-to-adapt flow
You browse the Library, find a primitive that matches what you need, and copy it. One click creates a local editable instance in your workspace. The copy is yours - you can rename it, change the prompt, adjust the schema, swap the model backend, or rewire the workflow graph.
Every copy carries forked_from metadata: an immutable record of where it came from. By default, copied primitives check for upstream updates. When the original is improved, a flag is set on your fork indicating an update is available. You can apply the update to pull in the improvements, or set auto_update = FALSE to diverge freely and build on your own modifications.
Trust tiers
Community registry primitives carry one of two trust tiers:
- Verified publisher (green badge): signed by a Modulo-vetted key. No warning on copy - the publisher has been vetted and the signature confirms integrity.
- Community (amber badge): unsigned or self-signed. A warning appears on copy: "This primitive has not been verified by Modulo. 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. A community primitive may be excellent. The badge tells you who vouched for the signature, not whether the output is good.
Rating system
Users rate primitives after using them. One rating per user per primitive. Self-rating is blocked. You must have at least one prior copy-to-adapt before you can rate - you have to have used it. Ratings display as a weighted average with a review count. This is a lightweight signal, not a marketplace. The goal is to help the next person decide whether a primitive is worth copying, not to gamify contribution.
Battle-tested defaults
The Library is the primary onboarding path. On first boot, the UI surfaces recommended primitives for your declared tool stack. You start from library primitives and migrate to bespoke over time. This is not a fallback for when you cannot build something yourself. It is the recommended first step: use what works, then customise as your needs diverge.
Journey example: before and after
Before
Imagine a team lead named Ravi who needs a pipeline that triages incoming GitHub issues by severity and tags. He opens a blank pipeline, defines a schema for the output (severity, tags, summary), writes a prompt for the LLM agent, wires a GitHub connector to read the issue body, and tests it against a dozen issues. Half the prompts produce inconsistent output. The schema needs three revisions before it validates reliably. The connector bindings break when the GitHub API returns a different shape for pull request events versus issue events. Two days later, the pipeline works for the cases he tested but fails on edge cases he did not think about.
After
Ravi opens the Library. He searches for "issue triage" and finds a schema, an agent, and a workflow bundle. He copies the schema, which already validates the output shape he needs. He copies the agent, which has a prompt that has been tested against real GitHub issues by other users. He copies the workflow, which wires the GitHub connector, the agent, and the schema together. He adjusts the prompt to match his team's tagging conventions, changes the severity options, and runs it against the same dozen issues. The output is consistent, the schema validates on the first pass, and the connector bindings handle both issues and pull requests. He ships it in an afternoon instead of two days, and the pipeline has a rating and review count that tell him it has been tested by others before him.
When to use it vs. when not to
Use the Library when you are starting something new and a primitive already exists for the tool or pattern you need. It is the fastest path to a working pipeline. Use it when you want proven defaults instead of guessing at prompt templates and output shapes. Use it when onboarding a new team member - they can start from a library primitive and learn the system by adapting a working version rather than building from scratch.
Do not use it when your use case is genuinely novel and no primitive covers it. Do not copy a primitive just to change everything about it - that is building from scratch with extra steps. And do not rely on ratings alone to judge whether a primitive fits your context. The rating tells you how many people have used it and what they thought. It does not tell you whether it works for your specific pipeline, your model backend, or your data shape.
Where it fits
The Library is one part of a larger system. Schemas validate output, agents produce it, workflows wire the pieces together, and gates decide what ships. HITL gates are how you 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. Together they are how a pipeline earns the right to run with less oversight over time. For the full picture, see The principles of Modulo.
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. Try the hosted demo at demo.modulo.run to browse the Library and copy a primitive, or use the contact page to talk to us about building your first pipeline from a library primitive.