Blueprints: A Predictable Baseline for Every Principal's Agents
Every serious agent application eventually has a first-five-minutes problem. A new tenant arrives, a user opens a workspace, or a customer completes sign-in—and now the system needs the right agents, tools, prompts, and integrations. FabrCore Blueprints make that moment explicit: describe the baseline once, then safely ensure it for each principal.
The Provisioning Question That Kept Reappearing
Creating agents one at a time works until a workspace needs an assistant, an analyst, an intake agent, and a specialist with a particular plugin configuration. Every caller then has to answer the same questions: Is this agent already there? Is it configured? Should I overwrite it? What happens if the third of four agents fails?
A Blueprint turns that into one intent: ensure this principal has this baseline set of agents. It is a named, version-tagged wrapper around familiar AgentConfiguration objects. The important word is ensure, not recreate.
What a Blueprint Is—and Is Not
Blueprints are a request-time provisioning manifest. They describe the agent handle, agent alias, model, system prompt, plugins, tools, event streams, MCP servers, and arguments an application wants for one principal.
Starting a FabrCore Host does not cause it to enumerate every principal and run a Blueprint. Your application owns that decision and calls the endpoint at the boundary that makes sense—typically tenant creation, first sign-in, or workspace initialization.
The Developer Experience: Keep the Baseline Near the Product
Blueprints introduce no parallel configuration language. Developers already know AgentConfiguration; put those configurations in the application service that owns workspace provisioning and send them through the typed Host API client:
var blueprint = new AgentBlueprintRequest
{
Name = "support-workspace",
Version = "2026-07",
Agents = [new AgentConfiguration
{
Handle = "assistant",
AgentType = "chat-agent",
Models = "default",
SystemPrompt = "Triage support work and explain the next step.",
Plugins = ["Tickets"]
}]
};
var result = await hostApi.EnsureBlueprintAgentsAsync(principalHandle, blueprint);That fits naturally behind an onboarding endpoint or sign-in hook. Calling it again stays safe: FabrCore checks the tracked agent's health rather than treating every invocation as a command to rebuild it.
The Admin Experience: Repeatable Without Surprise Resets
For administrators, Blueprints make standardization safe. Decide that every support workspace begins with an assistant and analyst, then let the application ensure that baseline for every principal. You do not need a custom list of already-provisioned tenants just to avoid duplicate creation.
A tracked agent that is healthy, degraded, or unhealthy returns its current health without being intentionally reconfigured. A tracked agent that has become NotConfigured is configured again from the Blueprint. New agents are configured and added to the principal's tracked list.
The response contains an AgentHealthStatus for every requested agent. A failed agent does not stop FabrCore from attempting the remaining agents, so operators get a complete picture instead of a partial mystery.
Scope Is Deliberate
The target principal comes from x-user-handle. A bare handle such as assistant becomes acme-42:assistant for principal acme-42. Fully-qualified handles are accepted only when they carry the same principal prefix; a Blueprint cannot quietly use this endpoint to provision another principal's agents.
That makes the request a clean administrative boundary: one call provisions one principal's baseline. It also makes the natural multi-tenant pattern straightforward—run the same Blueprint independently for each tenant or workspace principal.
Blueprints and Upgrades: Add Safely, Change Intentionally
The Name and Version fields are for your application's traceability. FabrCore echoes them in the response, but it does not persist them as a template catalog, compare versions, or delete agents that a newer manifest no longer mentions.
Adding a new baseline agent is an excellent Blueprint use case. Changing an existing agent's prompt, tools, model, or configuration is a deployment decision. For that, use POST /fabrcoreapi/Agent/create and explicitly opt into reconfiguration with ForceReconfigure. To remove an agent, use the delete endpoint.
| Intent | Operation |
|---|---|
| Ensure a standard baseline exists | POST /fabrcoreapi/Agent/blueprint |
| Deliberately update an existing agent | POST /fabrcoreapi/Agent/create with ForceReconfigure |
| Remove an agent | DELETE /fabrcoreapi/Agent/{handle} |
A Small Feature With a Better Default
Blueprints do not try to automate every lifecycle decision. They give developers an obvious place to declare the agents a product needs, and they give administrators an idempotent, observable way to apply that declaration principal by principal. The result is a more predictable start for every workspace—without turning normal login traffic into an accidental configuration migration.
Start with a small baseline, call it at the principal-creation boundary, inspect the health results, and make configuration changes deliberately. That is enough structure for a single application today and the right operating model when the same application is serving hundreds of principals tomorrow.
Build a Reliable First Run
Read the Blueprint documentation for the request contract, lifecycle behavior, and SDK example.