Quick Start

This is the fast path through onboarding: connect your architecture, encode your objectives, generate your first guidance, and extend it into the coding workflow.

1. Stand up and connect.

   • Create your account and organization, then invite at least one teammate. Onboarding lands better as a pair: the architect who will own Context and the engineer who owns integrations.

   • Connect your first integration by following the Configure an Integration guide. Most organizations start with AWS; see Available Integrations for the full list, including Kubernetes and observability sources. Cloud integrations use read-only access, and Catio supplies the policy and role definitions.

• Create and scope your first workspace by following the Create a Workspace guide. A workspace is the architecture boundary Catio operates over: it sets which part of your infrastructure Stacks renders, Archie reasons about, and Blueprints are generated against. Scope it to a stable boundary that rarely changes once set:
  • The product line, architecture, or domain the workspace covers.
  • The durable objective that holds over the workspace's whole life, not this month's priority.
  • The primary teams working in this part of the architecture.
  • Hard boundaries: what is permanently out of scope.
    Keep evaluation rules that define what "good" looks like (budgets, timelines, policies, approved patterns) in Context, and keep point-in-time asks in the prompt you give at inference time. A useful test: if changing something would change what success means or what is allowed, create a separate workspace instead of filtering inside this one.
• Extraction begins once the integration connects and typically runs 20 to 30 minutes; track progress in the process monitor at the top right. You do not need to wait idle. Subscribe the workspace to the integration while extraction is still running by following the Enable/Disable a Subscription guide. When extraction completes, your architecture data populates Stacks and becomes available to Blueprints and Archie.

2. Encode your Context. Give Catio your objectives and constraints so guidance becomes your organization's answer instead of generic best practice. A first cut takes 30 to 60 minutes:
   • Complete the architecture context questionnaires scope, lifecycle stage, constraints, and third-party tooling.
   • Upload the documents you already have: strategy, requirements, security policies, architecture principles.
   • Write down three settled decisions your architects would state in any design review: an approved pattern, a do-not-do, and a settled trade-off with its reasoning.
     Place org-wide guidance in Global Context and workspace-specific guidance in Workspace Context, then name the person accountable for keeping Context current before moving on.
3. Talk to your architecture.
   • Ask Archie the questions your team currently routes to a senior architect, such as "What depends on this database, and what breaks if we change it?" or "Where are our biggest cost drivers in this workspace?" Answers are grounded in your Stacks and Context. See Who is Archie?. See Using Archie for Architecture Deliberation for more context!
   • Go deeper in Stacks: walk the services, dependencies, data flows, and configurations extracted from your live environment, and filter by service, region, or resource type. Follow the Using Stacks to Investigate Your Architecture guide.
   • Generate your first Blueprints, one of each subtype: a Recommendation (an optimization of your existing architecture) and a Design (a system-aligned spec generated from a real PRD or feature request). When guidance misses, it is usually a Context gap: encode the correction and regenerate.
4. Extend into the coding workflow.
   • Install the Catio MCP in a developer coding environment (Claude Code, Cursor, VSCode, Windsurf, Zed, Claude Desktop, and others). Setup takes about 15 minutes per environment. Start with one or two developers on the workspace you onboarded rather than the whole org.
   • From the IDE, pull the spec for a real ticket through the MCP. If a spec exists in Catio it returns; if not, one is generated from the ticket's PRD or feature description using full Context. Implement against it and ship the PR, referencing the design and ticket.