Celest
Sections
Estate ReviewEstate Review

Celest Learn · Method

The Agent Estate Review methodology

An Agent Estate Review maps an organization's AI agent estate, connects source records without losing provenance, evaluates evidence quality, produces repeatable findings, and turns them into a prioritized operating plan. Celest runs the review read-only so teams can see the estate clearly before choosing what to change.

Published
Updated
Evidence
Celest-authored methodology with explicitly attributed internal Customer Zero observations and cited risk-management guidance.

The review boundary

An Estate Review begins with the estate and operating questions your team cares about. Celest examines the agreed Microsoft sources read-only, connects the records it can establish, and turns every missing or irreconcilable record into a named gap.

Your agents, permissions, assignments, and publication state stay untouched while Celest builds the operating picture.

Customer Zero proves the core pipeline on Celest's own partial estate: populated records, repeatable findings, null-preserving detail, and one signed-in acknowledgement. Those are internal engineering results; the live Estate Review applies the same model to each admitted customer scope.

Scroll horizontally to read the full table →

The fixed review boundary
DimensionIncludedExcluded
ScopeNamed tenants, environments, sources, and review periodUnbounded tenant discovery or adjacent environments
AccessSupported read access and stakeholder-provided contextCredential acquisition, privilege expansion, or hidden fallbacks
StateNormalized observations, findings, and local dispositionsChanges to agents, permissions, publication, or deployment
ClaimsFacts supported by healthy sources and explicit limitationsInference 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 can't repair weak evidence by writing with more confidence.

Scroll horizontally to read the full table →

Five passes from scope to operating plan
PassWorkArtifactStop condition
1. BoundName the estate, sources, time window, stakeholders, and permitted readsReview charter and source planScope or authority is ambiguous
2. ObserveCollect source records with timestamps, health, and source identityCollection run and source-health recordEvery required source is unhealthy
3. JoinCorrelate immutable identities where possible and retain conflicting observationsCanonical agent snapshots with join provenanceIdentity match is unsafe or unsupported
4. DiagnoseApply versioned rules only to sufficient evidenceDeterministic findings with reduced evidenceA rule's evidence precondition is unmet
5. DecidePrioritize findings with owners, expected effects, and evidence gapsExecutive posture and 30/60/90-day planRecommendation 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 can't 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.

Scroll horizontally to read the full table →

Source-health vocabulary
StateMeaningMay establish facts?
okThe read completed and its result passed the source contractYes
unavailableThe source was not available for this collectionNo
not_matchedThe source completed but could not match the requested identityNo
rejectedThe source rejected the scoped readNo
errorThe source failed while performing the readNo
unknownHealth could not be classified more preciselyNo

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. Only when its required sources are healthy enough to support the claim is a rule allowed to emit a finding. For example, an unused-agent finding requires sufficient activity telemetry; missing telemetry can't establish non-use.

Scroll horizontally to read the full table →

Examples of evidence-conditioned findings
QuestionRequired evidenceHonest outcome when absent
Is this agent unused?Healthy activity telemetry for the declared periodUsage unknown; source gap recorded
Does this agent lack an owner?Healthy ownership source and an exact agent joinOwnership unknown; no orphan claim
Is a blocked tool present?Tool inventory plus the applicable policy catalogTool-policy posture unavailable
Is exception rate high?Healthy invocation and exception counts over the same windowNo 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. [1]

  • 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 can't 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.
  • The engagement ends with an operating picture and plan; any action against the estate follows a separately authorized execution and verification path.

Sources

External claims on this page use the primary sources below. Celest-authored definitions and design criteria are identified as our operating model.

  1. 1
    Artificial 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.

Publication record
Author
Celest
Source revision
sha256:dabcd07d6cc878422334dd6511b057d968b02e4c166ccf842058982ad5094368