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 13 · LESSON 13.4

Manage principals, access, agents, and blueprints

Manage agents and access with capability discovery and conditional writes.

Lesson 77 of 86 · FabrCore 2.0

Overview

Remote management uses vendor-neutral administration contracts. Operations target a principal/environment and may return partial results. Revisions prevent one operator silently overwriting another's reviewed change. Diagnostic questions and business test messages are separate workflows.

Discover before rendering controls

GET /fabrcoreapi/admin/v1/capabilities advertises installed administration features, and authenticated openapi.json describes the routes/schemas. A Cloud Server should authorize the operator for the cluster and establish actor attribution from that authenticated identity before relaying a request. The target principal and local agent handle belong in the documented route, not in an untrusted actor header.

Operations return receipts, not instant fleet truth

A management action can be asynchronous or partially successful. Stable operation IDs and conditional revisions let the client inspect the outcome it actually submitted. A timeout is an uncertain response, not proof the Host did nothing. Reconcile its receipt before issuing another side-effecting operation under a new ID.

Manage a target through administration APIs

  1. Discover capabilities before showing actions. Use FabrCoreAdministrationClient or the environment screens to query principals, agents, ACL and blueprints.
  2. Read the resource revision, preview where supported, then submit create/update/apply or lifecycle operations against that version.
  3. Inspect operation status and per-target results. Reload on conflicts and distinguish unavailable features from an empty data set.
Discover contracts and read a target before changing it
GET /fabrcoreapi/admin/v1/capabilities
Authorization: Bearer <administration-credential>

GET /fabrcoreapi/admin/v1/openapi.json
Authorization: Bearer <administration-credential>

GET /fabrcoreapi/admin/v1/principals/dev/agents/researcher/configuration
Authorization: Bearer <administration-credential>
Submit a conditional configure operation · preserve the current configuration
PUT /fabrcoreapi/admin/v1/principals/dev/operations/tune-researcher-001
Authorization: Bearer <administration-credential>
Content-Type: application/json

{
  "kind": "configure",
  "agentHandle": "researcher",
  "management": {
    "revision": "<revision-from-read>",
    "configuration": {
      "handle": "researcher",
      "agentType": "researcher",
      "models": "default",
      "plugins": ["requests"],
      "args": { "_HarnessLoop": "todo", "_HarnessLoopMaxIterations": "4" }
    }
  }
}

GET /fabrcoreapi/admin/v1/principals/dev/operations/tune-researcher-001
Authorization: Bearer <administration-credential>

Read, change and reconcile one instance

  1. Discover capabilities and read a disposable agent's configuration/revision. Show the intended target principal and local handle to the operator.
  2. Submit a supported reviewed action against that revision and poll the corresponding operation receipt. Inspect per-target outcomes and read the resulting configuration back.
  3. Test a stale revision and a lost-response scenario. Expect a conflict for the former; for the latter retrieve the existing receipt rather than blindly resubmitting the action.

This is the Cloud Server's management workflow regardless of which UI it presents: discover, read, review, submit conditionally and reconcile the result.

If the result is different

Do not infer fleet-wide success from one successful silo response. Avoid treating a remote timeout as proof the operation never executed.

Go deeper

Explore the related documentation.