Scope: First-time setup of a CloudWatch Application Observability Space — from creation through first traces flowing. For using a Space that is already set up (queries, dashboards, alerts, evaluations), route to aws-observability.

aws cloudwatchomni ...

1. If the user is asking what Omni is, what a Domain or Space or grant means, where to start, or the end-to-end order of steps from nothing — rather than asking to perform one setup step — route to

   references/cloudwatch-omni/app-basics.md

   and answer the sequence from its "Setup order" section (not from a single procedure file such as

   collector.md

   , which covers one step). It also carries the boundary against aws-observability. A question about one concept's rules — a Space's Region relative to its Domain, the roles

   create-space

   needs — belongs to the procedure file for that concept (

   spaces-and-domains.md

   ), which the routing table names.
2. If the request is about instrumenting an AI agent project (adding OTel to a framework such as LangChain, LangGraph, Strands, CrewAI, OpenAI Agents, or Vercel AI), route to

   references/cloudwatch-omni/omni-agents-instrumentation/omni-agents-instrumentation.md

   .
3. If the request is about instrumenting a general application (a service on EC2, ECS, EKS, or Lambda in Python, Node.js, Java, or .NET — not an AI-agent framework), route to

   references/cloudwatch-omni/instrumentation/instrumentation.md

   .
4. If an instrumentation, ADOT, or collector request names neither Omni or a Space, nor Application Signals, ServiceEvents, or the

   amazon-cloudwatch-observability

   add-on, probe the target Region before choosing:

   aws cloudwatchomni list-spaces --region <region>

   . A Space exists → this skill,

   references/cloudwatch-omni/instrumentation/instrumentation.md

   . No Space → the customer has not adopted Omni; route to aws-observability's Application Signals onboarding reference. If the probe errors with an unknown service, that is the CLI model, not evidence Omni is absent — fall back to the customer's wording and ask only if still inconclusive.
5. If the request is about Space/Domain creation or configuration, route to the matching setup reference. An authorization error that appears the moment a just-created Space is used is part of this — it is a space access role trust-policy problem (

   create-space

   never verifies the role can be assumed), so route to

   references/cloudwatch-omni/spaces-and-domains.md

   → "If the Space was created but cannot be used", not to the access-grants reference.
6. If the user asks about getting telemetry to a destination — telemetry not yet reaching CloudWatch — deploy an OTel Collector on EC2/ECS/EKS so an instrumented workload has somewhere to send OTLP, and wire the app's

   OTEL_EXPORTER_OTLP_ENDPOINT

   to it:

   references/cloudwatch-omni/instrumentation/collector.md

   . The collector exports straight to CloudWatch's own per-signal OTLP endpoints. If instead the telemetry is already in CloudWatch log groups and needs forwarding into the Dataset, route to

   references/cloudwatch-omni/data-forwarding-and-centralization.md

   .
7. If the request is about getting Azure telemetry into CloudWatch, route to

   references/cloudwatch-omni/azure-ingestion/azure-ingestion.md

   and decide by intent. If the customer wants the telemetry their own application produces (the logs/metrics/traces from their code), that is supported via the CloudWatch agent on an Azure VM or AKS cluster — follow the reference. If they want telemetry their Azure resources emit on their own (the Azure equivalent of AWS VPC flow logs / Route 53 logs), that is not available — say so and do not attempt a setup.
8. If the user asks to connect, enable, or authorize Slack for a Space for the first time (including granting the operator permission to use it), route to

   references/cloudwatch-omni/slack-integration.md

   . Using Slack after it is connected (posting findings to a channel, mentioning the assistant, or searching Slack) happens in Slack and the console and is not covered by these skills; Slack as an alert notification target is covered by aws-observability's Omni alerts reference.
9. If the user wants Application Signals, ServiceEvents, or Dynamic Instrumentation, STOP and route to aws-observability — those are CloudWatch features and are out of scope for Omni instrumentation.
10. If the user already has a working Space and is asking about queries/dashboards/alerts, STOP and route to aws-observability.
11. If the user asks to register their own MCP tool server, connect a custom MCP server, set up MCP authentication, or choose an auth type for an MCP server (including an OAuth-protected one), route to

    references/cloudwatch-omni/custom-mcp-integration.md

    . For an OAuth-protected server the choice is one of the two OAuth2 types — client credentials for machine-to-machine, authorization code when a user must consent.
12. If the user asks to connect GitHub, link a GitHub organization or repositories, or enrich the application map from source code: CloudWatch Omni has no GitHub integration. Say so plainly and stop — do not walk through a setup. Do not offer a substitute: the Application Signals GitHub Action and the CloudWatch Logs GitHub audit-log source are separate CloudWatch features, not a way to connect GitHub to Omni, and a custom MCP server is not a GitHub integration. A GitHub-related feature found in public documentation is not evidence of an Omni GitHub integration.
13. If the request names neither product — "add observability to my API", "how should I begin monitoring my workload", with no mention of Omni, a Space, a Domain, or of a CloudWatch feature — do not assume either one. Which product a customer wants to set up is their intent, not something the account's current state tells you, so ask, framed product versus product: CloudWatch Omni (Application/Agent Observability — Domains, Spaces, grants, a Dataset) or CloudWatch (log groups, alarms, Log Insights, Application Signals). In the same message, explain the boundary so they can choose — it is setup versus use: creating or configuring a Domain, Space, grant, or Access Profile, getting telemetry flowing for the first time, and instrumenting an application or agent for Omni are first-time Omni setup and belong here; querying telemetry, building dashboards, and configuring alerts are day-to-day use, and — together with anything about Application Signals, X-Ray, synthetics, or CloudWatch alarms — belong to aws-observability. Do not start walking through Domain or Space creation until they confirm Omni; having asked, stop and wait.