Quickstart

Go from an empty account to a live operator that takes a real, governed action, then read the receipt that proves what it did. Five steps, about ten minutes. You can run the whole thing against a sandbox connector first, so no live system is ever touched until you say so.

Create a workspace from the Marketplace or with the CLI. A workspace is your tenant, its data is provably walled off from every other tenant from the first row written. Grab an API key from Settings → API keys and export it so the CLI and SDK can use it.

# export the API key from Settings → API keys
export FIBRIC_API_KEY="sk_live_…"
export FIBRIC_WORKSPACE="acme-ops"

The CLI drives your workspace from the terminal; the SDK is how you define operators and connectors in code. Install both, then confirm the CLI can reach your workspace.

# global CLI + project SDK
npm install -g @fibric/cli
npm install @fibric/sdk

# confirm the CLI sees your workspace
fibric whoami

A connector plugs Fibric into a system you already run and is built on MCP. For the quickstart, connect the sandbox order system, it speaks the same capability interface a real order system would, so nothing about the rest of the quickstart changes when you later swap it for the real thing.

# browse what is installable, then add the sandbox order system
fibric connectors search orders
fibric connectors add sandbox-orders --as orders

# confirm the capabilities it now exposes
fibric capabilities ls

Notice that you bound the connector to the role orders. Operators ask for the capability orders.hold, not for a vendor by name. That indirection is what makes swapping one order system for another a config change rather than a rewrite.

An operator is a named AI worker that senses through connectors, reasons with a base model, and proposes action. It never acts directly. A guardrail is the policy your deterministic executor enforces before any proposed action runs, fail-closed, so anything the policy does not explicitly allow is refused.

Create operator.ts. This operator watches orders and proposes a hold on any order that will miss its ship date.

import { defineOperator } from "@fibric/sdk";

export default defineOperator({
  name: "ship-risk",
  // what the operator is allowed to ask for
  capabilities: ["orders.read", "orders.hold", "orders.notify"],
  goal: "Hold any open order that will not ship on time, and notify the owner.",

  async sense(ctx) {
    return ctx.orders.read({ status: "open" });
  },

  // the model REASONS over what it sensed and PROPOSES a plan.
  // it returns proposed actions, it never executes them itself.
  async reason(ctx, orders) {
    return ctx.propose(orders
      .filter(o => o.willMissShipDate)
      .map(o => ({ capability: "orders.hold", args: { id: o.id } })));
  },
});

Now the guardrail. Policy is the deterministic half of the loop, it disposes of what the model proposes. This one allows holds and notifications but caps how many orders a single run can touch, so a runaway plan is structurally impossible.

# fail-closed: anything not allowed here is refused
version: 1
allow:
  - orders.hold
  - orders.notify
limits:
  orders.hold:
    max_per_run: 25      # cap the blast radius of any one run
    single_flight: by_order_id   # one in-flight action per entity
require_receipt: true

Deploy the operator and attach the policy in one command.

fibric operators deploy ./operator.ts --policy ./policy.yaml

Run the operator once and tail its receipts. Each receipt is the immutable record of one action: what was proposed, the policy decision, and the outcome. This is what makes everything Fibric did logged and explainable after the fact.

# run the operator once, then stream its receipts
fibric operators run ship-risk --once
fibric receipts tail --operator ship-risk

Open any receipt to see the full record, the envelope that triggered it, the proposed plan, the policy evaluation, and the idempotency key that guarantees the same action is never applied twice.

fibric receipts show rc_5b21 --json

{
  "receipt_id": "rc_5b21",
  "tenant_id": "t_8f2a…c901",
  "operator": "ship-risk",
  "capability": "orders.hold",
  "proposed_by": "model",
  "policy": { "decision": "allow", "rule": "orders.hold" },
  "idempotency_key": "ship-risk:SO-10884:hold",
  "outcome": "applied",
  "at": "2026-06-14T09:02:11Z"
}

#What just happened

You ran the full Fibric loop. The operator sensed through a connector, reasoned over what it saw and proposed a plan, and the deterministic executor disposed of that plan against your fail-closed policy, applying each action once, idempotently, and leaving a receipt for every step. That is exactly the shape a production operation runs in, the only thing that changes is you swap the sandbox connector for a real one.

#Next steps

• Core concepts, the event envelope, propose and dispose, single-flight, idempotency, and receipts in depth.
• SDKs, define your own connector with defineConnector and expose typed tools.
• Governance & trust, write richer fail-closed policies and read receipts in production.
• API reference, drive envelopes, plans, runs, and receipts over REST.