AtlasLoopOS documentation

Step-by-step guides for every product in the current catalog.

Use this page to understand prerequisites, the intended operator sequence, what to verify, and the current product boundary. Product status, application routes, capability names, and required permissions are sourced from the canonical product manifest.

Before using a Beta product: sign in, select the correct organization/workspace, confirm entitlement and required permission, configure only the providers needed by that workflow, and keep material execution behind the documented human approval and guardrail checks.
betaatlas-strategy

AtlasStrategy

Document source-backed market research, ICP, positioning, measurable goals, and a GTM play; submit it to the shared human approval gate and track the decision in Command Center.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: atlas-strategy.access.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

Strategy owners, growth leads, founders, and reviewers who need product context, market evidence, ICP, positioning, measurable goals, and a governed GTM play in one workspace.

Step-by-step

  1. 1Select an entitled organization and workspace, then open AtlasStrategy.
  2. 2Complete or review the product profile so the strategy has a defined product context.
  3. 3Add market or niche research entries with source URLs, notes, trends, and competitor evidence.
  4. 4Define the priority segment, ICP, buyer roles, pains, triggers, and exclusions.
  5. 5Document positioning, measurable goals, KPIs, and operating guardrails.
  6. 6Draft the GTM play and its hypothesis, then review the complete strategy packet.
  7. 7Submit the play to the shared approval gate; an authorized reviewer approves, rejects, or requests revision.
  8. 8Verify the decision and approved-play visibility in Command Center before downstream planning.

Verify the result

  • The product profile and research records remain scoped to the selected workspace.
  • The submitted play contains the intended ICP, positioning, goals, evidence, and hypothesis snapshot.
  • The approval decision appears in Command Center with the expected status and history.

Current boundaries

  • Research is user-provided; automated external market-database research is not part of the current Beta.
  • Approval marks a play ready for controlled planning and does not launch execution.
  • The workflow does not contact prospects, publish content, or spend budget automatically.
  • Availability depends on an eligible organization entitlement and a healthy deployment.
betaatlassocial

AtlasSocial

Plan and approve social content through permissioned workspace data, then publish approved X/Twitter posts immediately or through the durable scheduled queue when an account is authorized. Facebook, Instagram, and LinkedIn remain draft/schedule-only placeholders.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: atlassocial.access.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

Content and growth teams that need idea generation, platform-specific drafts, explicit approval, scheduling, and controlled X/Twitter publishing inside a workspace.

Step-by-step

  1. 1Select an entitled organization and workspace.
  2. 2Review the imported content sources that AtlasSocial can use for idea generation.
  3. 3If X/Twitter publishing is required, connect the workspace account through the configured OAuth flow.
  4. 4Generate post ideas from selected source IDs or the available source set.
  5. 5Generate platform captions from an idea or source and choose the intended tone.
  6. 6Review each draft and explicitly approve or reject it.
  7. 7For an approved X/Twitter draft, publish now or schedule it for the durable provider-backed queue.
  8. 8Review the scheduling calendar and draft status; treat Facebook, Instagram, and LinkedIn as draft/schedule placeholders until separate publishing integrations exist.

Verify the result

  • The selected workspace shows the intended content sources and generated drafts.
  • The X/Twitter connection reports connected before a real publish action is attempted.
  • Approved drafts show the expected approval and publish/schedule status in the workspace.

Current boundaries

  • X/Twitter is the only real publishing provider in the current Beta.
  • Facebook, Instagram, and LinkedIn remain draft/schedule-only placeholders.
  • Publishing still requires an approved draft and a configured provider connection.
  • The product does not grant unsupervised publishing permission.
betaatlasloop

AtlasLoop

Research canonical accounts, create and move versioned opportunities, record append-only revenue events, and run human-approved outreach with explicit SendGrid delivery evidence. Availability requires an eligible workspace and deployment configuration; full CRM activity management, autonomous follow-up, reply classification, FX conversion, and production service levels remain outside this Beta.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: revenue:read.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

Sales and revenue operators who need canonical accounts, a versioned opportunity pipeline, append-only revenue evidence, and human-approved outreach without a second identity model.

Step-by-step

  1. 1Select an entitled organization and workspace.
  2. 2Create or review a canonical AtlasData account and contact.
  3. 3Create an opportunity with amount, close date, stage, and working context.
  4. 4Move the opportunity through the versioned kanban and inspect stage history.
  5. 5Record expected, recognized, collected, refunded, or adjustment revenue evidence as appropriate.
  6. 6Draft outreach and submit it for a separate human approval decision.
  7. 7Send explicitly through configured SendGrid and review provider delivery or bounce evidence when the deployment is configured.

Verify the result

  • Stage changes append history and stale concurrent writes are rejected rather than silently overwritten.
  • Recognized and collected revenue remain separate from opportunity pipeline value.
  • Outreach has a human approval record before an explicit send action.

Current boundaries

  • AtlasLoop is a limited Beta rather than a full CRM.
  • SendGrid sending and provider feedback require deployment-specific configuration.
  • No opportunity movement, revenue recognition, outreach, or follow-up occurs autonomously.
  • Reply ingestion, generalized activity management, AI forecasting, and FX conversion are outside the current Beta.
betaatlaswatch

AtlasWatch

Monitor configured GTM accounts, syncs, pages, and operational signals that require attention. Availability depends on enabled data sources and workspace configuration.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: atlaswatch.access.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

Growth and operations teams that need a workspace-scoped review surface for configured tracking, sync, connection, page, checkout, and abnormal-behavior signals.

Step-by-step

  1. 1Select an entitled organization and workspace.
  2. 2Open the AtlasWatch dashboard and review open-alert, critical-alert, and health-check counts.
  3. 3Inspect the latest configured checks, including status, severity, observed value, and check time.
  4. 4Review alert history to understand which issues are open, warning, failed, or resolved.
  5. 5Open the AtlasSignals assignment workflow when a canonical signal needs an owner.
  6. 6Review assignment history and route qualified signals into a governed AtlasCampaigns draft when appropriate.
  7. 7Return to AtlasWatch after the underlying source updates and confirm the recorded check or alert state changed as expected.

Verify the result

  • The selected workspace contains only its own checks, alerts, and assignments.
  • Alert and check timestamps correspond to the expected configured source updates.
  • Any campaign play created from a signal still enters the normal governed approval flow.

Current boundaries

  • AtlasWatch reviews stored checks supplied by configured sources; the screen does not itself prove third-party tracking or checkout health.
  • Brand and platform names in stored checks do not imply a live connector is enabled.
  • The product surfaces attention signals but does not autonomously repair integrations or launch campaigns.
betaatlaspipe

AtlasData

Create tenant-scoped data sources, upload UTF-8 CSV files, preview detected columns and types, review every mapping, validate rows, import normalized GTM records, and inspect synchronization evidence. Tokenized webhook intake is implemented; Google Ads, Meta Ads, GA4, HubSpot, and Pipedrive remain explicit non-executable placeholders.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: atlaspipe.access.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

Operators who need a controlled data-ingestion path with preview, mapping, validation, deduplication, canonical account/contact records, and synchronization evidence.

Step-by-step

  1. 1Select an entitled workspace and create or choose a tenant-scoped AtlasData source.
  2. 2Upload a UTF-8 CSV file and wait for the bounded durable preview.
  3. 3Review detected columns, inferred types, and the staged upload identifier before importing anything.
  4. 4Map source columns to the supported canonical account and contact fields.
  5. 5Review validation and deduplication behavior, then confirm the staged upload once.
  6. 6Inspect imported, failed, and duplicate counts plus row-level synchronization evidence.
  7. 7Use the source, mapping, sync-log, and data-health views to correct issues and verify the normalized result.
  8. 8For machine intake, create and inspect a tokenized webhook endpoint only inside an authorized workspace.

Verify the result

  • The preview and confirmed import refer to the same staged upload.
  • Imported contacts/accounts preserve source and upload provenance without creating unexpected duplicates.
  • Sync logs show imported, rejected, and duplicate counts that match the confirmed operation.

Current boundaries

  • The stable internal key and API namespace remain atlaspipe for compatibility.
  • Google Ads, Meta Ads, GA4, HubSpot, and Pipedrive are explicit non-executable placeholders in the current Beta.
  • A named connector in the UI does not confirm that the connector is enabled.
  • Limited Beta status does not represent a production service-level commitment.
betaatlasloopos

AtlasLoopOS

Operate paid-media intelligence, approval workflows, configured integrations, and AI-assisted GTM workflow coordination. Optional automotive and inventory context is handled separately as AtlasCommerce after enablement.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: atlasloopos.access.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

Growth teams, agencies, and operators that need workspace analytics, approval queues, agent-assisted workflows, integrations, feeds, and an auditable activity timeline under explicit access controls.

Step-by-step

  1. 1Sign in, select an entitled organization and workspace, and open Command Center.
  2. 2Review the month-to-date spend, leads, calls, and CPL summary available for the selected workspace.
  3. 3Inspect the unified activity timeline to understand recent governed work and recorded lifecycle events.
  4. 4Review pending GTM play approvals and explicitly approve, reject, or revise material moves through the approval workflow.
  5. 5Open Agents only for permitted, configured workflows and keep material execution behind the applicable approval and guardrail checks.
  6. 6Use Feeds, Ask AtlasLoopOS, Analytics, and Integrations for the data and provider context enabled in the deployed environment.
  7. 7Return to Command Center to verify the recorded activity, approvals, and available outcome metrics after controlled actions complete.

Verify the result

  • Command Center metrics load for the selected workspace rather than another tenant.
  • Approval decisions and material workflow events appear in the activity trail.
  • Provider-backed actions are attempted only after the required entitlement, permission, configuration, and approval checks pass.

Current boundaries

  • Available analytics and provider behavior depend on the deployed environment and configured integrations.
  • Interface visibility does not prove that a provider connector or customer credential is configured.
  • Optional commerce and inventory behavior remains separated behind AtlasCommerce boundaries and entitlements.
  • The platform does not claim unsupervised campaign execution for material moves.
coming soonai_sales_manager

AI Sales Manager

Coordinate lead response, follow-up, pipeline visibility, and sales coaching through AI-assisted sales workflows connected to the shared platform after the capability is shipped.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: coming soon.
  • • Required permission: ai_sales_manager.access.
  • • No executable customer workflow is claimed while this product remains Coming soon.

Intended operator

Teams interested in a future lead-response, follow-up, pipeline-visibility, and sales-coaching workflow built on the shared AtlasLoopOS platform.

Step-by-step

  1. 1Open the Product catalog and confirm that AI Sales Manager is still labelled Coming soon.
  2. 2Review the public product description and planned capability boundary without treating it as an enabled workflow.
  3. 3Request availability if the planned product is relevant to your organization.
  4. 4Do not configure production processes around this product until an executable surface, entitlement path, and updated documentation are shipped.
  5. 5When the status changes in the canonical product manifest, follow the then-current documentation rather than this roadmap description.

Verify the result

  • The public catalogue continues to show Coming soon until the canonical manifest is intentionally changed.
  • No user should be told that a roadmap capability is available merely because a route or capability name exists.

Current boundaries

  • There is no executable customer workflow represented by the current product manifest status.
  • No production use, provider coverage, pricing, service level, or autonomous follow-up is claimed.
  • The application route is a roadmap placeholder until implementation is shipped and documented.
betaatlasinventory

AtlasCommerce

Connect supported commerce providers, normalize catalogue and inventory evidence, monitor WooCommerce low-stock events, create or resolve canonical AtlasSignals records, and project explicit AtlasCampaigns eligibility and buyability without rewriting approvals or published history. Access requires an eligible organization; provider parity, advanced feeds, forecasting, and production service levels remain outside this Beta.

Prerequisites

  • • Correct organization and workspace selected.
  • • Product status: beta.
  • • Required permission: atlasinventory.access.
  • • Any provider-specific credentials or OAuth connection required by the workflow must be configured for this workspace.

Intended operator

Commerce operators, growth teams, agencies, and campaign reviewers that need catalogue evidence, inventory monitoring, low-stock signals, and fail-closed campaign eligibility.

Step-by-step

  1. 1Select an eligible organization/workspace and open AtlasCommerce.
  2. 2Connect a supported commerce provider with the provider-appropriate tenant-bound credentials or OAuth flow.
  3. 3Run the initial catalogue synchronization and review normalized product, price, availability, inventory, category, image, variant, and sync evidence.
  4. 4For the hardened WooCommerce path, set or review the low-stock threshold and synchronize current quantities.
  5. 5Inspect open or resolved inventory events and the corresponding canonical AtlasSignals low-stock record.
  6. 6Review AtlasCampaigns eligibility and buyability for product-linked work; new execution fails closed while inventory is unsafe.
  7. 7After stock recovers, synchronize again and verify that the event/signal resolves and future eligibility is restored without rewriting approvals or published history.
  8. 8Inspect tenant-scoped audit evidence for connection, sync, threshold, inventory-event, eligibility, and buyability transitions.

Verify the result

  • The store connection validates before service-only encrypted credentials are retained.
  • Repeated catalogue syncs update canonical products rather than creating duplicate product identities.
  • Low-stock and recovery transitions update the same event/signal lineage and preserve prior audit evidence.
  • Campaign buyability blocks only new unsafe product-linked execution and does not rewrite approved or published history.

Current boundaries

  • AtlasCommerce is a Beta product and does not represent a public production service-level commitment.
  • The first hardened stock-to-signal-to-campaign workflow is WooCommerce; exact Shopify and Magento parity remains open.
  • Location safety stock, reservations, bundles, advanced salability, forecasting, and autonomous replenishment are outside the current Beta.
  • The product does not autonomously change campaign approval, copy, budget, publishing history, or replenishment orders.