Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 07 · LESSON 7.1

Create a canonical blueprint

Provision the cooperating agents from one canonical blueprint.

Lesson 39 of 86 · FabrCore 2.0

Overview

FabrCoreBlueprint describes the application baseline. Bare handles let the same definition be applied for different principals. Extensions such as squads and connectedAgents belong in the canonical document, not a separate agents-only compatibility DTO.

A canonical definition describes a workspace

A blueprint collects the agent definitions your product wants for one principal: handles, registered types, model aliases, plugins and arguments. Reusing bare local handles lets the same definition create dev:assistant and another user's assistant under their respective owners. It is data describing desired instances, not an assembly containing their implementations.

Storing and applying are different steps

Saving a named blueprint makes it available for later deployment. Applying expands its definition and attempts the corresponding agent operations. Neither putting a file beside the Host nor starting the process necessarily applies every blueprint to every user. Choose the application event that provisions the workspace, such as first sign-in, and inspect its results.

Write and apply the blueprint

  1. Create ops-desk with the assistant and specialist definitions, named models, plugin selections and Args. Keep credentials out of the document.
  2. Store a named blueprint through /fabrcoreapi/Blueprint or apply a canonical document directly through /fabrcoreapi/Agent/blueprint.
  3. Apply from trusted application bootstrap, such as first sign-in. Host startup does not automatically reconcile all blueprints for all principals.
ops-desk.json · canonical blueprint using the module 6 class 
{
  "name": "ops-desk",
  "version": "1.0.0",
  "agents": [
    {
      "handle": "researcher",
      "agentType": "researcher",
      "models": "default",
      "plugins": [
        "requests"
      ],
      "args": {
        "_HarnessDefaultMode": "plan",
        "_HarnessLoop": "todo"
      }
    }
  ]
}
Apply the file · trusted localhost exercise 
Invoke-RestMethod -Method Post -Uri http://localhost:5098/fabrcoreapi/agent/blueprint -Headers @{ "x-user-handle" = "dev" } -ContentType "application/json" -InFile ./ops-desk.json

Compare definition and created instances

  1. Use the example with an installed agent alias and available model alias. Apply it to a disposable principal and inspect each creation result.
  2. List/read the principal's resulting agents and compare their local handles, type aliases and model selections with the definition. Every intended target should be accounted for.
  3. Apply an ensure operation again. Confirm existing instances are not duplicated and remember that this does not prove changed fields were updated on them.

The result establishes repeatable workspace provisioning. It does not make the blueprint a continuous reconciler that deletes or updates every drifted instance automatically.

If the result is different

Preserve unknown top-level extensions when editing/cloning JSON. Agents-only compatibility helpers cannot represent extension-aware workflows.

Go deeper

Explore the related documentation.