Dexto
An open agent harness that turns LLMs into stateful, tool-wielding agents — YAML-defined, with a production coding agent, 50+ models, and MCP integration built in.
Evidence shows non-root container user, workspace handles rejecting paths that escape the root ('Workspace path escapes root'), and process capability only granted on explicit request — supporting a 2 for least_privilege. However, no direct evidence of user-confirmation gates, API-key protection/redaction, external-effect auditing, or rollback mechanisms; all deducted. pnpm overrides pin several historically vulnerable dependencies (tough-cookie, qs, jws), which is partial mitigation, not systematic supply-chain management. Author field is empty; attribution incomplete.
Integration tests target real contracts (bundled artifact loading, path-escape rejection, capability negotiation), giving adequate self-consistency; CI uses --frozen-lockfile and pinned Node for dependency availability; tests assert concrete error messages. Main README and full docs were not among provided files, so doc–code consistency is only partially confirmed.
Serves CLI/SDK/server/Docker usage modes with explicit engines (Node>=20); capabilities are negotiated by intent (read/process) with clear boundaries. Trigger precision lacks prompt/tool-routing evidence — deducted.
Clean monorepo layout, consistent @dexto/* naming, changesets versioning, CI build, and a thorough Docker README with compose examples justify solid install notes. License file exists but repo metadata is NOASSERTION and package. declares Elastic-2.0 (source-available, not OSI open source) — a material adoption constraint, hence 1. No known-limitations section visible. Empty author field means maintenance responsibility is only indirectly inferable.
Health endpoint, REST/SSE API, SDKs, and an agent-image bundler support a 2 for output usability; the image/skill/workspace abstractions add real value over raw MCP SDK usage. Cost-benefit evidence (token cost controls, approval overhead) is thin — deducted.
Tests map directly to claimed behaviors (path escape rejection, capability gating), making claims traceable; facts and inferences are separable. But only a subset of repo files was visible for this review, so cross-source corroboration (main README, docs/) is insufficient — deducted.
- Licensed under Elastic License 2.0 (source-available, not open source); hosting it as a managed service for third parties is prohibited — assess compliance before enterprise integration.
- Bundled tools include filesystem and process execution, and API keys are passed via plaintext .env; restrict volume mounts, egress, and rotate keys in deployment.
- No systemic evidence of user-approval gates or external-effect auditing; add host-side sandboxing before production use.
- Dependency security relies on point fixes via pnpm overrides; add lockfile auditing (e.g., pnpm audit / Dependabot).
What does this agent do, and when should you use it?
Dexto, built by Truffle AI, is an agent harness and toolkit: an orchestration layer that turns LLMs into reliable, stateful agents that take actions, remember context, and recover from errors. Written in TypeScript, it ships as a CLI, a Web UI, a REST/SSE server mode, and the @dexto/core SDK. It includes a production-ready coding agent usable immediately, capable of reading/writing/refactoring code, executing shell commands, and spawning sub-agents. Agents are defined in version-controlled YAML, letting you swap among 50+ models (OpenAI, Anthropic, Google, Groq, xAI, local Ollama/GGUF) without code changes. Dexto works as both an MCP client (30+ tool servers) and an MCP server that Claude Code or Cursor can consume. Note that it is licensed under Elastic License 2.0 rather than a standard open-source license.
Dexto reads a YAML agent config (llm, mcpServers, permissions, storage) and instantiates an agent from it. At runtime it calls the configured LLM provider's API, connects to Model Context Protocol servers via MCPManager (e.g., filesystem, Puppeteer browser), executes tool calls, and enforces human-in-the-loop approvals (manual or auto-approve modes with toolPolicies). Sessions and memories persist across restarts in Redis/PostgreSQL/SQLite or in-memory backends, supporting dexto -c to continue, dexto -r <id> to resume, and dexto search to query history. Agents can spawn sub-agents like explore-agent via the agent-spawner tool, with approvals forwarded to the parent for a unified flow. Run modes are Web UI (default), CLI (--mode cli), server (--mode server, exposing endpoints like POST /api/message over REST/SSE via startHonoApiServer), and MCP server (--mode mcp over stdio for Claude Code/Cursor). Programmatically, install @dexto/core and use the DextoAgent class: createSession(), generate(), stream(), switchLLM(), and multimodal inputs.
- A developer who wants to autonomously build, debug, and refactor an entire codebase can use the built-in coding agent (dexto --agent coding-agent) to read/write code, run tests, and execute shell commands
- A team embedding agents into their own product can use the @dexto/core SDK to programmatically create sessions, stream responses, and switch models, then expose REST/SSE via startHonoApiServer
- Claude Code or Cursor users can connect a Dexto agent as an MCP server (dexto --mode mcp --agent coding-agent --auto-approve --no-elicitation)
- Privacy-conscious users can run local models via Ollama or node-llama-cpp GGUF (auto GPU detection for Metal/CUDA/Vulkan), keeping data on-machine
- Multi-agent workflows like the triage-agent let a coordinator delegate subtasks to explore-agent and other registered sub-agents via agent-spawner
- Builders of companions or support bots can combine persistent sessions, memory, and Discord/Telegram integrations to keep context across restarts
What are this agent's strengths and limitations?
- Configuration-driven: agents are fully defined in version-controlled YAML — swap models and tools without code changes, with automatic reload
- Model-agnostic: built-in support for OpenAI, Anthropic, Google, Groq, xAI, Cohere, AWS Bedrock, Vertex AI, OpenRouter, LiteLLM, and local Ollama/GGUF, with mid-conversation model switching
- Two-way MCP: acts as an MCP client connecting 30+ tool servers, and as an MCP server consumable by Claude Code/Cursor
- Batteries included: persistent sessions, memory, multimodal input, observability, and human-in-the-loop approvals (manual/auto-approve/toolPolicies) are framework features
- Multiple delivery modes: CLI, Web UI, REST/SSE server, SDK library, MCP server, plus Discord/Telegram example integrations
- Licensed under Elastic License 2.0 (GitHub shows NOASSERTION) — it restricts offering Dexto as a competing service and is not an OSI open-source license; review terms for commercial use
- The project is marked Beta, so APIs and config formats may change, creating upgrade risk for production adoption
- Collects anonymous telemetry by default (commands, timing, errors, system info, models used); you must set DEXTO_ANALYTICS_DISABLED=1 to opt out
- MCP mode requires --auto-approve --no-elicitation (it runs non-interactively), weakening manual approval safety controls
- Source builds require a pnpm/Node.js toolchain, and production-grade persistence needs you to configure Redis/PostgreSQL yourself
How do you install or deploy this agent?
Native installer (recommended): on macOS/Linux/WSL run curl -fsSL https://dexto.ai/install | bash; on Windows PowerShell run irm https://dexto.ai/install.ps1 | iex. Or build from source: git clone https://github.com/truffle-ai/dexto.git && cd dexto && pnpm install && pnpm install-cli (requires Node.js and pnpm). For SDK usage: npm install @dexto/core. The first run launches a setup wizard (also dexto setup) to configure LLM provider and API keys (e.g., OPENAI_API_KEY, ANTHROPIC_API_KEY) or local Ollama models.
How do you use this agent?
Run dexto to start the default Web UI with the first-run setup wizard; dexto --mode cli for the interactive terminal (type / for commands); dexto -p "create a landing page" for a one-shot task; dexto --agent coding-agent to launch the coding agent; dexto -m claude-sonnet-4-5-20250929 to switch models; dexto -c to continue the last conversation; dexto --mode server --port 3001 for REST/SSE; dexto --mode mcp to run as an MCP server. SDK example: const agent = new DextoAgent({llm: {provider: 'openai', model: 'gpt-5.2', apiKey: process.env.OPENAI_API_KEY}}); await agent.start(); const session = await agent.createSession(); const response = await agent.generate('What is TypeScript?', session.id);. Install prebuilt agents from the registry with dexto agents install <name>. Logs live in ~/.dexto/logs/; set DEXTO_LOG_LEVEL=debug for verbose output.
How does this agent compare with similar options?
The README positions Dexto as an 'operating system for AI agents' (LLM as CPU, context window as RAM, Dexto as OS), distinguishing it from raw LLM API calls by adding orchestration, state, tools, and recovery. Documentation explicitly shows exposing Dexto as an MCP server to Claude Code and Cursor, making it a complement to those tools rather than a replacement.