Docs

How xTerminal holds the state of a custom site: who can change what, how Requests ship, and where agents work.

Popular

Basics

What xTerminal is

A control panel for a custom-built website. State, custody, and ops. Not an AI website builder.

How xTerminal works

The stack: a dashboard for state, a connected custom site, Requests, a Knowledge Base, and a worker that still comes back to a person.

Quick start

Create an account, verify email, then billing. Managed signup is operator-gated today.

Your first site

The dashboard is ready after billing. A developer connects the custom site. You run it from there.

Managed vs other paths

Foundation, Advanced, and Managed. Requests are a Managed capability. Prices on marketing cards are not a locked billing contract.

Roles and permissions

Owner, admin, and developer are people on the site. Workers and agents act through a key the developer mints.

The Request loop

Compose, worker, review, then Ship to live. A person stays in the loop.

Servicing requests

A person and a worker share one board. The worker builds. A person still reviews. Ship to live is a separate ask.

Request a change vs Edit

Edit is for content already on the page. Request a change is for everything else, when Requests is on.

Delivery note / proof

The review card is the proof: headline, how to check, and what changed. Preview sits next to it.

Control panel vs developer lane

Owners run the site from the dashboard. Developers hold the repo. The client never sees GitHub.

Connect a site

A developer wires the custom site to this dashboard. Owners invite that person. xTerminal does not generate the site.

Domains, hosting, custody

The developer lane holds the host and the domain registrar. The dashboard holds who may change the site.

What belongs in the platform

A feature belongs here if it is state, permission, or a change log. Everything else stays in the developer lane.

Knowledge Base

Per-site brand and company facts people and agents share. The dashboard editor is Coming soon.

Agents as employees

Treat a worker like a named employee: a lane, supervision first, no brand mascot in the UI.

Agent on your site

One worker per client site for ops. Keys do not stretch across sites.

Connect an agent (MCP)

Interactive agents will sign in with OAuth. Worker keys stay for headless. Wake stays a separate push. The connect pages are Coming soon.

What agents may / may not do

Workers act on Requests for one site. They cannot skip review or ship without promote.

Agents and the Knowledge Base

A Client Ops worker reads the Knowledge Base before it drafts. Missing facts escalate. Nothing is invented.

Portfolio vs Client Ops

Client Ops works one site. Portfolio watches many. Add Portfolio once. Duplicate Client Ops per site. Then connect with a worker key and wake.