Every model call, on the rails.
Fabric is the runtime under every Celara solution. Each agent runs as a graph, and each model call is a node run in that graph. Every node run is held to your constitution, your model allowlist and your budget. Runs survive restarts, stop at eval gates and wait for people when a decision needs one.
Three checks on every node run. No agent runs off them.
The rails apply to solutions you install from the marketplace, graphs you build in Studio and calls your developers make through the MCP server. Nobody has to remember to turn them on.
Your constitution
The articles bound to the work apply to every node run. Agents can read them while they work. After each run, the output is screened and the findings go to the evidence ledger with quoted excerpts.
Your model allowlist
Each organization lists the models it allows and sets a tier for each graph. A call to a model outside the list does not run. You use your own model keys.
Your budget
Work is metered in work units. Set budgets per organization, team or graph, with alerts and a soft limit. At the hard limit, runs fall back to economy models.
Agents, graphs, skills and tools. Versioned, owned, reviewed.
Everything an agent is made of lives in one catalog. Every item has an owner, a status and a version history. Validate a change, promote it, roll it back, or clone it for another team.
Say what it should do. Studio drafts the graph.
Describe the work in one sentence. Studio asks what it needs to know, shows you the plan and builds the graph on the canvas while you watch.
How Origin and Studio work →A replay of Studio. Someone asks for a check on every new client. Studio asks which risk level needs a person, shows a four-step plan and builds the graph: sanctions, adverse-media and ownership screens, a risk score, and a compliance officer for doubtful cases. A test run with a sample client stops at the compliance officer.
Graphs with a status, a mode and a history.
An agent graph wires agents, tools, eval gates and approval steps together. You can always see which version is running and what changed.
The revenue-review agent graph: active, structured one-shot, 7 nodes, version 2. A version 3 draft adds a critic node before the merge and an approval step before sending. It is validated and promoted, so version 3 is live and version 2 is kept, ready for a rollback.
Every agent has an owner.
Each agent lists its version, its status, its owner and the skills, tools and graphs it uses. Changes go through review before they reach production.
The sql-explainer agent, version 3.18.1, owned by Genevieve Raynor, with 5 skills, 4 tools and 12 graphs. A change to version 3.19.0 is proposed and a review is requested. Genevieve approves it, and only then does it reach staging and then production.
Write a capability once.
A skill packages how to do one thing well. Every agent that uses it gets the same reviewed behavior, and an update reaches all of them.
The evidence-and-provenance skill is updated from version 1.0.0 to 1.1.0, adding a source check before any claim is returned. The update reaches all 10 agents that use it, until 10 of 10 are updated.
Tools with their access on record.
Each tool shows its protocol, how it authenticates and which agents can call it. Tools reach your systems of record, such as your CRM, ERP and document stores.
The crm-lookup tool, version 4.19.12, over MCP with OAuth, linked to three agents. Onboarding-guide, a linked agent, calls it and is allowed. Ticket-triage, which is not linked, calls it and is refused because it is not on record for this tool. Both calls are logged.
Try a graph before you publish it.
Run a draft graph against sample inputs, watch each step and compare versions. Playground runs use the same rails as production.
A draft of the feature-build graph, version 4, runs on a sample input in the playground. Its four steps run one by one: plan, two implementers and synthesize. It is compared with the published version 3: the same four steps, fewer tokens and a shorter run. It is ready to publish, and it ran on the same rails as production.
Runs that finish. Even when a machine doesn't.
Every run is durable. If a worker restarts mid-run, the run resumes at the step where it stopped. Retry from any step, cancel, stream it live or run it in batches.
Single turn
One request, one answer. Fast and cheap.
Agentic loop
The agent uses tools and memory until the job is done, inside its limits.
Plan and execute
A plan is made first, then carried out step by step. Each step is checked.
- Eval gates on edges. An eval sits between two steps. If the output fails it, the run does not move on.
- Human approval steps. A run can stop and wait for a named person to approve or send it back. It holds its state for as long as that takes.
- Post-run screening. After the run, the output is checked against the articles that apply.
- 01Reader42 questions extracted✓
- 02Drafteranswers cite past approved answers✓
- ↻worker restarted · run resumed at step 03, no work lost
- 03Eval gate · every claim cites a source41 of 42 passed · 1 sent back to the draftergate
- 04Drafter · retry on 1 answerpassed the gate on retry✓
- 05Security sign-offassigned to the security leadawaiting approval
- 06Post-run screening6 articles applyqueued
What every run cost, did and decided.
Every node run is traced with its model, tokens, latency, cost and result. Roll it up by agent, graph, team or provider, and see the error that stopped a run.
Observability for the last 7 days: total model cost $11,230, 1.5 million LLM calls, 8.7 billion tokens, p95 latency of 2.6 seconds and an error rate of 0.8%. The cost line runs across the week, with latency and error sparklines below.
Model spend this month: $128,742 of a $200,000 budget, 64% used, with a soft limit at 80%. At the hard limit, runs fall back to economy models. Cost by agent is led by segment-builder at 39.8%, and cost by model by claude-haiku-4-5 at 61.4%.
Five runs stream in: one completed, one running, one timed out, one cancelled and one failed. The failed run, run-0284, opens to its trace. Steps 4 to 6 passed, and step 7, validate-output, stopped the run because the schema check found a missing source field.
Example figures
One gateway for every model call. Failover built in.
All model traffic goes through one gateway in your cloud. It checks the allowlist, the tier and the budget before a call leaves, and records the call when it returns.
- Failover. When a provider slows down or returns errors, traffic moves to the next allowed provider. The run carries on.
- Your keys. Calls go out with your own model keys. We never charge for tokens.
- Provider health. Latency and errors per provider sit next to cost on the observability board.
An MCP server and an API. Same rails as everything else.
Connect your coding agent to Celara's MCP server, or call the API from your own code. Create agents, graphs, skills, tools and evals, run graphs, and recall memory. Every tool call goes through the constitution first.
# connect your coding agent to Celara $ mcp add celara https://celara.your-company.com/mcp ✓ connected · 41 tools · scoped to your role > agent.create questionnaire-drafter ✓ model on the allowlist · tier standard ✓ 6 articles bound · created as draft v1 > graph.run supplier-questionnaire --batch 12 ✓ 12 durable runs queued · budget ok > tool.call crm.export all-contacts ✕ blocked by Art. 7 data minimization ● refusal written to the evidence ledger
- The constitution, allowlist and budget apply to every MCP and API call
- New agents start as drafts and go through review like any other change
MCP server
41 toolsFor coding agents and AI clients. Author and run agents, graphs, skills, tools, evals and triggers. Use memory, Datahub and your connections.
API
RESTStart runs from your own systems, stream them, approve steps and read the evidence for any run.
Scoped access
Per roleA developer sees the tools their role allows. Every call is recorded against the person who made it.
Every solution you install runs on Fabric.
Install a solution from the marketplace and its agents, graphs, skills and tools land here. They run on the same rails, report to the same observability board and write to the same evidence ledger as everything you build.
Run your first graph on the rails.
Bring one process. We'll run it on Fabric in a working session and show you the trace and the evidence it leaves.