The Unseen AI-Agent Readiness Methodology (AARM) is the step-by-step method for determining whether a Salesforce environment is structurally ready for AI agent deployment.
The Unseen AI-Agent Readiness Methodology (AARM) is the step-by-step method for determining whether a Salesforce environment is structurally ready for AI agent deployment.
It is not a maturity score for innovation posture. It is a readiness test for operational reality.
AARM answers one question:
Can this Salesforce org support AI agents without forcing the enterprise to automate ambiguity?
AARM evaluates ten readiness dimensions using evidence from metadata review, configuration analysis, process documentation, stakeholder interviews, and sampled transaction history.
Each dimension is scored on a 1-5 scale:
1 = not ready2 = materially deficient3 = conditionally ready only for narrow pilots4 = ready for bounded deployment5 = ready for scaled use with governanceEach dimension receives:
1-5 scoreAARI = ((sum(dimension score x weight) - 1) / 4) x 100
This produces a normalized 0-100 readiness index.
Readiness is not determined by average alone. If automation conflict mapping, permission architecture legibility, or change governance maturity score below 3, the org is not ready for write-enabled agent deployment regardless of average score.
The output is not only a score. It is a sequence of corrective actions tied to Unseen's six-stage model so the client knows what must happen before AI expands.
| Dimension | Weight | What it means | How to assess it | What "ready" looks like | What "not ready" costs the org |
|---|---|---|---|---|---|
| 1. Data model clarity | 12% | The institution can explain the core objects, lifecycle states, relationships, and system-of-record logic the agent will depend on. | Review object model, stage definitions, ownership logic, duplicate concepts, and key entity relationships. | Core business objects and lifecycle states are defined, stable, and linked to named owners. | The agent reasons over contradictory entities, duplicate meanings, or lifecycle labels that teams interpret differently. |
| 2. Field-level documentation coverage | 10% | Critical fields have business definitions, owners, and clear downstream use. | Inspect descriptions, help text, usage patterns, requiredness, population rates, and reporting or automation dependency. | Critical fields are documented, named consistently, and trustworthy enough for agent context or action. | Agents rely on fields no one can define, with hidden workarounds and low population reliability. |
| 3. Automation conflict mapping | 12% | The org understands what automation fires where, in what order, and with what side effects. | Audit Flow, Apex, Process Builder, Workflow Rules, scheduled actions, and object-event overlap. | Revenue-critical objects have mapped automation paths, collision risks are known, and fault handling is visible. | Agent actions trigger invisible downstream behavior, duplicate updates, recursive loops, or approval confusion. |
| 4. Permission architecture legibility | 10% | The enterprise can define what an agent may read, suggest, update, or approve. | Review profiles, permission sets, field access, service accounts, approval rights, and separation of duties. | Agent scope is bounded by object, field, action type, and approval policy with named ownership. | AI inherits unclear or excessive permissions and creates an access-control problem disguised as automation. |
| 5. Process logic documentation | 12% | The business rules the agent is expected to follow are documented beyond the happy path. | Review SOPs, decision trees, exception handling, approval logic, routing rules, and knowledge-holder concentration. | Core workflows and exception paths are documented and institutionally owned. | The agent is forced to operationalize tribal knowledge, inconsistent judgment, or undocumented exceptions. |
| 6. Integration boundary mapping | 10% | The org understands what external systems write to or read from Salesforce and what state changes they cause. | Review connected apps, middleware, APIs, ETL jobs, service accounts, and write-back behavior. | Inbound and outbound dependencies are mapped with owners, failure modes, and data contracts. | AI behavior is corrupted by external writes, hidden dependencies, or unknown source-of-truth conflicts. |
| 7. Historical data integrity | 10% | Past records are reliable enough to train prompts, ground recommendations, or evaluate agent quality. | Sample historical records, inspect null rates, coding drift, duplicate records, and policy changes over time. | Historical records on key objects are sufficiently complete and interpretable for context and benchmarking. | The organization draws agent instructions or evaluations from data that encodes old processes, bad hygiene, or unmanaged exceptions. |
| 8. Custom code documentation | 8% | Apex, managed-package logic, and custom components are understood well enough to predict side effects. | Review code inventory, trigger ownership, interfaces, test coverage signals, and documentation of business intent. | Critical custom logic is inventoried, owned, and explained in business terms. | Agents interact with code paths no one can confidently describe or debug. |
| 9. User behavior pattern documentation | 8% | The institution understands how users really work around the system, not just how process diagrams say they should. | Interview operators, inspect reassignments, manual overrides, skipped steps, free-text notes, and off-system workarounds. | Real-world user patterns are documented and known to diverge only in controlled ways. | AI is deployed into a process that already depends on informal behavior invisible to design documents. |
| 10. Change governance maturity | 8% | The organization can approve, test, document, communicate, and review changes affecting agent behavior. | Review release practices, CAB or approval paths, sandbox discipline, rollback history, documentation updates, and post-change review. | Changes are versioned, approved, testable, and reflected in documentation and monitoring. | AI behavior drifts because the environment changes faster than governance can keep up. |
| Profile | AARI Range |
Meaning | Deployment stance |
|---|---|---|---|
| Structurally Unready | 0-39 |
The org lacks the basic legibility required for AI to act safely inside it. | No write-enabled agent deployment. Begin with audit, documentation, and governance reconstruction. |
| Conditionally Ready | 40-59 |
The org may support narrow internal pilots, but material blockers remain. | Limit use to observation, summarization, or recommendation workflows with strong human review. |
| Pilot Ready | 60-79 |
The org can support bounded AI deployments with explicit controls and instrumentation. | Launch tightly scoped pilots with rollback, logging, and named owners. |
| Scale Ready | 80-100 |
The environment has the structural clarity and governance needed for broader AI adoption. | Expand in phases, but retain ongoing monitoring and governance review. |
Any one of the following should hold the org below Pilot Ready until remediated:
3333 on systems the agent will touch3An AARM engagement should produce:
AARIAARM does not answer whether AI is strategically important. It answers whether the organization has earned the right to deploy it safely.
That distinction is where most enterprise AI programs fail.
Email hello@unseen.so to request an AI Readiness Audit.