Getting started

Availability: This guide supports existing or invited Tedix organizations. The standalone CLI is public beta; the source repository and supported self-hosted releases remain private. See Release status.

Try the Cloud beta

Open Tedix Cloud with your invited account and choose your organization. If none is available, ask the person who invited you to confirm your access; signing in alone does not provision an organization.

Use the walkthrough below in the same Cloud conversation or through the CLI. Local source exploration is optional; it is not required to evaluate Cloud.

One task, two turns

Use a synthetic brief first; no company documents or connectors are needed:

Draft a 30-minute agenda for evaluating a new supplier. Cover delivery reliability, pricing, and support. Include time allocations adding to 30 minutes and three unanswered questions. Use only this brief; do not invent supplier facts, call tools, send messages, or create files.

Then, in the same conversation:

Revise that agenda to 20 minutes. Keep all three evaluation topics and the same three unanswered questions. Use only this conversation; do not call tools.

Check that the minutes add up, the three topics remain, and no supplier facts were invented. You should be able to use or revise the draft immediately.

In the CLI, after signing in, reuse one named thread for both prompts:

tedix -w acme ask --thread supplier-agenda "YOUR_FIRST_PROMPT"
tedix -w acme ask --thread supplier-agenda "YOUR_REVISION_PROMPT"
tedix -w acme inspect HOME_RUN_ID

acme is your saved organization connection, not a new workspace. Replace the prompt placeholders with the text above and inspect the run ID returned by each turn. Read the outcome and routing information: this small task can answer in Home without delegating to a tedi or invoking a tool.

Observed on 20 September 2026: a maintainer ran these two turns against an existing Cloud organization. Both completed as answer_in_home. The reply kept all three questions and changed the time allocations as follows:

The three questions asked for delivery-performance evidence, pricing assumptions and additional charges, and support response/escalation commitments. This is a small observed drafting-and-revision example, not a new-user onboarding test, a connector demonstration, or proof that the system learns every interaction.

Conversation continuity is not automatic permanent learning. Recent messages can be replayed or compacted; organizational facts and reusable skills have separate storage and selection. Model replies can be wrong, and a completed run does not independently certify their contents.

For the code behind these steps, follow one request through Tedix.

Evaluate Tedix locally with private-beta source access

With private-beta repository access, install the public CLI and run setup from any directory. Bun, genuine Node.js 22+, and Git must be on PATH:

The first setup needs network access to download source and dependencies, even when you choose offline mode. Offline mode disables model calls.

tedix setup

Setup uses an existing checkout or downloads the source matching your CLI release through your Git credentials, then guides offline or own-account AI selection. It verifies the downloaded commit before starting the local product and opens the browser when ready. No tedix login is required.

For offline onboarding without prompts, run tedix setup --yes. To choose the source location, use tedix setup --directory ~/tedix-local. Later, tedix dev resumes the saved installation and selected mode from any directory. Within a source checkout, it runs that checkout and defaults offline. Without the CLI, contributors can still run bun run-local from their checkout.

The supported trial starts from that clean exported checkout; it does not depend on a maintainer’s private Wrangler overlay, Cloudflare account, or Tedix production credentials.

Open the Tedix OS URL printed by the launcher, name your local OS, and enter its empty workspace. The first run creates the isolated organization, owner membership, and personal tedi through canonical API contracts. It starts the API on Cloudflare’s local workerd runtime and connects the Tedix OS to that isolated API and D1 through a same-origin loopback proxy. It requires no credentials and never contacts a Cloudflare account. State persists under .wrangler/run-local. bun run-local --smoke starts with a temporary empty D1, completes the same onboarding, proves no sample Workspace was imported, then checks the OS shell, D1 Workspace write, favorite, authenticated API, and cross-boundary readback before exiting.

Use bun run-local --demo only when you want the deterministic Local Tedix, Revenue Ops, and Local Shared Draft sample state. That lane persists separately under .wrangler/run-local-demo.

For a first offline task, choose New workspace, name it Supplier review, and describe the decision you need to make before your next order. Save it, return to Workspaces, and reopen it. The name and description should remain after a refresh or a tedix dev restart. You have saved a working context; generating an agenda requires the inference option below.

To opt into paid Workers AI, authenticate with bunx wrangler login, find your account ID with bunx wrangler whoami, then run tedix dev --inference --account-id <32-character-account-id>. This adds only remote inference; D1 and the local product state remain on your machine. No secret provider or Tedix Cloud account is needed. It does not deploy an installation or configure external connectors.

To send Workers AI requests through your own AI Gateway, add its ID from the same Cloudflare account:

tedix dev --inference --account-id <32-character-account-id> --ai-gateway <gateway-id>
# From source without the CLI:
bun run-local --inference --workers-ai-account=<32-character-account-id> --ai-gateway=<gateway-id>

tedix setup also offers the optional gateway and remembers it with your local installation. Wrangler handles authentication; these commands do not need Tedix credentials or a secret provider. Model calls leave your machine and are billed to your Cloudflare account; product data bindings remain local. A configured gateway does not establish successful inference: send a small synthetic prompt and check its response and your gateway logs.

With inference enabled, Home can propose local tool actions for your approval, including saving a document. The launcher also starts MCP on port 3000. After creating your local organization, a coding agent can discover its tools:

TEDIX_MCP_URL=<local-gateway-url> \
TEDIX_MCP_BEARER_TOKEN=tedix-local-demo \
tedix code 'async () => await discover.search({query: "get_os_output", limit: 2})'

Replace the URL with your local gateway address from Gateways. The demo credential works only locally. Use Cloud login for Cloud organizations.

The local trial proves first-run onboarding, the Tedix OS shell, durable Workspace and preference writes, the API authentication boundary, migrations, and D1-backed product reads. It deliberately does not claim remote tedi execution or provider-backed capabilities; those require the customer-owned accounts described in the self-hosting guides.

Without private-beta source access, begin with the public CLI and an existing Tedix organization below. Clone instructions will replace this note once Tedix publishes the governed export described in Release status.

1. Install and verify the CLI

curl -fsSL https://downloads.tedix.dev/install.sh | sh

The installer puts tedix in ~/.local/bin, which is not on the default macOS PATH, so it also adds that directory to your shell profile and prints what it changed. Open a new terminal, then verify:

command -v tedix
tedix --version

The standalone CLI includes its runtime dependencies. For exact versions, checksums, PATH options, updates, and rollback, see Install the Tedix CLI.

2. Sign in to your organization

Run the ordinary login command. Tedix OS opens in your browser and lists the organizations available to your account. Choose the organization this terminal should use (for example, acme):

tedix login
tedix -w acme auth status

For scripts or other non-interactive terminals, provide the same slug on the command line:

tedix login acme

Login uses browser-backed OAuth. The workspace stores the resulting grant locally; it does not contain a credential compiled into the binary. auth status shows the selected workspace and gateway without printing the secret. The browser returns only the selected organization slug through a one-time local callback. The CLI resolves the organization’s public MCP gateway before OAuth, so an ordinary member does not need a Tedix platform-administrator login first.

3. Run one durable Home turn

Home is the governed conversation and execution lane. Use it when work needs rationale, durable run state, approvals, delegation, or evidence:

tedix -w acme ask "Explain the workers and applications available to me."

The CLI waits for authoritative settlement and returns a non-zero exit code if the run fails or is cancelled. A timeout means the run may still be active; inspect it rather than sending the same request again.

Useful readbacks:

tedix -w acme status
tedix -w acme runs
tedix -w acme inspect HOME_RUN_ID
tedix -w acme tail HOME_RUN_ID --no-follow

4. Discover a direct capability

Code Mode calls the organization MCP gateway directly without creating a Home run. Use it for bounded discovery and stateless reads where you already own the decision and do not need a durable rationale trail.

tedix -w acme code \
  'async () => await discover.search({ query: "calendar", limit: 5 })'

Ask for an exact parameter schema only after discovery identifies the callable:

tedix -w acme code \
  'async () => await discover.search({ query: "calendar events", limit: 2, includeParameters: true })'

Do not guess tool names or arguments. Call the exact namespaced callable returned by discovery. Treat every write-capable call as a real production mutation and obtain the required approval before invoking it.

5. Understand the proof boundary

A successful dispatch is not proof that the intended outcome happened. For material work, inspect the settled run, its artifacts, approval decisions, and completion evidence. A result may explicitly list supported and unsupported claims; report only what the evidence supports.

The full accountability chain for delegated work is:

1. the request and the Work Item identify the objective, owner-held risk, and accountable executor;
2. an independent principal grants any required approval — never the requester;
3. the tedi executes within the admitted scope;
4. an external effect is proven only by an explicit provider confirmation or provider reference, not by dispatch or local settlement alone;
5. rationale, artifacts, and evidence preserve what was decided and observed;
6. a later contradiction or correction remains attached to the durable record.

Not every task needs every step. The supplier-agenda walkthrough above stays in Home and demonstrates conversation continuity plus inspectable run records; it does not create a Work Item, invoke a provider, or demonstrate the full chain.

Verify one provider-backed chain

For a protected skill workflow that is already authorized to send one real Gmail message, retain the three canonical readbacks instead of writing a separate proof narrative. Replace the ID placeholders with the linked Work Item and workflow run:

tedix -w acme work context WORK_ITEM_ID --json > work-context.json
tedix -w acme work approval-audit-list \
  --input '{"workItemId":"WORK_ITEM_ID","statuses":["approved"],"limit":10}' \
  --json > approval-audit.json
tedix -w acme skill inspect RUN_ID --json > workflow-inspection.json

bun scripts/harness/verify-accountability-chain.ts \
  --work-context work-context.json \
  --approval-audit approval-audit.json \
  --workflow-inspection workflow-inspection.json \
  --namespace gmail \
  --method gmail_send

The verifier requires the Work Item to name its accountable owner, risk, and accepted outcome; an approved decision by a principal other than the requester; a completed linked workflow run; pinned workflow and skill hashes; input and terminal artifacts; and a successful call in the current execution epoch whose canonical receipt carries a non-unknown provider confirmation. It rejects a dispatch ID, local settlement, arbitrary result ID, or confirmation from an old restart epoch as proof of the external effect.

A passing synthetic test is only checker validation. Call the chain provider-backed only after the workflow made the authorized external change and fresh readbacks from that run pass. If later evidence disproves the result, record the correction against the Work Item with work confirm --contradicts; do not edit the captured provider receipt.

Next:

• learn the core concepts;
• choose between skills, automations, flows, and runs;
• understand governance and audit;
• see how MCP applications expose tools;
• give a coding or research agent the agent guide.