Skip to content
Enso
Debug and tune the system around your coding agent

Give agents room to work. Keep the receipts.

Enso is for developers who want the freedom of working with capable coding agents without removing themselves from the engineering process.

View Enso on GitHubRead the docs

Let the agent work. Stay close enough to understand the work.

Enso transcript showing a developer asking for a regression test first and the agent beginning the investigationexpand
Trust, then verify

There is another path between blind trust and zero trust.

01

Blind trust

Hand over the process. Reconstruct the work when the result surprises you.

02

Trust, then verify

Give the agent meaningful freedom. Preserve enough evidence to understand the work and step in when judgment matters.

03

Zero trust

Approve every movement. Stay involved, at the cost of the agent's room to work.

The instruction isn't always the intent.

You can write a perfectly reasonable prompt and get a perfectly reasonable result that still isn't what you meant.

Sometimes the agent misunderstood. Sometimes you left something important unsaid. Sometimes your own assumption was wrong. Enso gives you somewhere to look when the result and the intent part ways.

Work together

Let the agent work without disappearing from the work.

A thread is a working session, not just a prompt and an answer. The agent can investigate, edit, run tools and keep moving. When it needs your judgment, the question appears in the same place as the work.

An Enso thread with the agent's questions waiting for the developer's answerexpand

Questions when they matter

The agent can stop and ask rather than guessing through an ambiguity. You can answer, redirect, change mode or add an image in the thread.

Permission without prompt fatigue

Choose how much can happen without asking. A decision for the session does not have to become a permanent global rule.

Threads that remain threads

Projects keep the work together. Open a stored thread later and its record is still there, ready to resume.

You do not have to approve every step to stay part of the process.

Set the conditions

A run starts with conditions you can see.

Project, model, effort, permissions, system prompt and the task itself shape what happens next. Enso makes those choices explicit at the start instead of letting them disappear into setup.

The Start a session dialog: model, effort, mode, system prompt, saved prompt and the first taskexpand
Choose how the work starts, together, before the first request.
Enso's prompt library: reusable prompts, their context cost and what the model receivesexpand
Reuse system, append and session prompts. Inspect their context cost and what the model will receive. The system prompt stays fixed for the life of the thread.
Understand what happened

Understand what produced the result.

What did the model have?

Inspect what it was working with.

Context shows the composition of each request. The Context Browser opens the exact elements: system prompt, tool schemas, messages, injected context and tool results.

Context events also record model, mode and compaction changes. When a result surprises you, you have somewhere to look.
Enso Context: the composition of the next request and the request-by-request trendexpand
What changed?

Tool history tells you what was attempted. Diff tells you what is actually different.

Diff reads the project's git state, not the agent's tool history. It sees changes from an edit, a write, a shell command, a formatter or your own editor.

Enso Diff: the project's changed files, and the old and new lines of a changeexpand
How did the run behave?

Separate signals. Room for judgment.

Stats helps explain where time, context and cost went. Session Eval adds a timeline of human corrections, queued prompts, interrupts, declined questions, tool calls, writes, test and build activity, and refusal channels.

Enso keeps these signals separate instead of collapsing a session into a single quality score. They are evidence for investigating a run.

Try another path

Try another path without erasing the first one.

Pick a prompt in an existing thread and fork from there. The original stays where it is. The new thread begins with the history before that point and puts the prompt back in front of you.

A fork in Enso: listed under the thread it came from, with the prompt it was forked at back in the composerexpand
The fork, under the thread it came from in the rail, and the prompt it was forked at back in the composer.
A fork point: the parent thread, the model, the permission mode, the system prompt and the recorded run conditionsexpand
Its fork point: where it came from, and the conditions its runs started under.
Lineage · run provenance

Keep the conditions with the work.

A run records conditions such as its model, effort, permissions and project revision, with fingerprints of the configuration and context files it began with. If two attempts behave differently, Enso gives you somewhere to look for what else changed.

Preserve both runs and the conditions they ran under. Inspect their fork points or compare threads with Session Eval from the command line. The browser does not yet have a side-by-side comparison workspace.Forks share the project's working tree and keep the original system prompt. Start a new thread to try a different system prompt.
The software factory

Don't just use an agent. Build the system it works inside.

The agent is one part of the system producing the software. The model, instructions, context, tools, permissions and project state all shape the result. Tests, feedback and human judgment matter too.

Change one of those conditions and the result may change with it. Enso gives those conditions somewhere to live and gives the work a record you can inspect.

The software factory is not a machine you switch on and walk away from. It is a system you can inspect, tune and improve.
ModelWhich model is doing the work, and with how much effort?
InstructionsWhat system prompt, saved prompt and task did the run begin with?
ContextWhat information was actually sent with each request?
Tools and permissionsWhat could the agent do without asking, and where did a boundary intervene?
ProjectWhat code and configuration was the run operating against?
VerificationWhat changed, what was tested, and what evidence remains?
HumanWhere did you answer, correct, redirect or change the conditions?
Freedom with boundaries

Freedom works better when the rules are clear.

Permissions

What can proceed, what needs an answer, and what is denied by policy.

Questions

A place for the agent to ask rather than guess.

Guards

Known classes of actions refused before they run, with a receipt explaining the boundary.

Explicit web access

A deliberate path to fetching and searching the web instead of opaque shell egress.

An Enso guard receipt: reading .env refused as a credential read, with the guard and rule that decided itexpand
Allowed
The action could proceed.
Asked
A decision was needed before proceeding.
Operator declined
You chose not to allow the action.
Guard refused
A known rule stopped the action before it ran.
Tool failed
The action ran and returned an error.
Provider refused
The model provider declined the request.
Built on pi

Use what works. Own what is different.

Enso is built around pi rather than a private agent runtime of its own. pi handles the agent loop, model interaction, tools, sessions, branching and compaction.

Enso adds the browser, context inspection, permissions, evidence, lineage, debugging and the places where human judgment enters. That keeps Enso focused and gives it an existing ecosystem to build on.

Explore the features

The full product map.

The complete reference for working with Enso, inspecting a run and changing its conditions.

Verify & operate

Keep receipts for the parts that matter.

Distinguish refusals from failures, catch the agent working around one, see what changed, inspect the logs, and give the agent deliberate paths to external information.

Guards and receiptsknown boundaries · explicit refusalsIncidents and the command judgesignals · halt · report · judgeDiffevery changed file · side by sideDiff Viewerprompt by prompt · snapshot to snapshotLogs and debugginglive logs · debug state · bundlesWeb accessweb_fetch · web_searchTerminalpi with Enso loadedSettingsthemes · fonts · providers · roles · permissions · security · web tools · projects & threads · storage

The feature docs document not only what each capability does, but also how to open it, what to look for, and what it doesnot do. Browse all feature documentation →

Documentation as evidence

The docs carry receipts too.

The feature pages are built from the application and its source. Screenshots are regenerated from an Enso session, documented values are checked against what the app showed, and every feature page includes what it does not do. The build checks for drift.

I check your work.
You check mine.
The system keeps the receipts.

Enso is for developers who want capable agents to do real work without making the process disappear.

View on GitHubRead the docs