Build on the operational layer for the physical world.
Fibric is agentic AI for anything you run, a building, a warehouse, a paper company's orders. It senses every system, reasons about what is happening, and acts safely, governed by default. These docs show you how to connect a system, define an operator, set a guardrail, and read the receipt for every action it takes.
What Fibric is
Most automation lives inside one screen. Fibric brings reasoning out of the screen and onto the things you actually operate. You point it at the systems you already run, tell it the outcome you want in plain language, and it does the work, end to end, while a policy you set keeps every action in bounds.
Two readers use these docs. Operators run real spaces and operations and want to point and go without writing code. Builders extend Fibric with new operators and connectors and want the SDK, the CLI, and the API. The mental model below is the same for both.
Unify real-time data from every siloed system into one operational picture.
Models understand what is happening, predict what is needed, and plan multi-step action.
Control systems and dispatch teams, then leave a receipt for every step.
The mental model
Five pieces fit together. Learn these five and the rest of the docs read easily.
- Connectors plug Fibric into the systems you already run, software like a help desk or an order system, and hardware like sensors, locks, or HVAC. Every connector is built on MCP, so the same shape works everywhere.
- Capabilities are what a connector can do, stated by intent rather than by vendor. An operator asks for the capability
orders.hold; which connector fulfills it is configuration, so swapping one vendor for another is a config change, not a rewrite. - Operators are named AI workers that run an operation. An operator senses through connectors, reasons with a base model, and proposes action.
- The executor is deterministic. The model only ever proposes a validated plan; a deterministic executor disposes, checking it against your policy and running it once, in order, idempotently.
- Receipts record every action, its inputs, the policy decision, and the outcome, so anything Fibric did is logged and explainable after the fact.
Fibric only ever works on real data, a placeholder can never pass as a metric. Every action is checked against a fail-closed policy before it happens: the model proposes, a deterministic executor disposes. Tenant data is provably walled off, and every action leaves a full receipt.
Where to start
Pick the path that matches what you are doing today.
defineConnector, expose typed tools, and wire auth.
Open →
Reference
API reference
The REST API for envelopes, plans, runs, and receipts, with method badges, parameter tables, and request and response examples.
Open →
Build
CLI
Install, log in, connect a system, deploy an operator, tail receipts, and manage policy from your terminal.
Open →
How these docs are organized
The left rail follows the order you will need things. Get started takes you from zero to a first action. Concepts explains the model so the rest makes sense. Build is the hands-on reference for extending Fibric with code. Reference is the exhaustive API and the changelog.
Code blocks are copyable, every heading has a stable anchor, and you can flip the whole reference to a light theme with the toggle in the top bar. If you only read one page first, read the quickstart, it grounds every concept in something you can run.
Do the quickstart with a sandbox connector first. You never touch a live system, but you see the full loop, sense, reason, propose, dispose, receipt, in about ten minutes.