Show agentless release status on individual integration pages

[jmikell821]

Summary

Agentless-enabled integrations that are GA when deployed with Elastic Agent can still be beta (or another pre-GA stage) when deployed agentless. On individual integration pages, the top-page metadata currently reflects only the package-level release status, not the agentless deployment release status.

Example: Microsoft Defender for Endpoint shows GA in page frontmatter and the details table, while agentless deployment is described as beta only in the Requirements → Agentless enabled integration section.

We need ingest/integrations and docs alignment on whether individual integration pages should surface agentless-specific maturity near the top of the page, and if so, how.

Problem

Customers and support may infer full GA supportability from top-of-page badges when they are planning or using agentless deployment. That mismatch has caused confusion about support expectations.

Today, agentless maturity is communicated in:

• Prose in the Agentless enabled integration requirements section (easy to miss)
• Kibana UI badges next to the Agentless deployment option (kibana#264504)
• The Agentless integrations quick reference table (currently being updated in docs-content#6661)

Individual integration pages still do not clearly distinguish:

Deployment mode	Example (Microsoft Defender for Endpoint)
Agent-based (stack / serverless)	GA
Agentless	Beta

Background / related work

This issue is a follow-up to broader work tracked internally in docs-content-internal#445. Much of the upstream work is complete; this issue focuses on individual integration page metadata.

Completed upstream work

Area	Link	Notes
Package spec	package-spec#1098, package-spec#1130	Adds release under deployment_modes.agentless
Integrations manifests	integrations#18552	~60+ integrations set release: beta for agentless; CSPM set to ga
Kibana UI	kibana#264504	Shows agentless release badge on integration detail and package policy form
Quick reference page	ingest-docs#1886	Created agentless integrations quick reference
Quick reference disclaimer	integration-docs#1240	Temporary note that Release status column reflects agent-based mode, not agentless
Release status clarification	docs-content#5854	Closed; led to #1240 and #6661
Quick ref fixes	docs-content-internal#1102	Closed; broken link and terminology fixes

In progress (separate from this issue)

Issue	Scope
docs-content#6661	Update integration-docs automation to read deployment_modes.agentless.release in the agentless quick reference table

Related Kibana / ingest context

• ingest-dev#5302 — original request to show Beta tag for agentless-capable integrations in Kibana
• ingest-dev#6141 — related Kibana agentless badge work
• integrations#18294 — referenced in kibana#264504

Related but out of scope for this issue

Issue	Description
docs-content#6644	Document which data streams are supported for agentless-enabled integrations
docs-content#6624	Firehose agentless integration docs

Current behavior (integration-docs automation)

Individual integration pages are generated from EPR data in integration-docs:

• Frontmatter applies_to (stack, serverless) uses package semver / lifecycle
• Details table Version row uses package semver via getLifecycle(version)
• deployment_modes.agentless.release is available in manifests but is not used for top-of-page metadata on individual pages

Relevant generator files:

• src/make-new-md-file/make-frontmatter.js
• src/make-new-md-file/make-details.js
• src/get-integrations.js

For default-value logic when deployment_modes.agentless.release is absent, see @MichelLosier's comment on docs-content-internal#445 and Kibana’s getAgentlessRelease in kibana#264504.

Questions for ingest / integrations

1. Is the Kibana UI + agentless quick reference table sufficient, or should individual integration pages also surface agentless maturity near the top?
2. If yes, which approach do we prefer?
   • A. Add an Agentless release status row to the details table when deployment_modes.agentless.enabled === true
   • B. Add a section-level {applies_to} / product badge on the Agentless enabled integration section only
   • C. Introduce a new applies_to dimension for agentless (would require docs-builder support)
   • D. Other (please specify)
3. Should frontmatter stack / serverless stay GA when the agent-based integration is GA, even if agentless is beta? (Probably yes — we probably shouldn't mark the whole integration beta for agent-based users.)
4. After agentless platform goes GA, should integration teams update deployment_modes.agentless.release: ga individually, or is there a planned bulk/default behavior?

Proposed acceptance criteria (TBD after discussion)

• Stakeholders agree whether individual integration pages need agentless-specific maturity signaling
• If yes, agreed implementation approach documented
• integration-docs automation updated accordingly (if applicable)
• Behavior aligns with Kibana UI and agentless quick reference table
• Temporary disclaimer in integration-docs#1240 updated or removed as needed

cc: @nimarezainia @MichelLosier @lucabelluccini @vishaangelova @jsoriano @theletterf

[github-actions]

Elastic Docs AI Menu

Check one box to run an AI workflow for this issue.

• Triage (docs-triage). Status: not started.
• Scope the docs work (docs-issue-scope). Status: not started.

Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team.

[vishaangelova]

I think the easiest and probably most efficient approach at this point is to add a release-status row to the details table on each integration page (generated by automation in integration-docs), populated only when deployment_modes.agentless.enabled === true.

Suggested solution

• Add a | **Managed deployment release status** | <badge> | row to the details table, rendered only for integrations with a managed deployment.
• Reuse the release-resolution logic already used for the managed integrations quick reference in Display agentless deployment lifecycle in Agentless integrations quick reference #6661, which mirrors Kibana's getAgentlessRelease (default of beta when release is absent, CSPM's GA-before-release-field rule, and only-agentless templates deferring to package semver). This keeps the individual pages, the quick reference table, and the Kibana UI badges consistent by construction.
• Badge rendering matches the existing table convention: plain GA for GA, and a product badge (beta/preview) otherwise.

[nimarezainia]

I thin an integration has only one life-cycle. That applies to agentless and agent based. The problem right now is due to the fact that the agentless platform is in beta. Once we GA the agentless platform, agetless integrations should inherit the life-cycle that exist for the integration as a whole.

is this not the case?

[vishaangelova]

@nimarezainia ah, by agentless integration lifecycle, what I meant is that integrations now have the deployment_modes.agentless.release field in their manifest.yml set to Beta or GA, which can be different from the integration's agent-based release status. So the idea here is to surface the release status of the agentless deployment in the table at the top of each integration's doc.

Currently, although agentless integrations typically include an "Agentless enabled integration" section in their docs, in some cases it might be missing or it might be buried a little deeper in the page, so users won’t immediately see it when checking the integration documentation. We'd like to surface the agentless deployment availability (and status) at the top by pulling the deployment_modes.agentless.release field from the manifest.yml and including it in the generated table as a new row (Managed deployment release status).

[nimarezainia]

Apologies I wasn't clear. By Lifecycle I am referring to the integration version number. Perhaps incorrectly.
The GA/Beta is still valid. An integration will have a GA/Beta status for Agent based, and it will have GA/Beta for Agentless