## TL;DR
Your agent polls the SCIM provisioning status, sees a top-level "complete" or success flag, and reports the job done while individual users are still pending. The fix: stop trusting the summary status. Poll the per-user provisioning state and only report complete when every user shows active. Add a final verification pass that actually checks each account can authenticate.

## The error
```text
Agent: "Provisioning complete: 25/25 users provisioned"
IdP admin console: 9 users still "pending", not yet active
```

## Steps
1. Reproduce the gap. Run the agent's status check, then compare against the IdP console's per-user list. Expected output: the agent's summary disagrees with the per-user states.
2. Read the status schema. Find what the "complete" flag actually means in the SCIM or provisioning API: often "request accepted," not "users active." Expected output: documentation or a response sample showing the flag's real meaning.
3. Switch the agent to per-user polling. Check each user's status individually and aggregate. Expected output: the agent reports 16 of 25 active instead of a false complete.
4. Define done as all-active. The agent may only say complete when every user is active, or when a timeout expires with a named list of stragglers. Expected output: no more premature "complete" reports.
5. Add a login verification pass. After all-active, verify a sample of accounts can actually authenticate. Expected output: verification passes, or the real failures surface with names.

## When to use
- The agent reports provisioning complete but users cannot log in
- The IdP console shows pending users the agent did not mention
- Provisioning "works" in demos and fails in production scale

## When not to use
- Provisioning fails outright with errors: fix the SCIM mapping or credentials
- Users are active but lack the right groups: a group-mapping problem
- The IdP itself is down: wait it out, do not tune the agent

## Tool compatibility
SCIM 2.0 provisioning from any identity provider (Okta, Entra ID, Google Workspace) to any SaaS app, plus agent frameworks that poll async job status. The per-user-truth pattern applies to any async provisioning API.

## Variant phrasings
### scim provisioning stuck pending
Poll per-user state, not the summary flag.
### agent says provisioning complete too early
The summary flag means accepted, not done.
### scim status complete users not active
Verify each account individually.
### onboarding agent false complete
Define done as all users active.

## Why it happens
Async APIs separate "we accepted your request" from "we finished the work," and they expose both as status fields with confusingly similar names. An agent reading the top-level status sees success at step one of a hundred. SCIM makes this worse because user activation fans out across connectors with their own queues: the SCIM server accepted all 25 users in milliseconds, but the downstream app provisions them over minutes. The summary is technically true and operationally useless. Per-user polling is the only status that matches what the new hire experiences.

## Edge cases
- Users stuck pending forever: set a straggler timeout (for example 30 minutes) after which the agent escalates with names instead of waiting silently.
- The per-user API is paginated: poll all pages or the stragglers hide on page two.
- A user fails provisioning permanently: distinguish "pending" from "failed" so one bad record does not block the all-active signal.
- The IdP caches status: add a small delay between the all-active signal and the verification pass.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_j-1jhbrqX7wW8oS-vdQMWg