Blueprints and the marketplace

Inspect before installing

The list names required integrations, required Context keys, and the tables, columns, and disabled automation a system creates. An agent reads that list and then builds the workbook itself. It does not install the system.

Use the preflight result

Resolve every missing integration or Context key before you install. Check the proposed tables, columns, and disabled automation in the preflight output, then verify that the installed objects appear in the workspace. A disabled workflow is a draft, not a running automation.

When it goes wrong

If preflight reports a missing integration or Context key, correct that prerequisite and run preflight again. If the proposed system does not match the job, choose a different blueprint or use a recipe for a fixed worksheet kit.

If preflight reports a missing integration, connect the provider only when the workspace intends to use it. Do not create a connection merely to make a catalog item appear complete when its provider action is not needed yet.

If preflight reports a missing Context key, write the underlying factual document with its source rather than inventing a value to satisfy the prerequisite. Then re-run the free preflight.

If the object plan conflicts with existing work, stop before installation. Compare another blueprint, use a fixed recipe, or choose an advisory play when the request is a workflow of decisions rather than an installed system.

If an install fails after state changed, read the returned receipt and current workspace objects before retrying. A retry should use the exact known contract and should not duplicate tables or columns without inspection.

A successful blueprint workflow has a reviewed preflight, fulfilled prerequisites, a deliberate installation, and visible resulting objects. It is not complete merely because an agent found a catalog title.

The preflight result is a concrete object plan, not a generic recommendation. Preserve it while resolving a prerequisite, then compare the refreshed result with the intended workspace outcome before installation.

If the object plan changes, review the tables, columns, and automation again. A preflight can only describe the current workspace state and selected catalog system.

Inspect the system

A blueprint is an installable workspace system from the blueprint catalog. It can create worksheets and columns, and some systems include a disabled workflow rather than a running automation.

Blueprint operations also support saved workspace snapshots that can be shared or listed on the marketplace. A snapshot is not an advisory play and should be inspected as a concrete workspace system.

workspace.blueprints.list is a free read that lists shipped installable systems and their requirements. Read the catalog before selecting a system so its requirements are part of the decision.

workspace.blueprints.describe is a free read for one shipped system or saved workspace snapshot. Use it to see the selected system rather than inferring its created objects from its title.

The product UI installs a shipped blueprint. An agent does not. Build the workbook, source, and columns with tables.workbooks.create, tables.table_sources.attach, and tables.columns.add.

A blueprint can name required integrations and required Context keys. A missing integration or Context key is a prerequisite result, not evidence that the install operation or the system itself is broken.

Preflight identifies proposed tables, columns, and disabled automation. Check every proposed object against the workspace’s existing structure before installation, especially when a similar workbook or workflow already exists.

Context requirements refer to durable workspace knowledge. Record product, buyer, competitor, or voice facts in Context, then use the required keys supplied by the selected system.

External provider connections belong to Integrations. Building a blueprint can proceed until a connection is needed, but a provider-dependent run or send can be blocked until the workspace connects the required provider.

A disabled workflow is a draft. It does not begin running, sending, enrolling, publishing, or spending merely because the blueprint installed its configuration.

Install and verify

Installation is a state-changing operation. Fetch the exact install schema, choose an explicit supported mode, and inspect its cost policy before a live run rather than assuming that a free preflight makes installation free.

smoke_test inspects static schema and policy without a write or audit record. dry_run previews against real workspace state without business writes, provider spend, or outward actions; live executes the selected supported operation.

A capability’s catalog cost policy and credit class determine cost. When a live call needs a quote, use the returned estimate and rerun unchanged parameters with the max_credits ceiling the caller accepts.

Architect can use a blueprint as a plan, but it must still search and fetch each exact capability contract. The blueprint does not grant permission or skip the workspace, mode, or credit checks.

After installation, inspect the created workbook, worksheets, columns, and disabled workflow in the app. Keep the returned ids as the source of truth and use a web_url, when present, to reach the precise object.

Use the preflight as a comparison artifact, then verify the actual workspace objects after installation. A disabled workflow remains a draft until a separately chosen activation action runs.