Environments

Operators take real actions on real systems, so the line between trying something and running it in production deserves more care than a config flag. Fibric gives you three composable tools for that line: sandbox connectors that simulate a system, workspaces that partition work inside a tenant, and separate tenants where you need the full isolation wall. Promotion is deliberately boring: the operator and its guardrails do not change; what changes is which connector fulfills each capability.

#Three levels of separation

These compose. A common arrangement for a team shipping its first operator: one tenant, a staging workspace whose capabilities are bound to sandbox connectors, and a production workspace bound to the real systems. Teams with regulatory or organizational pressure for a harder wall run staging as its own tenant instead, at the cost of maintaining two sets of connector installations.

#The sandbox is the same machinery

A sandbox connector is not a mock of Fibric; it is a real connector whose tools act on a simulated system. The governed loop is identical: the operator proposes, the trust gate disposes, single-flight and idempotency apply, and every action is receipted. This matters because what you are testing in an agentic system is mostly not the side effect itself; it is the proposals your operator makes and the policy that gates them, and both are exercised fully against a sandbox.

# bind the orders capability role to the sandbox
fibric connectors add sandbox-orders --as orders

$ fibric connectors list
ROLE     CONNECTOR        STATUS
orders   sandbox-orders   ready

# the operator, its trigger, and its guardrails are written against "orders",
# with no knowledge of which connector stands behind the role

Sandbox connectors declare auth: none(), so no real credential exists in the sandbox path at all, the strongest possible form of key separation for development. For repeatable local testing against recorded traffic, fibric dev replay re-runs event fixtures through your operator; see Testing connectors and the CLI reference.

#Workspaces as environment boundaries

A workspace is a tenant-scoped partition: workspace_id travels on every envelope and every row, and operators, event queries, and stream subscriptions can all be scoped to one. Using workspaces as environments means your staging traffic and production traffic live in the same tenant but never mingle in a view, a trigger, or a consumer:

• Ingest staging events with the staging workspace_id; operators registered in that workspace see only them.
• Filter dashboards and stream consumers by workspace_id, so a staging burst never pollutes a production chart.
• Receipts carry the workspace, so an audit of production actions excludes rehearsals cleanly.

#Promoting configuration

Because operators request capabilities rather than naming connectors, promotion is a rebinding, not a rewrite. The operator definition, its trigger, its prompt, and its guardrails are byte-identical in both environments; the only thing that changes is which connector fulfills each capability role.

1. connectors   install the real connector and bind it to the same role
                  fibric connectors add cn-magento --as orders
                verify:  fibric connectors test orders
2. guardrails   review policies against real value: maxValue ceilings,
                which tools ALERT. Tighten before first production run;
                loosen later with evidence from receipts.
3. operator     create/resume the operator in the production workspace,
                same definition, same trigger
4. watch        fibric receipts tail — confirm first dispositions look right
5. rollback     fibric operators pause <id> stops new proposals instantly;
                already-executed actions are receipted and, where the tool
                declares an inverse, undoable

Step 2 deserves the emphasis. The sandbox will happily approve a $10,000 refund because sandbox money is free; production guardrails should make that an ALERT or a BLOCK. A sound pattern for a newly promoted operator is to set ALERT on every side-effecting tool for the first week, approve through the Actions & plans API or console, and convert to ALLOW per tool as the receipt history earns it. Trust is granted with evidence, not assumed with deployment.

#Key separation

Environment separation is only as good as the separation of the secrets that reach each environment.

Continue with Tenancy & isolation for what the tenant wall enforces, Secrets and credentials for credential lifecycle, and the quickstart to run the whole sandbox loop in about ten minutes.