Enso documentation

Enso is a personal agent host. It connects Slack, Telegram, and a cron scheduler 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 currently 0.1.0 and pre-production. CLI names, configuration, and the home layout may change without a migration path. The documentation describes the current working tree and is the public source of truth for this version.

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, or Grok from Slack or Telegram.
• Stable workspaces. Bind each conversation to a directory with its own purpose, instructions, skills, knowledge, drafts, and uploads.
• 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.
• Delivery and history. Send progress or results back to chat, retain job runs, and inspect what happened later.
• A read-only viewer. Browse 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.

A concrete example

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

1. You post “Review the open release checklist and tell me what is blocked.”
2. Enso maps the Slack channel to ~/.enso/workspaces/meteor.
3. It starts the configured provider CLI with that directory as its working directory.
4. The agent reads the home and workspace instructions, then uses the files and skills it can see there.
5. Enso updates a status message while the provider streams output.
6. The final answer returns to the Slack thread.
7. 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 once per minute. The optional web viewer runs as a separate process. Everything Enso owns is stored under one home directory:

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

Every chat binding and every job points to exactly one workspace. Every execution names a complete agent triple: provider, model, and effort. There are no hidden model fallbacks.

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.
• Not a content management system. Durable reference material is a Markdown file in a workspace; instructions and skills tell the agent when to read 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:

1. Read Concepts for the mental model.
2. Follow Installation and run the guided setup.
3. Create or refine a workspace.
4. Validate the machine with enso doctor.

If Enso is already running:

• Use Configuration to add a transport, binding, provider, or workspace override.
• Use Jobs to automate recurring work.
• Use Customizing to write durable instructions and skills.
• 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 0.1.0 currently includes Slack and Telegram transports, resumable conversations, scheduled jobs, prerun and postrun scripts, run history, message and Slack helpers, custom tables, service management, workspace auditing, and the read-only viewer.

The project is MIT licensed. Source, changelog, and issue tracking are intended to live in the Enso GitHub repository once the project is published.