Dexto: A YAML-Configured Harness for LLM Agents, With a Coding Agent Attached
Agent harness and tookit for building AI agents and agentic applications. CLI and SDKs included
At a glance
- What is it?
- Dexto is a TypeScript agent harness that turns a YAML file into a stateful agent with tools, sessions and permissions. The bundled coding agent is the demo; the harness is the product, and its Elastic 2.0 licence is the first thing to check.
- Who is it for?
- Adopt Dexto if you want an agent defined by a YAML file rather than by glue code, and you are comfortable running MCP servers over stdio in the same process as the agent. Do not adopt it if you need a permissively licensed library to embed in a closed product, or if your agent has to run without a Node runtime.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Dexto fills between an LLM API call and a working agent
Calling a model is easy. Keeping one running across a conversation, giving it file access, remembering what it did, and stopping it from deleting something is the part that consumes weeks. Dexto positions itself as that layer. The README calls it an agent harness and offers an operating system analogy: the LLM is the CPU, the context window is RAM, Dexto is the OS, and your agent is the application.
The target user is a TypeScript developer who wants an agent without writing the orchestration themselves. The README lists session management, tool orchestration, memory, multimodal support and observability as included, and describes agents as configuration-driven: you define them in YAML and swap models and tools without touching code. That is the actual claim to evaluate. If the YAML schema covers your agent, you write no orchestration code. If it does not, you are extending the harness, and the README does not describe that path in the material available.
The repository also ships a coding agent as a worked example. The README is explicit that this is one example of what you can build, not the whole product, and gives the command dexto --agent coding-agent to launch it. Treat the coding agent as a demonstration of the harness rather than as the harness itself.
How the pieces fit: YAML config, MCP servers, and a permission gate
The mechanism visible in the README is a config file per agent, conventionally under agents/my-agent.yml. Two blocks appear there. The first is mcpServers, which declares Model Context Protocol servers the agent can call. The README's example wires a filesystem server and a Puppeteer server, both with type: stdio, a command of npx, and an args array. So tools arrive as child processes speaking MCP over stdio, not as in-process functions you import.
The second block is permissions, with a mode key that takes manual or auto-approve, and a toolPolicies block containing alwaysAllow. The tool names in that list are namespaced with a double hyphen: mcp--filesystem--read_file and mcp--filesystem--list_directory. That naming convention is how the harness maps an MCP server plus a tool into a single identifier, and it is the detail most likely to trip you up when writing policies by hand.
The README states that agents remember which tools you approved per session, so the permission layer is stateful rather than a static allowlist. Sessions themselves persist across restarts: dexto -c continues the last conversation and dexto -r session-abc123 resumes a named one. The README also mentions persistent memory that shapes agent behavior, though it does not describe the storage format or where memory lives on disk in the supplied material.
Interfaces are separate from the harness. The README lists a Web UI, a CLI, a REST API, Discord and Telegram as ways to reach the same agent, which is the point of putting orchestration in a layer rather than in a client.
Installing and running Dexto from the documented commands
The README gives a native installer for macOS, Linux and WSL via curl -fsSL https://dexto.ai/install | bash, and a PowerShell equivalent with irm https://dexto.ai/install.ps1 | iex. Building from source is git clone of the repository, then pnpm install and pnpm install-cli. Note the pnpm dependency: there is no npm or yarn path documented.
Running dexto with no arguments launches a setup wizard on first run. From there the README documents dexto --mode cli for terminal mode, dexto -p "create a landing page for a coffee shop" for a one-shot task, dexto --auto-approve "refactor this codebase" to skip confirmations, and dexto -m claude-sonnet-4-5-20250929 to switch models. Inside the interactive CLI, typing / opens the command surface for switching models, managing sessions and configuring tools. Dexto setup configures defaults such as provider, model and API keys, and can download local models.
Operationally, logs go to ~/.dexto/logs/ and DEXTO_LOG_LEVEL=debug raises verbosity. The README points to cli.dexto.ai for the installation guide and the CLI command reference, which is where upgrade and uninstall instructions live. That is worth noting: the README does not cover upgrades inline, so the documented upgrade path is a separate page.
The README shows a status badge of Beta. Plan for schema and flag movement between releases. The three published packages in the release list (dexto, @dexto/tui, @dexto/tools-todo) share a version number, which suggests they are released together rather than independently.
The licence is the decision point, and the README does not settle it
The repository metadata reports the licence as NOASSERTION, while the README displays an Elastic 2.0 badge. Those two signals disagree, and the disagreement matters more than any feature on this page. Elastic 2.0 is a source-available licence, not an OSI-approved open source licence. It typically restricts offering the software as a managed service and has version-based relicensing terms. The README also labels the project Beta.
What that means in practice: if you are evaluating Dexto as a library to embed in a commercial product, the licence question comes before the architecture question. The supplied material does not include the LICENSE file text, so the exact terms cannot be confirmed here. Read the file in the repository and get your own advice. The metadata field saying NOASSERTION may simply reflect a licence GitHub's classifier does not recognise, but you cannot assume that.
On maintenance cost, the material supports only a limited reading. The last push and the most recent releases are dated 2026-09-08, and the three packages in the release list carry the same version, so the project appears to be actively released. That tells you nothing about the size of the maintainer team, the response time on issues, or the stability of the YAML schema across minor versions. The topics list includes contributions-welcome, which suggests outside contributions are expected rather than merely tolerated. There is also a Discord link in the README, which is where the project appears to direct community questions.
Where the harness model gets in the way
A configuration-driven harness is a constraint as much as a convenience. Anything the YAML schema does not express has to go through MCP servers or through code that hooks into the harness. The README's examples cover MCP servers, permissions and model selection. It does not show how to register a custom in-process tool, how to intercept the tool loop, or how to shape the prompt sent to the model. If your agent needs those, you are reading source rather than documentation.
The MCP-over-stdio design has a concrete cost. Each server is a child process launched with a command such as npx, which means startup latency per server, a Node runtime on the host, and a process tree to supervise. For a long-running server that is fine. For a short-lived one-shot invocation via dexto -p, the overhead is paid on every run.
Permission modes come in two settings in the documented example: manual, which requires approval for each tool, and auto-approve, which the README describes as trust mode for local development. There is no documented middle ground such as allow-read, deny-write. You approximate it with toolPolicies.alwaysAllow, which means enumerating namespaced tool names by hand. That is workable and tedious, and it is the kind of list that drifts when you add a server.
Finally, the README claims support for 50+ LLMs across OpenAI, Anthropic, Google, Groq, xAI, local models via Ollama and GGUF through node-llama-cpp, plus gateways including OpenRouter, AWS Bedrock, Vertex AI and LiteLLM. Breadth across that many providers usually means uneven depth per provider. The material does not indicate which providers get extended thinking, structured output or tool-calling parity.
How Dexto differs from wiring an agent framework yourself
The obvious alternative is a general-purpose agent framework in the same ecosystem, such as LangChain or LangGraph. The difference in approach is where the agent lives. With a framework, the agent is code: you compose nodes, tools and state in TypeScript or Python, and the framework supplies primitives. With Dexto, the agent is data: a YAML file that the harness reads, with the harness owning the loop, session store, permission gate and interfaces.
That distinction decides most adoption questions. If your agent's logic is genuinely bespoke, with branching control flow and custom state transitions, a framework gives you the seams to express it and Dexto gives you a schema to fight. If your agent is a model, a set of tools and a permission policy, Dexto removes the code you would otherwise write and maintain, and the YAML becomes something a non-author can edit.
A second alternative worth naming is using a coding agent product directly rather than building on a harness. Dexto ships one, and the README is candid that it is an example. If all you want is a terminal coding assistant, the harness underneath is overhead you did not ask for. The harness earns its place when you need a second and third agent in the same shape, sharing session and permission machinery.
The MCP angle cuts across both alternatives. Dexto is an MCP client, and the README also lists MCP servers as something you can build. If you have already standardised your tools behind MCP, Dexto's value is mostly the permission layer and the session store around them.
Who should adopt Dexto, and what to verify before you do
Adopt it if you are a TypeScript team that wants several agents sharing one runtime, and you are willing to describe those agents in YAML. The permission model, the per-session approval memory and the persistent sessions are the parts that are tedious to build and are already here. The multi-interface story (CLI, Web UI, REST API, Discord, Telegram) matters if the same agent has to be reachable from more than one place.
Do not adopt it if you need a permissively licensed library to embed in a closed-source product, or if your deployment target has no Node runtime for the MCP child processes to run in. Do not adopt it if your agent's control flow is the interesting part of your product, because you will spend your time working around the configuration schema rather than with it.
What to verify first, in order. Open the LICENSE file and confirm the Elastic 2.0 terms against your intended use; the repository metadata says NOASSERTION and the README badge says Elastic 2.0, and only the file settles it. Then install a pinned version and write one agent YAML with a single MCP server, checking the toolPolicies.alwaysAllow naming against the tool list the CLI actually reports, since the double-hyphen convention in the README is the kind of detail that changes between releases. Then run dexto -m with a different provider mid-session and confirm the session survives the switch. The README states that model switching mid-conversation works; it does not show what happens to tool state when it does.
Editorial conclusion
Adopt Dexto if you want an agent defined by a YAML file rather than by glue code, and you are comfortable running MCP servers over stdio in the same process as the agent. Do not adopt it if you need a permissively licensed library to embed in a closed product, or if your agent has to run without a Node runtime. Before committing, read the Elastic 2.0 terms for your use case, confirm the exact tool-policy key names against the version you install rather than against the README, and verify that a mid-conversation model switch preserves the session you care about.
Community notes