01
Blind trust
Hand over the process and inspect the result afterward. Fast when everything goes right. Hard to reconstruct when it doesn't.
An evidence-driven control plane for coding agents
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.
Trust the agent enough to let it work. Verify enough to understand what happened.
expandTrust, then verify
There is another path between blind trust and zero trust.
02
Trust, then verify
Give the agent meaningful freedom. Preserve enough evidence for the human to understand, challenge and intervene when judgment matters.
03
Zero trust
Put an approval in front of every movement. It can reduce some risks, but the friction can also undermine the reason to use an agent.
“Clean this up, fix the bug, and make it safe.”
instructionThe words are clear.
assumptionsThe intended tradeoffs may not be.
evidenceWhen intent and outcome diverge, there is somewhere to look.
The genie problem
The letter of the instruction isn't always the intent.
Humans communicate with a great deal left unsaid. Another engineer brings assumptions about the codebase, acceptable tradeoffs and what you actually meant. An agent may understand the words perfectly without sharing those assumptions.
It's the old genie problem: the wish is granted according to what you said, not necessarily what you meant.
More rules do not eliminate that gap. Neither does more autonomy. Sometimes the agent's interpretation is wrong. Sometimes your assumption is wrong. Evidence gives both of you something concrete to work from.
expandA real handoff from the LED-412 session: the stated runbook path did not exist, the agent checked before acting, and the human later corrected where the runbook actually lived. The record makes the gap between instruction and intended outcome inspectable.
See the system
Not just the conversation.
Enso makes the system behind an agent's work visible: what it knew, what it did, what changed, what was refused, and what evidence remains afterward.
Context · request by request
Follow what the model was carrying.
The context view shows the whole makeup of each model request, not just a token counter. Move across the timeline, select a request, and see what changed.
system prompt · tool schemas · messages · injected context · tool results
expandContext browser
Open the box.
A total only tells you that context grew. The browser shows why. Inspect individual elements—including project instructions and tool results—and trace when they entered the request.
This is the evidence behind “what did the agent know when it did that?”
expandFailures are evidence
See the work that did not go cleanly.
Tool failures stay in the transcript instead of disappearing behind a polished final answer. You can see the attempted command, its arguments, the actual output, and how the agent responded.
expandStats · operational evidence
Understand the shape of the session.
Cost, context use, tool calls, failures and latency sit beside the transcript. The point is not a score. It is enough evidence to investigate what happened and where the work became expensive or noisy.
expandChat
Work together.
The agent works through the task. Tool calls, questions, refusals and failures remain part of the record.
Context
See what it saw.
Inspect what the model was carrying and how that context changed from one request to the next.
Stats
Understand the work.
Cost, tool use, context, latency, failures and other operational evidence live beside the transcript.
The software factory
Don't just use an agent. Build the system it works inside.
A capable coding agent can produce software quickly. The harder problem is designing the conditions around it: context, tools, rules, verification, feedback and the places where human judgment enters.
The software factory is itself something you engineer. The output is software; the system producing it—context, tools, models, rules, verification, feedback and human judgment—is increasingly part of the developer’s work. Enso makes that system visible enough to inspect, debug and improve.
ContextWhat information and assumptions are available to the model?Enso exposes the actual request through the Context timeline and browser, so context can be inspected rather than inferred.
ToolsWhat can it do, and what evidence does that work leave?Tool calls, arguments, results and failures remain part of the session record.
RulesWhich known boundaries are explicit rather than implied?Guards constrain specific known paths and leave a receipt when a boundary acts.
ChecksWhich claims can be tested instead of trusted?Tests, mechanical gates and their results turn claims about the work into evidence that can be checked.
HumanWhere does judgment add more value than another automatic step?Keep the developer able to inspect, question, redirect and change the conditions when understanding matters.
Built on pi
Use what works. Own what is different.
Enso did not start by rebuilding an agent harness. It is built around pi, a proven, extensible coding-agent foundation with support for models, providers, tools, skills and extensions.
That gives Enso a capable agent runtime and an existing ecosystem to build on, while Enso concentrates its own engineering on observation, evidence, controls, context inspection, verification and the places where human judgment enters the process.
When the underlying harness gains capabilities, Enso can build with them rather than recreate them. When Enso needs something different, it can extend the system at the layer where that difference matters. That is part of why new Enso capabilities can move quickly without Enso trying to own the entire stack.
pi provides the agent foundation. Enso makes the system around the agent visible, inspectable and easier to improve.
Set the conditions
Freedom is not the absence of choices.
A session starts with explicit conditions: the model, effort, operating mode and initial task. The agent gets room to work inside a setup you can see and reason about.
expandControl with receipts
A boundary should explain itself.
When a known guard refuses an action, Enso keeps the refusal in the same record as the work: what was attempted, which boundary applied, and which rule acted.
Refusal ≠ failure
Different events mean different things.
A tool call that genuinely fails and an action Enso refuses are not the same event. These two receipts preserve that distinction instead of collapsing both into a generic error.
A missing-file failure is evidence about the environment. A guard refusal is evidence about an explicit boundary.expand failure
expand refusalGuard receipt
Known boundaries can be explicit.
Here the agent tries to edit a neighboring repository. The write is refused as outside the active workspace, and the receipt names the guard and rule that made the decision.
by Enso guard · rule write-confinementexpandSecurity, honestly
Enso is not a sandbox.
Sandboxes are useful when you need a containment boundary. Enso is solving a different problem. Its guards constrain specific, known paths; they are not proof that the machine is isolated.
Trying to anticipate every action an agent might take becomes a continuing game of rules and exceptions. At the other extreme, unrestricted autonomy asks the human to trust a system they increasingly cannot see.
Enso focuses on visibility, evidence and meaningful intervention. Observation first. Control where it is useful. Receipts when something matters.
How Enso is built
The process carries the same burden as the product.
Enso itself is built with agents. The work deliberately includes mechanical gates, review, evidence and revalidation. That adds friction. It also changes what “fast” means.
Prefer evidence
Claims get checked.
If behavior can produce a record, preserve it. If a claim can be checked mechanically, check it.
Keep the human close
Judgment still matters.
The goal is not constant approval. It is preserving the places where understanding and intervention are useful.
Measure the result
Speed is not diff velocity.
The useful measure is how quickly you can produce software you understand and are willing to keep.
I check your work. You check mine. The system keeps the receipts.
Enso is being built for developers who want capable agents as collaborative engineering peers—not invisible replacements.