---
title: "Platform overview"
description: "What AlisX is, the eight tools on the bench (the Skill Store, the three Alis Ideate tools, the three Alis Build tools and AlisX Specialists), how a project runs through them, and where the console, the CLI and the TUI each belong."
url: "https://docs.alisx.com/explanation/platform-overview/"
---
# Platform overview

AlisX is the agent-native platform that brings structure to how and where you and your teams work with your AI tools, so work goes further, moves faster and happens safer. Intelligence without structure is costly chaos: ask a coding agent to write the requirements for a dashboard and it answers with its own limits. It can only read what is in the chat. It does not know what a good requirements document looks like here. It cannot see what another team worked out last quarter. It has nowhere approved to deploy. AlisX gives each of those limits a tool, and this page gives you the shape of the platform before you touch any part of it.

## One bench, eight tools

Think of AlisX as a bench your team and your agents work at. Eight tools sit on it: two families of three, for context and for code, and two that serve both. Whichever door you come in by, the whole bench is yours: one account, one plan, one credit balance, and one active account that every tool reads.

```mermaid
flowchart TB
    S["Skill Store<br><small>knowledge and know-how</small>"]:::cat3
    X["AlisX Specialists<br><small>the right people to ask</small>"]:::cat2
    subgraph Bench[" "]
        direction LR
        subgraph Build["The Alis Build tools: code"]
            direction TB
            B1[Alis Build Environments]:::cat1 --> B2[Alis Build Workstations]:::cat1 --> B3[Alis Build DBD]:::cat1
        end
        subgraph Ideate["The Alis Ideate tools: context"]
            direction TB
            I1[Alis Ideate Interviews]:::cat4 --> I2[Alis Ideate Projects]:::cat4 --> I3[Alis Ideate Artifacts]:::cat4
        end
        Ideate --> Build
        Build -. what people see .-> Ideate
    end
    S -.-> Bench
    X -.-> Bench
```

**The Skill Store** is knowledge and know-how. Someone in your organisation already knows the best way to write a requirements document or set up a service; the Store makes that the way every AI in the company works. A skill is a curated instruction document, with optional resource files and code templates, that an agent finds mid-session and loads live. Skills come in four layers: yours, private until you share them; your team's, improved together; the community's, vetted and with provenance; and the platform's, published by Alis Exchange to every builder. Every publish is scanned and every version kept. See [Agents, skills and the CLI](https://docs.alisx.com/explanation/agents-skills-cli.md) and [Discover and load skills](https://docs.alisx.com/how-to/skill-store/discover-and-load-skills.md).

**Alis Ideate Interviews** let an AI interviewer talk to each person who knows the work, individually, in their own language and in their own time, and ask follow-ups about what they share.

**Alis Ideate Projects** keep everything the work touches together, recordings, documents, spreadsheets, notes and interviews, and serve a compact map to people and agents so they fetch detail only when a job needs it.

**Alis Ideate Artifacts** turn that context into documents, specs and prototypes that others can review and act on, each traceable to what people said. The three together are the Alis Ideate tools, for context; see [Context before code](https://docs.alisx.com/explanation/ideate.md).

**Alis Build Environments** give people and agents a secure place to build together in your own Google Cloud, under your own IAM and audit trail, with private Git, shared build and deployment workflows and ring-fenced infrastructure to deploy into. See [Organisations, products and services](https://docs.alisx.com/explanation/organisations-products-services.md).

**Alis Build Workstations** are machines of your own inside a build environment, with a terminal in the browser or ssh from your laptop, that keep your agent running after the laptop shuts.

**Alis Build DBD** is Define, Build, Deploy: a typed contract compiled into versioned packages, a pushed commit built into an immutable version, and a Terraform deploy with a plan to read first and a person before production. The three together are the Alis Build tools, for code; see [Define, Build, Deploy](https://docs.alisx.com/explanation/define-build-deploy.md).

**AlisX Specialists** are the right people to ask. When you or your agent need another person, AlisX routes you to a working Builder who answers: someone on your own team, or the Alis Build platform team. You reach them from the console or by sharing a session from the CLI, and a human reads the ticket first, including tickets written by agents. See [Get support](https://docs.alisx.com/how-to/help/get-support.md).

**Alis** is the agent you work with in the console. You chat with Alis from the navigation pane or from inside a project: Alis reads what your projects hold, answers from it with citations, and when you say so, starts interviews and research and writes artifacts. Alis also runs the interviews themselves. On these pages, "Alis" on its own always means the agent; the company is Alis Exchange.

Every tool shares the account, the plan, the credit balance, the people, the console and the CLI. The two families part in one place, access: an admin grants a member Ideate access, for the Alis Ideate tools, and Build access, for the Alis Build tools, separately, because the two carry different costs and consequences. See [Accounts and billing](https://docs.alisx.com/explanation/accounts-and-billing.md).

## How a project runs on AlisX

Software projects lose most of their time in translation: from what a customer said, to what someone wrote down, to what a team built, to what is running. AlisX treats the whole of it as one loop with nine stages, and each stage names the tool that does the work. The Skill Store holds skills for every stage; `alis skills search` finds them.

1. **Capture.** An Interview asks everyone who touches the work, in their own words and in their own time, and keeps every answer in one Project. What keeps coming up is visible before you commit to anything.
2. **Describe.** The Project already holds who said what and the documents you loaded. An Interview puts the wording back to the people who raised it until the problem is one the organisation recognises.
3. **Decide.** The business case is an Artifact: what the problem costs today, worked out from the time of the people who carry it, shared by link with whoever holds the budget.
4. **Define.** An Interview walks the current way of working with the people who do it. Then an Artifact puts a prototype in front of the people who will use it, so they sign off on something real rather than a document.
5. **Design.** The Skill Store gives your agent the standards your architects already wrote, so the plan comes back inside your rules. A Specialist reviews it in the same session before the team commits to anything.
6. **Build.** A Build Environment gives the work a secure place in your own cloud, and a Workstation keeps your agent going after you close the laptop. Every change goes through DBD. When the plan runs out, the agent knows from the Project who defined the line, and asks them.
7. **Verify.** DBD puts the working piece in a development environment. An Interview takes it back to the people who defined done, and records what they accept and what they send back, line by line.
8. **Launch.** DBD releases into production in your own cloud, on a person's explicit approval. An Artifact carries the change note to the people it affects, and an Interview a fortnight later asks whether it stuck.
9. **Review.** An Interview goes back to the sponsor who said yes and the team who built it, and the Project holds their answers against the business case it started from. What you would do differently becomes a skill in the Store, and new problems go back into Capture.

## Where your work lives

Everything you make with the Alis Build tools belongs to a **build environment**, which resource names and the `alis org` command call an organisation. A build environment owns **products**. A product works out of two Git repositories: the build environment's definitions repository (the protobuf contracts) and the product's own build repository (the implementation). Inside a product, each **service** is a unit that is defined, built and deployed on its own. Services are versioned, and versions are deployed into **deployment environments**, which are your own cloud projects. See [Organisations, products and services](https://docs.alisx.com/explanation/organisations-products-services.md) and [Deployment environments and versions](https://docs.alisx.com/explanation/environments-and-versions.md).

Everything you make with the Alis Ideate tools belongs to a **project**, which holds its people, contributions, interviews, research and artifacts.

Alongside both, an **account** holds the people. An account has members, each with a role and with Ideate access, Build access or both. Every user works against an active account: every tool's usage is measured against it, and the account receives an invoice at the end of each month for its users' spend. See [Accounts and billing](https://docs.alisx.com/explanation/accounts-and-billing.md).

## Three interfaces, one platform

The same platform is reachable in three ways, and each one is designed for a different kind of user.

| Interface | Made for | Where |
|---|---|---|
| The console | People working in a browser: sign-up, account admin, the Alis Ideate tools, the Alis Build dashboards, the Skill Store, Specialist conversations | [console.alisx.com](https://console.alisx.com) |
| The CLI | Scripts and coding agents: deterministic commands, one JSON object per result, exit codes | `alis <command>` in a terminal |
| The TUI | People working in a terminal: products, services, versions, builds, logs, support | `alis` with no arguments |

The console is the front door: it is where you create an account and where recordings are made and interviews are set up and taken. The CLI and the TUI are the same binary. Run it with a command and it behaves like a tool built for automation; run it with nothing and it opens a full-screen interface for a person. See [Agents, skills and the CLI](https://docs.alisx.com/explanation/agents-skills-cli.md) for why the CLI is designed the way it is.

Bring the agent you already have. An agent with a shell, such as Claude Code, Codex, Gemini CLI, Cursor or OpenCode, works through the CLI. The CLI carries its own operating manual (`alis docs`), resolves context from the directory it runs in, and streams progress on stderr while keeping a single machine-readable result on stdout. For agents with no shell, the Alis Build MCP server offers the same Define, Build and Deploy operations remotely.

## What stays yours

Your protobuf definitions, your implementation, your Dockerfiles and your Terraform live in your own repositories. Your services deploy into cloud environments that you own, under your own IAM. Your skills stay private until you share them. AlisX provides the structure: it compiles and publishes your contract, builds your images from commits you pushed, applies your Terraform with the variables it injects, records every version and deployment so you can see what is running where, and keeps every interview, decision and skill with the company, even when people move on.

## Where to go next

- New to the platform: [Create your account](https://docs.alisx.com/tutorials/create-your-account.md), then [Install the CLI](https://docs.alisx.com/tutorials/install-the-cli.md).
- Here to capture knowledge: [Your first project](https://docs.alisx.com/tutorials/first-ideate-project.md).
- Here to ship software: [Ship your first service](https://docs.alisx.com/tutorials/first-build-service.md).
- Setting up an agent: [Work with a coding agent](https://docs.alisx.com/tutorials/work-with-a-coding-agent.md).