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.
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 →
| 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 can't repair weak evidence by writing with more confidence.
Scroll horizontally to read the full table →
| 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 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 →
| 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. 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 →
| 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. [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.
- 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:dabcd07d6cc878422334dd6511b057d968b02e4c166ccf842058982ad5094368