{ "schemaVersion": 1, "id": "agent-estate-review", "slug": "agent-estate-review", "title": "The Agent Estate Review methodology", "shortTitle": "Agent Estate Review methodology", "description": "A practical, read-only method for establishing what AI agents exist, what the available evidence supports, and what decisions an organization should make next.", "targetQuestion": "What is an Agent Estate Review, what evidence does it collect, and what should it produce?", "directAnswer": "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.", "scope": "This page publishes Celest's Agent Estate Review methodology and proposed two-week engagement format. Celest has contract and test proof for collection, normalization, deterministic findings, persistence, and the read API, plus a bounded Dev round trip for a truthful partial empty estate. Populated live findings and acknowledgement remain pending proof; nothing here claims autonomous production remediation.", "evidenceLevel": "Celest-authored methodology grounded in the repository's implemented read-only contracts and cited risk-management guidance.", "author": { "name": "Celest", "url": "https://celest.dev/" }, "published": "2026-07-27", "updated": "2026-07-27", "sections": [ { "id": "review-contract", "heading": "The review contract", "blocks": [ { "type": "paragraph", "text": "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." }, { "type": "callout", "label": "Review promise", "text": "We will tell you what the available evidence establishes, what it does not establish, and which decisions deserve attention. We will not turn missing evidence into reassuring certainty." }, { "type": "table", "caption": "The fixed review boundary", "columns": [ "Dimension", "Included", "Excluded" ], "rows": [ [ "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" ] ] } ] }, { "id": "five-pass-method", "heading": "The five-pass method", "blocks": [ { "type": "paragraph", "text": "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." }, { "type": "table", "caption": "Five passes from scope to operating plan", "columns": [ "Pass", "Work", "Artifact", "Stop condition" ], "rows": [ [ "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" ] ] } ] }, { "id": "evidence-model", "heading": "What the evidence model preserves", "blocks": [ { "type": "paragraph", "text": "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." }, { "type": "list", "items": [ "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" ] }, { "type": "callout", "label": "Three values that must remain different", "text": "Null means no healthy source established the fact. False means a healthy source explicitly established false. Zero is valid only when a healthy source explicitly observed zero." } ] }, { "id": "source-health", "heading": "Source health controls what may be concluded", "blocks": [ { "type": "paragraph", "text": "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." }, { "type": "table", "caption": "Source-health vocabulary", "columns": [ "State", "Meaning", "May establish facts?" ], "rows": [ [ "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" ] ] } ] }, { "id": "finding-standard", "heading": "A finding is a claim with an evidence precondition", "blocks": [ { "type": "paragraph", "text": "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." }, { "type": "table", "caption": "Examples of evidence-conditioned findings", "columns": [ "Question", "Required evidence", "Honest outcome when absent" ], "rows": [ [ "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" ] ] } ] }, { "id": "deliverables", "heading": "What the customer should receive", "blocks": [ { "type": "paragraph", "text": "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." }, { "type": "list", "items": [ "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" ] }, { "type": "callout", "label": "Commercial boundary", "text": "The review produces decisions and proposed work. Any future action against the estate requires a separate plan, explicit authority, bounded execution path, and fresh-state verification." } ] }, { "id": "how-to-evaluate", "heading": "How to evaluate an Agent Estate Review", "blocks": [ { "type": "paragraph", "text": "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.", "sourceIds": [ "nist-ai-rmf" ] }, { "type": "list", "items": [ "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": [ { "id": "nist-ai-rmf", "title": "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", "publisher": "National Institute of Standards and Technology", "url": "https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf", "accessed": "2026-07-27", "supports": "The Govern, Map, Measure, and Manage risk-management framing and governance as a cross-cutting function." } ], "related": [ { "title": "Evidence, authority, and receipts", "url": "https://celest.dev/learn/evidence-authority-and-receipts", "description": "See why a finding, decision, handoff, execution observation, and receipt must remain distinct." }, { "title": "Request an Agent Estate Review", "url": "mailto:founders@celest.dev?subject=Agent%20Estate%20Review", "description": "Bring a bounded Microsoft agent scope and the operating questions your team needs answered." } ], "publication": { "canonicalUrl": "https://celest.dev/learn/agent-estate-review", "sourceDigest": "sha256:f47bb025aa0c54d04bec0c2dc51611497b9ed4ecf90fbc21442ae6746e55541d" } }