Celest Learn · Operating model
The Agent Estate Review methodology
An Agent Estate Review is a bounded, read-only examination of an organization's AI agent estate. It establishes scope, collects source observations, joins records without erasing provenance, evaluates evidence quality, produces deterministic findings only where the evidence supports them, and turns those findings into a prioritized operating plan—not automatic remediation.
The review contract
A credible review begins by defining what it may observe and what it may not change. The target is a bounded tenant and environment scope, the collection path is read-only, and every unavailable source remains a visible limitation. The implemented boundary can persist normalized collection state and exposes contract-tested snapshot, finding, and local-acknowledgement paths. Its live Dev proof currently covers a partial empty-estate round trip, not populated findings or acknowledgement. It does not publish, deploy, assign, activate, block, delete, approve, change permissions, or otherwise mutate the inspected Microsoft estate.
| Dimension | Included | Excluded |
|---|---|---|
| Scope | Named tenants, environments, sources, and review period | Unbounded tenant discovery or adjacent environments |
| Access | Supported read access and stakeholder-provided context | Credential acquisition, privilege expansion, or hidden fallbacks |
| State | Normalized observations, findings, and local dispositions | Changes to agents, permissions, publication, or deployment |
| Claims | Facts supported by healthy sources and explicit limitations | Inference presented as observation or absence presented as zero |
The five-pass method
The engagement is organized as five passes. Each pass produces an inspectable artifact and has a stop condition. A later pass cannot repair weak evidence by simply sounding more confident.
| Pass | Work | Artifact | Stop condition |
|---|---|---|---|
| 1. Bound | Name the estate, sources, time window, stakeholders, and permitted reads | Review charter and source plan | Scope or authority is ambiguous |
| 2. Observe | Collect source records with timestamps, health, and source identity | Collection run and source-health record | Every required source is unhealthy |
| 3. Join | Correlate immutable identities where possible and retain conflicting observations | Canonical agent snapshots with join provenance | Identity match is unsafe or unsupported |
| 4. Diagnose | Apply versioned rules only to sufficient evidence | Deterministic findings with reduced evidence | A rule's evidence precondition is unmet |
| 5. Decide | Prioritize findings with owners, expected effects, and evidence gaps | Executive posture and 30/60/90-day plan | Recommendation implies unapproved execution |
What the evidence model preserves
The canonical record is a provenance-preserving join rather than a replacement for source systems. It records when an observation was made, which collection produced it, how identities were joined, whether the snapshot is complete or partial, and which source limitations constrain interpretation.
- Identity and source aliases across the scoped estate
- Ownership, sign-in, lifecycle, publication, deployment, assignment, and activation observations
- Models, orchestration, tools, connectors, flows, sharing, and MCP posture where available
- Usage, exceptions, activity, and economic observations where healthy sources establish them
- Collection time, source health, join provenance, completeness, and reduced finding evidence
- Explicit nulls for facts no healthy source established
Source health controls what may be concluded
A source's failure state is part of the review evidence. The review uses six health states so an inaccessible source cannot quietly become an empty result. A collection with only healthy sources is complete; a mixture of healthy and unhealthy sources is partial; if every source is unhealthy, collection fails closed instead of committing a misleading snapshot.
| State | Meaning | May establish facts? |
|---|---|---|
| ok | The read completed and its result passed the source contract | Yes |
| unavailable | The source was not available for this collection | No |
| not_matched | The source completed but could not match the requested identity | No |
| rejected | The source rejected the scoped read | No |
| error | The source failed while performing the read | No |
| unknown | Health could not be classified more precisely | No |
A finding is a claim with an evidence precondition
A finding is not a dashboard color or a model's intuition. It has a stable fingerprint, subject, versioned rule, severity, observation window, and reduced structured evidence. A rule is allowed to emit a finding only when its required sources are healthy enough to support the claim. For example, an unused-agent finding requires sufficient activity telemetry; missing telemetry cannot establish non-use.
| Question | Required evidence | Honest outcome when absent |
|---|---|---|
| Is this agent unused? | Healthy activity telemetry for the declared period | Usage unknown; source gap recorded |
| Does this agent lack an owner? | Healthy ownership source and an exact agent join | Ownership unknown; no orphan claim |
| Is a blocked tool present? | Tool inventory plus the applicable policy catalog | Tool-policy posture unavailable |
| Is exception rate high? | Healthy invocation and exception counts over the same window | No rate finding |
What the customer should receive
The useful product is not merely an inventory export. The review should leave the organization with a shared operating picture and a bounded decision queue.
- A normalized agent inventory with source and join provenance
- Ownership, lifecycle, tool, MCP, usage, cost, and risk findings where evidence supports them
- An executive posture report that distinguishes zero, false, unknown, and unavailable
- Prioritized proposed work with evidence, accountable owners, and expected effects
- An authority and operating-model workshop
- A 30/60/90-day plan separating immediate evidence repair from later governed change
How to evaluate an Agent Estate Review
NIST's AI Risk Management Framework describes Govern as a cross-cutting function and organizes risk work around Govern, Map, Measure, and Manage. A useful estate review should make those activities operational: define scope and accountability, map the actual estate, measure with source-qualified evidence, and produce governed treatment decisions. [nist-ai-rmf]
- Can every material conclusion be traced to a source observation?
- Does the report preserve unavailable evidence instead of filling gaps?
- Are identity joins and conflicts visible?
- Can the same inputs reproduce the same deterministic findings?
- Are recommendations separated from authority and execution?
- Does the customer leave with owners, priorities, and explicit next decisions?
Limitations
- The initial supported source set may not observe every agent surface, and preview or session-bound sources remain separately labeled and replaceable.
- A read-only review can identify supported gaps and propose work; it cannot prove that later remediation occurred.
- Stakeholder context can explain evidence but must not be silently converted into source observation.
- Results are bounded to the declared scope, collection period, source health, and rule versions.
- Celest's current production promotion remains staged; this page does not claim an autonomous production governance service.
Sources
External claims on this page use the primary sources below. Celest-authored definitions and design criteria are identified as our operating model.
- 1Artificial Intelligence Risk Management Framework (AI RMF 1.0)
National Institute of Standards and Technology · Accessed 2026-07-27. The Govern, Map, Measure, and Manage risk-management framing and governance as a cross-cutting function.
- Author
- Celest
- Source revision
sha256:f47bb025aa0c54d04bec0c2dc51611497b9ed4ecf90fbc21442ae6746e55541d