Goal

The ai-ml-pipeline-testing pipeline should exercise integrations against a cluster that has AutoEmbedding (automatically-embedded vector indexes, "type": "autoEmbed") available. Today the great majority of Evergreen tasks provision a deployment where AutoEmbedding is not set up, so any integration feature that depends on it is silently untested.

Blocked by

Nothing.

Current state (verified on main, commit 7fd88e0)

Setup path	Evergreen func	AutoEmbedding available?
Local Atlas (mongodb-atlas-local via drivers-evergreen-tools/.evergreen/run-orchestration.sh --local-atlas)	setup local atlas	No - no embedding provider configured
Community + mongot docker-compose (.evergreen/mongodb-community-search/)	setup community atlas	Yes - mongot.conf sets embedding.providerEndpoint to VoyageAI with isAutoEmbeddingViewWriter: true
Remote Atlas cluster (per-integration URI from secrets, setup-remote.sh)	setup remote atlas	Unverified - clusters are pre-existing, this repo never creates them

Counts in .evergreen/config.yml: ~18 tasks use setup local atlas, 4 use setup community atlas (test-langchain-python-community, test-langgraph-store-python-community, test-pymongo-search-utils-community, test-self-community), ~17 use setup remote atlas.

.evergreen/scaffold_atlas.py creates search indexes from each integration's indexes/*.json via SearchIndexModel. No index definition in any integration directory uses "type": "autoEmbed" - the only autoEmbed usage in the repo is .evergreen/mongodb-community-search/self_test.py, which is exercised solely by the test-self-community self-test.

Prerequisites not in the repo docs

• The community+search path needs the VoyageAI keys written to secrets/voyage-api-query-key and secrets/voyage-api-indexing-key with mode 400 by start-services.sh; mongot refuses the embedding provider otherwise. The local-atlas path never starts a mongot configured for embedding at all.
• For the remote path, a cluster only supports AutoEmbedding on a version/tier that offers it. The per-integration clusters behind the *_MONGODB_URI secrets predate AutoEmbedding and have not been re-checked.

Steps

1. Decide which of the three setup paths is the AutoEmbedding-capable baseline.
2. Audit the remote clusters behind the *_MONGODB_URI secrets used by .evergreen/setup-remote.sh and record, per cluster, whether an autoEmbed index can be created.
3. Make an AutoEmbedding-capable deployment the default for tasks that test embedding-backed features, rather than an opt-in COMMUNITY_WITH_SEARCH=1 variant used by only 4 tasks.
4. Add at least one autoEmbed index definition to an integration's indexes/ directory so scaffold_atlas.py exercises the code path in a real integration test, not just the self-test.
5. Make the failure loud: if an integration's suite requires AutoEmbedding and the target deployment lacks it, the task should fail rather than skip.

Acceptance criteria

• At least one non-self-test Evergreen task creates and queries an autoEmbed index as part of its normal run.
• Every remote cluster referenced in setup-remote.sh is documented as AutoEmbedding-capable or explicitly out of scope.
• A deployment lacking AutoEmbedding causes a task that needs it to fail visibly.

Decisions needed

1. Baseline deployment. Should AutoEmbedding coverage come from (a) expanding the community+mongot docker-compose path to more tasks, (b) upgrading/recreating the remote Atlas clusters, or (c) both, split by integration?
2. Scope. Do all integrations need AutoEmbedding coverage, or only those whose upstream libraries expose the feature?

Notes

• setup_local_atlas() in .evergreen/utils.sh tears down the community-search stack whenever COMMUNITY_WITH_SEARCH is unset, so the two paths are mutually exclusive on a host.
• self_test.py already proves the autoEmbed path works in the community-search environment (index auto_embed_plot_index, model voyage-4, $vectorSearch with a text query and no client-side vector) - the cheapest existing template to copy.
• pymongo-voyageai tests client-side VoyageAI embeddings, which is a different thing from server-side autoEmbed and does not cover this gap.