Enso documentation

Enso is a personal AI assistant. It connects Slack, Telegram, and background work to the agent command-line tools already installed on your machine, then runs every request in a named workspace with durable instructions, files, skills, and session state.

The short version is: you send a message, Enso routes it to the right workspace, the selected agent CLI does the work locally, and Enso delivers the result back to the conversation that asked.

Enso is in pre-1.0 beta, with public releases and a managed installer. Guides note features that need a newer runtime. The transactional workflows, knowledge, and memory guides cover development features that are not part of v0.1.2; release availability is stated separately from installation.

What Enso gives you

Enso adds the parts around an agent CLI that make it useful away from a terminal:

A chat front door. Talk to Claude Code, Codex, Grok, Antigravity, or OpenCode from Slack or Telegram. Cloud’s guided setup offers Claude Code and Codex.
Stable workspaces. Bind each conversation to a directory with its own purpose, instructions, skills, knowledge, drafts, and uploads.
Knowledge maintained through chat. Keep linked Markdown in shared and workspace folders, then browse it in the read-only reader; see availability.
Dated conversation recall. Find earlier requests, decisions, and reported outcomes by workspace and time with Memory, a separate development feature.
Independent conversations. Each Slack thread, direct message, or Telegram chat has a serialized queue and resumable provider session.
Scheduled work. Run the same agents from cron-style jobs, with scripts that can decide whether work is needed before a model call is made.
Follow-through. Use heartbeats for one future action or a temporary watch that ends when its outcome is reached.
Projects and tasks. Carry work through stages with written handoffs and evidence. Workflows adds optional enforced checks and configurable development flows.
Delivery and history. Send progress or results back to chat, retain job runs, and inspect what happened later.
A read-only viewer. Browse Today, tasks, heartbeats, workspaces, skills, jobs, runs, files, logs, and health in a local web interface that cannot change Enso’s state.

Enso deliberately does not replace the provider CLI. The provider still owns its login, model session, permission flags, tool access, and final answer. Enso owns the routing, queue, schedule, local working directory, delivery, and operational record around it. Start with Security and policies to choose access limits and try complete configuration examples before giving an agent sensitive work.

A concrete example

Suppose a Slack channel called #meteor-dev is bound to a workspace named meteor.

You post “Review the open release checklist and tell me what is blocked.”
Enso maps the Slack channel to ~/.enso/workspaces/meteor.
It starts the configured provider CLI with that directory as its working directory.
The agent reads the home and workspace instructions, then uses the files and skills it can see there.
Enso updates a status message while the provider streams output.
The final answer returns to the Slack thread.
A follow-up in the same thread resumes that conversation’s provider session.

A top-level message in the same channel starts a different Slack thread and therefore a different conversation. It can run independently and keeps separate session state.

Scheduled jobs use the same workspace and agent model. The difference is that nobody is waiting in chat: the scheduler starts the run, records the result, and alerts only when the configured rules say it should.

The operating model

One long-running enso serve process handles all configured chat transports and checks jobs and heartbeats once per minute. The optional web viewer runs as a separate process. Enso’s configuration and runtime state live under one home directory:

~/.enso/
├── config.json
├── AGENTS.md
├── skills/
├── workspaces/
├── jobs/
├── heartbeat/
├── browser/
├── runtime/
├── secrets/
├── enso.db
└── enso.log

Every chat binding, job, and beat points to exactly one workspace. Every provider-backed execution names a complete agent triple: provider, model, and effort. There are no hidden model fallbacks. In v0.1.2, a repo project’s task worktrees live under ~/.enso/worktrees/. The workflows implementation adds command and integration stages that run without a model, and gives new worktrees a project-selected root outside the home, <repo>/.worktrees by default.

For the precise vocabulary and both execution flows, continue to Concepts.

What Enso is not

Understanding the boundary is important, especially before unattended use.

Not a sandbox. A workspace organizes context; it does not restrict filesystem or network access. The provider CLI’s permission flags decide what the agent may do.
Not a hosted model service. Enso runs the provider CLIs you installed and authenticated. It does not hold or replace their accounts.
Not multi-user infrastructure. Enso is designed for one operator, their machine, and their agents. Cloud teams can share access to that computer, but don’t add separate users or file permissions inside it.
Knowledge remains in files. Durable knowledge lives in Markdown; instructions and skills tell the agent when to read and maintain it.
Not a control plane. The web viewer is intentionally read-only. Operational changes happen through files and the CLI.

Choose a starting path

For a cloud computer, start with Cloud getting started. It covers launch, chat connection, and provider sign-in, then points back to these same guides for everyday use. Cloud access is by private beta invite; Personal, teams, and transfers explains sharing its machines.

If you are installing for the first time:

Read Concepts for the mental model.
Follow Installation and run the guided setup.
Pair the Slack app or Telegram bot that setup asks for; Chat connections covers creating it, its tokens, and the pairing challenge.
Create or refine a workspace.
Validate the machine with enso doctor.

If Enso is already running:

Use Configuration to add a transport, binding, provider, or workspace override.
Use Jobs for standing responsibilities, Heartbeat for finite follow-ups, and Tasks and projects for work with stages.
Use Workflows to choose a simple flow, start the development preset, or add checks, human approval, and lifecycle scripts.
Use Customizing to write durable instructions and skills.
Use Knowledge for shared reference, linked pages, imports, and a consistent writing style.
Use Memory to recall dated conversations, decisions, and reported outcomes.
Use Browser for persistent local browser profiles and human sign-in.
Use the web viewer or CLI reference to inspect and troubleshoot the system.

A safe first validation

After setup, these commands give a useful health check without changing content:

enso config check
enso workspace audit
enso doctor
enso service status

Then send !help in Slack or /help in Telegram. If the conversation is bound, Enso will reply with the available chat commands. If it is not bound, each qualifying direct message or explicit mention receives an explanation instead of silently running in an arbitrary workspace.

Documentation for agents

Every rendered guide has a raw Markdown companion. The site also publishes three discovery files:

/llms.txt is the concise site-level entry point.
/docs/llms.txt lists each focused Markdown guide.
/llms-full.txt contains the entire documentation set in one file.

An agent should prefer the focused guide when the task is narrow and the complete bundle when it needs to reason across configuration, workspaces, jobs, and CLI behavior together. The Markdown pages contain the same prose as the human-readable pages, without layout or frontmatter.

Project status

Enso is MIT licensed. The public source repository, changelog, and issue tracker are available now. Cloud remains invite-only and free during beta; it uses your own AI account.