Blueprints

Browse published workflow and agent blueprints and grab them into your project as independent, editable copies

What Blueprints are

A blueprint is a ready-made workflow or agent, published to a catalog that every organization on the platform can browse. When you find one you want, you grab it into one of your projects, and what lands there is a brand-new, fully independent copy that you own and can edit freely.

Blueprints exist so a good build doesn't stay trapped in the project it was built in. A KYB verification flow, a document-compliance reviewer, a support-triage agent: someone builds it once, publishes it, and every other team starts from a working version instead of a blank canvas.

Blueprints are an in-product catalog of templates. This is different from Cloud Marketplace, which is about buying a MagOneAI subscription through AWS, Azure, or GCP.

The model in one paragraph

A blueprint stores an immutable, sanitized snapshot of the source asset, completely decoupled from it. Publishing exports the source's Hub-published version, strips anything sensitive or environment-specific, and stores the result. Grabbing copies that stored snapshot into your project as a new asset with fresh identifiers and no link back. Editing or re-publishing the source workflow never changes the listing; removing or republishing the listing never changes anything anyone has already grabbed.

Browsing

Blueprints appears in your organization's navigation. The listing page shows every published blueprint, with:

Search across blueprints
Category filter: Productivity, Sales, Support, Finance, Engineering, HR, Marketing, Other
Type filter: All, Use Cases, or Agents
Sort: Newest first (default), Oldest first, Most grabbed, or Name (A to Z)

Results are paginated at 12 per page.

The detail page

Opening a blueprint shows its full description, which supports rich formatting, embedded images, video, and downloadable documents, alongside a details panel:

Field	Meaning
Type	Use Case or Agent
Category	Its catalog category
License	MIT, Apache 2.0, Proprietary, or Custom
Grabs	How many times it has been installed
Published	When the listing was created
Dependencies	External integrations it needs, plus notes about what isn't included

Two actions are always available: Grab it, and Preview, a read-only view of the actual workflow or agent configuration, so you can see how it's built before committing.

Grabbing a blueprint

Review what it needs

The grab dialog opens with the full description and a What this needs panel listing the external integrations the blueprint expects, or telling you plainly that no external integrations are required.

Choose a project

Pick the project to grab into. You need write access to that project.

Name it

The blueprint's name is pre-filled; change it to whatever makes sense in your project. If a workflow with that name already exists there, the grab is refused with a clear conflict message. Rename and try again.

Check the readiness report

Once a project is selected, the dialog re-checks the dependencies against that project and marks each integration either connected or configure after grab, so you know what's left to wire up before the first run.

Confirm

Confirm the grab. On success you can jump straight to it: Open in Canvas for a use case, Go to Agent for an agent.

You can also start from a blueprint when creating a use case: the create panel has a From blueprint mode alongside Blank, with its own searchable picker.

What you get, and what you have to finish

A grabbed blueprint is a genuine copy: new identifiers throughout, no foreign key back to the listing, no shared state with anyone else who grabbed it. Edit it however you like.

To make that copy portable and safe, some things are deliberately not carried over:

Not included	What to do
Knowledge bases	Attach your own after grabbing. The dependency notes say so explicitly.
LLM configurations	Your project's default model is used unless you set one.
MCP connections and connection hints	Connect the required integrations in your project.

This is why the readiness check matters. A blueprint that needs an integration will import cleanly and then fail at run time if that integration isn't connected. The panel tells you which ones up front.

For a use case, the grab brings across the whole tree: the workflow itself, the agents it references, every child workflow it calls, and (for a Super Agent) the use cases it can call as capabilities. All of them are recreated in your project.

Publishing a blueprint

Publishing is a superadmin action, done from Studio against a real asset in a real project.

Publish the source to the Hub first

Only a Hub-published version can be snapshotted. The whole point is that a blueprint ships something known-good, not a work in progress. If the workflow calls child workflows that aren't published, publishing is blocked with the exact list: "Publish these child workflows to the Hub first: …"

Open the publish dialog

On a use case card, the menu offers Publish as Blueprint (or Republish Blueprint if it's already listed). Agents are published from the agent card's publish action. Only library agents can be published.

Write the listing

Fill in the catalog metadata:

Name (required): up to 255 characters
Short description (required): one line shown on listing cards, up to 160 characters
Category (required)
License: MIT, Apache 2.0, Proprietary, or Custom
Long description (optional): full Markdown with a live preview, plus uploaded images, documents, and video, or an embedded YouTube / Vimeo / Loom URL

Publish

The snapshot is exported, sanitized, checked against the publish guards, and stored. From that moment the listing is frozen: editing the source workflow changes nothing until you explicitly republish.

What sanitizing removes

Before a snapshot is stored, the same strippers that run on any workflow export are applied, removing knowledge base ids, LLM configuration ids, MCP connection ids, and connection hints, and the result is scanned for secret patterns. For a Super Agent, the per-node list of disabled capabilities is stripped too, so the listing carries the workflow's structure, never one project's environment.

Publish guards

A publish is refused if any of these are true:

Guard	Limit
A secret or API-key pattern is detected in the snapshot	Blocked, naming the field
The exported snapshot is too large	5 MB
The workflow has too many activities	100
An identical snapshot is already listed for this organization	Blocked as duplicate content
A referenced child workflow isn't Hub-published	Blocked, naming the workflows
The agent isn't a library agent	Blocked

The duplicate check hashes the content itself, ignoring the export timestamp. That's what makes a republish with no real changes a no-op instead of a second identical listing.

Republishing, editing, and removing

Action	Effect
Republish	Refreshes the snapshot from the current source. The listing's link stays the same, so anyone who bookmarked or shared it still lands in the right place.
Edit details	Changes display metadata only: name, descriptions, category, license, media. No re-snapshot, and it works even if the source asset is long gone.
Delete	Soft-deletes the listing so it disappears from the catalog. Existing grabs are unaffected, because they're independent copies.

A Super Agent blueprint's content hash depends on the whole project's published state, because its callable capabilities are part of what gets bundled. Publishing an unrelated workflow in the same project can therefore change the hash, which means a republish that looks like a no-op may not be one.

Media in a listing

Long descriptions carry more than text, because a blueprint often needs a walkthrough:

Kind	Formats	Size limit	Behaviour
Image	PNG, JPG, WebP	2 MB	Rendered inline
Document	PDF, DOC/DOCX, XLS/XLSX, CSV, PPT/PPTX, TXT, ZIP	25 MB	Downloads when clicked
Video	MP4, WebM, MOV	200 MB	Streamed with seek support

Hosted videos need no upload at all. Paste a YouTube, Vimeo, or Loom URL on its own line and it becomes a sandboxed embed.

Uploads are superadmin-only and validated by inspecting the file's actual bytes rather than trusting the declared type; SVG, HTML, and executables are rejected outright. Because a blueprint's images and video have to load for viewers in every organization, the files themselves are served publicly, so don't put anything confidential in listing media.

Who can do what

Action	Required access
Browse listings, view detail, preview	Any signed-in user
Preview a grab and grab into a project	Write access to the target project
Publish, republish, edit details, delete, upload media	Superadmin

Limitations today

Public visibility only. Every published blueprint is visible platform-wide. Organization-only listings are reserved for a later phase.
Publishing is superadmin-only. Organization-level publishing isn't available yet.
No moderation queue. There's no review or rejection workflow; a published listing is live immediately.
Snapshots don't auto-update. A blueprint reflects the source as of its last publish or republish, by design.