---
title: Enterprise
description: "One operating picture every agent across functions shares, simulates against, and acts from."
---

Across a company, the world model is one operating picture every function shares: the live read on what is true right now about deals, cash, incidents, and commitments, and how sure the business is of each. At Meridian, a B2B software company in the last week of the quarter, the deal that would close the gap shows won in the CRM and has no invoice in billing. Each team is right about its own slice, and no one, agent or person, sees the company whole. That is the trap at scale, and it is what one shared belief state outside the model dissolves: every operating agent reads, simulates against, and acts from the same picture. The seven worlds in this section are slices of this one, and a company runs all of them at once.

## The world

The **environment** is the operating company: customers and accounts, deals and pipeline, products and inventory, incidents, cash and forecast, commitments and headcount. Entities span functions. Relations cross them: this renewal depends on that open incident, this forecast rests on that deal closing, this shipment blocks that customer's go-live. Ground truth is scattered across systems of record (CRM, ERP, ticketing, the data warehouse, finance, source control), each authoritative for its own slice and silent about the rest. The world model is the layer that reconciles them into one current picture instead of leaving every agent to stitch it together per turn.

## What streams in

**Observations** arrive from every operational surface the company already runs:

- CRM updates, deal-stage changes, and renewal signals
- support tickets, chat transcripts, and incident channels
- ERP and inventory movements, fulfillment and logistics events
- finance and billing events, and the numbers behind the forecast
- the actions of the company's own agents, in every function

That last channel is what makes it one world and not many. When the finance agent revises the forecast or the support agent escalates a churn risk, that becomes evidence the other agents read. The picture each one acts from already carries what the others just learned.

## The belief state

The company's operating picture is a set of claims drawn from every function, each carrying confidence, provenance, and decay, alongside the gaps and conflicts no single team can see alone.

```
┌──────────────────────────────────────────────────────────────┐
│  MERIDIAN: Q3 OPERATING PICTURE                              │
│                                                              │
│  ● "Q3 revenue lands within 2% of plan"  71% │ finance+pipe  │
│  ● "Enterprise churn rising in EU"       64% │ support+CRM   │
│  ● "Fulfillment SLA at risk on line 3"   58% │ ops+sensors   │
│  ● "SOC2 controls intact"                88% │ eng+audit     │
│    └─ ⚠ Decayed: last audit was 70 days ago                  │
│                                                              │
│  Gap: "No demand forecast for the new SKU"                   │
│  Contradiction: sales says the deal closed; billing has none │
└──────────────────────────────────────────────────────────────┘
```

Every claim carries its source function, so a forecast built on finance plus pipeline reads differently from one a single dashboard asserts. The sales-versus-billing contradiction is the kind that costs real money: it is invisible inside either system and obvious the moment both feed one world. The agent that surfaces it is not smarter than the teams; it is the only one looking at the whole board.

## What we're after

The **intent** is the company's, not one function's: hit the plan and keep the commitments behind it. Success means the quarter lands where it was promised, the obligations the business made are met, and every operating decision traces to evidence a leader can inspect. The limiting factor is the cross-functional unknown most likely to move the outcome, which here is the unreconciled deal, not the security posture. Moves are ranked against that intent, not against raw uncertainty, so the company's attention lands where being wrong is most expensive.

| | |
|---|---|
| **Goal** | Hit the plan and keep the commitments behind it. |
| **Success** | Quarter on plan, obligations met, every decision traceable to evidence. |
| **Limiting factor** | The cross-functional unknown most likely to move the outcome. |

## The policy

A company runs under rules that outrank any single team's convenience. You encode them once, and every agent inherits them:

| Policy bucket | Across the business |
|---|---|
| **Invariants** | Respect compliance, data-residency, and privilege boundaries. Stay within each role's spend and commitment authority. |
| **Source hierarchy** | The system of record outranks a Slack message; a signed contract outranks a verbal "we agreed"; a posted number outranks a projected one. |
| **Conventions** | How functions hand off, how an incident is escalated, how a forecast is revised. |
| **Avoid** | Letting one team's optimistic read inflate a company-level belief; acting on a number another system already moved. |

## The actions

Group what an agent may do by what it costs to be wrong, the same banding every function uses:

| Action | Safety class | Effect |
|---|---|---|
| `reconcile`, `summarize-state`, `flag-risk` | **info** | Read-only. Surfaces the picture; changes nothing. |
| `update-forecast`, `open-ticket`, `adjust-inventory` | **mutates** | Changes a function's recorded state. |
| `issue-credit`, `reallocate-budget`, `notify-customer` | **needs-approval** | Gated on a human with the authority. |

Today, policy and actions are a modeling lens you encode, not a contract the engine runs for you. The invariants, the source hierarchy, and these safety classes live in how each agent observes and acts. The engine does not yet take a registered policy and refuse the calls that violate it; a declarative config surface for that is on the roadmap. Read the tables as the contract your agents uphold. What the engine guarantees is the rest of the loop: it fuses the signals into one picture, surfaces the conflicts, and keeps the trail.

## Plan & act

An operating agent does not start from the thread in front of it. It orients on the whole company picture, reads the cross-functional move most at risk, and acts, with the result folding back in for every other agent:

```ts
import Beliefs from 'beliefs'

const beliefs = new Beliefs({
  apiKey: process.env.BELIEFS_KEY,
  agent: 'ops-orchestrator',
  namespace: 'org:acme',
  writeScope: 'space',
})

// 1. Orient: read the company picture; the ranked next moves ride back on it
const context = await beliefs.before('Are we on track for Q3, and what is most at risk?')
const [move] = context.moves   // top-ranked, already in hand; no extra call
// → { action: 'gather_evidence', subType: 'reconcile-deal-billing', valueOfInformation: 0.8, ... }

// 2. Act: your agent dispatches the tool the move points to
const recon = await runTool(move.subType)   // 'reconcile-deal-billing' → your CRM + billing reconciler

// 3. Fold the result back in; it becomes the next observation for every function
await beliefs.after(JSON.stringify(recon), { tool: 'reconciler', source: 'crm+billing' })
```

The verdict is the product. A stack of dashboards hands a leader twelve views and leaves the synthesis to a Monday meeting. The company world model renders the call: Meridian's quarter is at risk on the unreconciled deal, confirm that before trusting the forecast, and here is the confidence on each claim and the function it came from. Because every belief traces to the system it came off, a `needs-approval` move reaches a human with its evidence attached, not as a recommendation to take on faith.

<Callout type="info" title="Emerging: simulate the move before you make it">
As the business accumulates action-to-outcome history, an agent can simulate a cross-functional move forward before committing to it (`beliefs.forecast.predict([...])`): if we pull budget from here, what happens to the SLA there. It reports low confidence until enough real outcomes have accrued to calibrate, so a simulation is never mistaken for a guarantee. [Moves](/dev/core/moves) covers the forecasting layer.
</Callout>

<CardGroup cols={2}>
  <DocsCard title="Engineering" description="A codebase as a world model: the cleanest world to prove the loop in." href="/dev/cases/engineering" />
  <DocsCard title="World model" description="The full frame: environment, observations, belief, intent, policy, actions." href="/dev/core/world" />
</CardGroup>
