The Fibric platform

One operational layer for the physical world.

A building panel here, an order book there, sensors nobody reads until it is too late. Fibric sits across all of it: one live model that senses every system at once, reasons about what is coming, and acts to fix it before it lands on a customer. Governed, every step.

Get early access → See the loop

One kernel for all of it. A chiller, an open order, a door sensor, a support queue.

The control loop

Sense, reason, act. One loop that never stops closing.

01 / SENSE

Unify everything into one picture

Your operation already produces data. The problem is that it lives in a dozen systems that do not talk to each other. Fibric connects to each one and folds it into a single live model of what you run: the same picture for a chiller, an open order, a door sensor, and a support queue.

Reads software systems and physical devices through the same connector model.
Normalizes everything into one canonical event so nothing is special-cased.
Real data only. A placeholder can never enter as a measurement.

02 / REASON

Understand, predict, and plan

A base model reads the live picture and works out what is happening, what is about to happen, and what to do about it. It plans multi-step action and resolves conflicts up front, so two fixes never fight each other, and a problem gets caught before it reaches a customer or a floor.

Predicts needs and risks instead of waiting for an alarm.
Plans across systems. One intent can touch HVAC, an order, and a team.
Proposes a validated plan; it never acts on its own conclusion.

03 / ACT

Take the action, leave a receipt

A deterministic executor carries out the plan: it controls systems, dispatches a team, holds an order, opens a ticket. No new hardware is required; Fibric acts through the systems you already run. Every step is logged and explainable, and the result feeds straight back into sense, so the loop closes.

Acts through existing systems: control, dispatch, notify, ticket.
Single-flight and idempotent, so an action can never run away.
Every step leaves a receipt you can read later and trust.

The loop, closing

1event shape

Sense

A chiller and an open order land in the same envelope. Nothing is special-cased.

657to 0

Single-flight

One entity, one action in flight. The 657-message flood becomes structurally impossible.

0new boxes

Act

Fibric acts through the systems you already run. Nothing to rack, nothing to install.

100% receipted

Audit

Every step logs what it saw, what it proposed, the gate it cleared, and what it did.

Operators

Named AI workers that run one operation, end to end.

An operator is a worker you put in charge of one thing. It owns the full loop for its job: it watches the systems that matter, reasons about what they mean, and acts inside the bounds you set. You hire operators the way you hire people, for a role, not for a vertical. One kernel runs every one of them.

Live today · JAM+ tenant

Order Risk

a paper & print company

Watches the order book, the proof-approval queue, and production status. It scores every open order for the chance it slips its ship date, and it does that upstream of the carrier scan, while there is still a day to fix it. When one is about to go wrong it holds the order, chases the proof, or escalates to the account owner before the customer ever asks where it is.

Senses: Magento · proofs · productionReasons: which order slips, and whyActs: hold · chase · escalate

OPR

Comfort & Energya hotel

Reads occupancy, weather, and the building's own systems, then tunes air, light, and access to the rhythm of arrival and rest. A guest walks into a warm room; an empty wing is not heating itself at 2am. It learns the day instead of running a fixed schedule.

BMS · occupancy · weathersetpoints · lighting · access

OPR

Floor Flowa warehouse

Reads every station, lane, and exception, and works out where flow is about to break: a stalled station, a pile-up, a late inbound. The moment a station stalls it reroutes the work, reschedules the slot, and tells the floor, so one exception never freezes the whole line.

WMS · stations · inboundreroute · reschedule · notify

Three operators, three industries, one kernel. Proof of reach, not the whole menu.

Open the marketplace →

The same loop, any floor

The operator does not know it is a warehouse.

It reads stations and inbound, it works out where flow is about to break, it reroutes a lane. Swap the warehouse for a hotel or an order book and the kernel underneath is byte-for-byte the same. The vertical is just which connectors you plugged in.

✓ Real data only · every action vetted before it runs

Connectors & capabilities

Plug into the real world. Swapping a system is config.

Ticketingcapability

→

KustomerZendesk

Commercecapability

→

MagentoShopify

Building controlcapability

→

BACnetNiagara

Voice & contactcapability

→

Amazon Connect

An operator asks for “ticketing,” not for Kustomer. Fibric routes the request to whichever connector you have installed. The day you move from Kustomer to Zendesk is a config change, and every operator keeps running.

Capability over connector

An operator never names a vendor. It asks for a capability, like "ticketing", "building control", or "commerce", and Fibric routes that to whichever connector you have installed. The day you move from one system to another, you swap the connector and every operator keeps working. No vendor is ever hardcoded into the platform.

Built on MCP

Connectors are integrations, and integrations are MCP. Software systems, physical devices, and operators all plug in through the same model, so a sensor and a SaaS API are first-class in exactly the same way. If it speaks MCP, Fibric can sense it and act on it.

No new hardware

Fibric acts through the systems you already run. There is no box to install and no rip-and-replace. You connect what you have, set what you want, and the operators work within it.

Browse integrations →

The governed engine

The model proposes. A deterministic executor disposes.

Governance is not a setting you turn on. It is the shape of the engine. A base model reads the world and suggests what to do, but you would never let it act on its own judgment. So it never does. It proposes a plan, and a deterministic executor, code you can read with rules you set, decides whether and how that plan runs.

The model

Proposes

Reads the live picture and returns a validated ExecutionPlan: a sequence of steps, each one explicit. It suggests; it does not decide.

policy gate→fail-closed

The executor

Disposes

Validates every step against your policies, then runs only what passes. A rule you set can veto anything before it ever happens.

Fail-closed policy

A rule can veto anything

You write the policies. If a proposed step would break one, it is stopped before it runs, not flagged after. The default is to do nothing, never to guess.

Single-flight + idempotency

A runaway action is impossible

One entity, one action in flight at a time, every action carrying an idempotency key. A retry can never become a second send. The "657-message flood" is structurally impossible, not policed.

Walled-off tenancy

Your data is provably isolated

Every event and every row carries a tenant_id. Isolation is enforced at the data layer, not hoped for in application code. Nothing of yours touches anyone else's.

Full receipts

Every action is explainable

Each step the executor runs is logged with what it saw, what it proposed, what passed the gate, and what it did. You can always answer "why did it do that" with the record, not a guess.

Read the trust spine →

Studio

Point and go. Say what you need in plain words.

For the people who run the place

You should not need to be technical to put an operator to work. In Studio you connect a system, say what you want in plain language, and watch the plan before anything runs. The model turns your intent into a step-by-step plan; you approve it; the executor does the rest and hands back a receipt.

Connect a system in a few clicks, no integration project.
Describe the outcome you want, not the steps to get there.
See the proposed plan, approve it, and keep the receipt.
Set the policies once; every operator stays inside them.

Start in Studio →

Studio · new intent

Hold any order that won't ship on time, and tell the owner why.

1Read open orders and production statussense

2Score each order's risk of missing its datereason

3Place a hold on at-risk ordersact · vetted

4Notify the account owner with the reasonact · vetted

Receipt #4471 · 4 steps · 0 vetoed Approve & run

Built on Fibric

The first product is already running on real orders.

BearScope · a paper & print company

It catches the order before the carrier scan ever does.

BearScope is the first product on Fibric, live on a real paper and print company today. The Order Risk operator watches the order book and the proof queue, scores what is about to slip, and acts upstream of the carrier while there is still a day to fix it. Same kernel as the hotel and the warehouse. Only the connectors change.

.82

SO-48117 Mercer Dental

Carrier not scanned 26h past pickup · ships tomorrow

Hold + notify

.61

SO-48140 Halcyon Press

Stock short 1,200 of 2,000 on hand

Split ship

✓ Real data only · every action vetted · receipt on dispatch

See BearScope →

Early access

Bring reason to what you run.

Tell us what you operate. We onboard the operation, not sell you a tool.

Real data only. Every action checked before it happens.