Why a CLI
When we shipped Atlas App -- our visual AI workspace -- developer adoption was slower than expected. Exit interviews revealed a consistent pattern: developers do not want to switch contexts to use AI. They live in their terminal, their editor, their CI pipeline. Asking them to open a separate application creates friction that compounds across hundreds of daily interactions.
The friction is not really about the application. It is about the shape of the work. A developer debugging a failing deploy is holding a stack of context -- which branch, which service, what changed, what the logs said thirty seconds ago. Moving to a chat window means rebuilding that context by hand, in prose, for a system that could have read it directly.
Atlas CLI brings the model orchestration layer into the environment where that context already exists.
Core capabilities
# Query any Atlas model with organizational context
atlas ask "What is our current test coverage policy?"# Invoke a named agent with structured input atlas agent run code-reviewer --file src/api/payments.ts
# Search the organizational knowledge base atlas knowledge search "deployment runbook for payment service"
# Chain operations in scripts atlas ask "Generate a PR description for:" < git diff HEAD~1 | atlas format markdown ```
Atlas CLI authenticates using your organization's identity provider, pulls in your team's knowledge base context, and routes each request through the appropriate Atlas model based on the nature of the task.
Context-aware by default
The most useful property of a terminal-resident tool is that the context is already there. Before sending a query, the CLI can read the current directory, recent git history, and active branch to build a context payload.
A question like "is this change safe to deploy?" becomes materially more useful when the model knows you are in the payments service, on a hotfix branch, on a Friday afternoon. None of that had to be typed. The same question asked in a chat window is a different, weaker question, because the human has to reconstruct the situation first and will inevitably leave things out.
This is the general argument for meeting AI where work happens rather than relocating work to where the AI is.
Designed for scripts, not sessions
A chat interface assumes a human is waiting. A command-line tool cannot assume that, and designing for the difference matters more than it first appears.
- Everything composes. Reading from standard input and writing to standard output means Atlas CLI participates in pipelines rather than replacing them. The output of a diff becomes the input to a review; the output of that becomes a comment.
- Exit codes carry meaning. A command that cannot distinguish success from failure cannot be used in automation. A review that finds blocking issues should be able to fail a pipeline stage.
- Output is parseable. Prose is fine for a human reading a terminal. Anything a script consumes needs structure, which is why formatted output modes matter more than they look.
- Runs are reproducible. The same command against the same repository state should behave consistently enough that a failure is a signal rather than noise.
These constraints are unglamorous, and they are the difference between a tool developers try once and a tool that ends up in a pipeline.
Authentication in an enterprise environment
Terminal tools have a long history of encouraging bad credential habits: long-lived tokens pasted into shell profiles, secrets committed to repositories, shared service accounts nobody can attribute.
The safer pattern is short-lived, scoped credentials issued through the organization's existing identity provider, with the scope tied to the person rather than the machine. The practical consequences are worth stating plainly:
- 1A token that expires quickly limits the blast radius of a leaked credential.
- 2Scoping to the human, not the host, means audit logs attribute actions to a person.
- 3Access is revoked centrally when someone changes team or leaves, without hunting through developer machines.
- 4CI environments get their own scoped identity rather than borrowing a developer's.
This is the same access control model applied throughout the platform. A terminal is not a reason to weaken it.
Using it in continuous integration
The CLI becomes most valuable when nobody is watching it run. Common patterns:
- Pull request summarization. Generate a description from the diff so reviewers start with context rather than reconstructing intent.
- Review assistance. Surface likely issues before a human reviewer spends attention on them, without blocking on the model's judgement.
- Release notes. Assemble a changelog from commits and tickets, in the house format, as part of the release job.
- Incident summaries. Collapse a long alert and log trail into a readable summary at the point an incident is declared.
The important design rule for all of these: AI-generated output should be a starting point that a human edits, not a gate that silently blocks work. Automation that cannot be overridden gets disabled.
What a CLI is not good at
Being honest about this makes the tool more useful, not less.
Terminals are poor at reviewing long outputs, comparing alternatives side by side, and any task where the answer is visual. Reading two thousand words of analysis in a scrolling buffer is worse than reading it in a document. Work that involves iterating on a draft, exploring a knowledge base, or collaborating with colleagues belongs in Atlas App, which shares the same intelligence layer and the same organizational knowledge.
The two are surfaces onto one system rather than competing products. Work started in one is visible in the other, and choosing between them is a question of what the task looks like, not which tool you have adopted.
Integration with existing tools
Atlas CLI ships with pre-built integrations for: - GitHub and GitLab (PR descriptions, code review summaries, issue triage) - Jira and Linear (ticket generation, sprint planning assistance) - PagerDuty and Opsgenie (incident summary generation, runbook lookup) - Datadog and Grafana (anomaly explanation, threshold recommendations)
Each integration reads from your organization's configured data sources through Atlas Secure's access control layer, so the model only sees data the current user is authorized to access. An integration that bypassed that boundary would be a liability regardless of how convenient it felt.
What is coming
The next major release will ship agent composition from the command line -- chaining multiple agents using Unix-style pipes, with observability into each agent's reasoning trace. We are also working on a watch mode that monitors file changes and surfaces suggestions without requiring explicit invocation.
