01
A task, not a message
The unit of interaction has a real lifecycle: New → Planning → Executing → Waiting for you → Completed. You can close the laptop in the middle of it.
Desktop environment for AI agents
A modern model can plan, run code, edit projects and chain actions. A chat window turns that into a terminal you hand-drive. Enactive is the environment the agent works in instead — the model is the engine, this is the workspace.
Add a MySQL replica health probe
Probe lag on the three instances and write the result
Reading StationCnfWriter.cs…
What do you want to accomplish?
Execute — edits freely, asks before run_command
The desktop window, drawn from the application's own layout and labels.
How it works
Workspace → Task → Worker → Artifact. Chat stays, as a side console for quick nudges — it is no longer where the work happens.
The unit of interaction has a real lifecycle: New → Planning → Executing → Waiting for you → Completed. You can close the laptop in the middle of it.
Structured progress — found 14 files → identified the bottleneck → 3 tests passed → changes ready. Never raw chain-of-thought.
A run ends in a diff, a file set, a report — with Apply, Review and Reject on it. Not fifty chat bubbles you have to read.
The agent runs the plan end to end and stops where the autonomy tier says to ask — showing the whole action, never a summary of it.
What's in it
Everything below is implemented and running today, not a roadmap.
The planner emits step dependencies. The scheduler runs steps by readiness, cascade-skips dependents when one fails, and detects cycles.
Observe → Suggest → Execute → Autonomous. Shell and PowerShell ask first; you can remember an approval for the session or for the workspace.
Developer, Reviewer (read-only), Ops, Writer — each with its own tool allowlist, permission level and model. You pick a role, not a model.
Read-only discovery of host and OS, Git branch, remote and dirty state, Docker, WSL and services — fed into the prompt and shown in the UI.
Decisions and artifacts across every run fold into a persistent project memory, so the next run starts knowing what the last one did.
Drop ten tasks in the evening. The agent runs headless, declines to guess at forks, and leaves results and questions in your Inbox.
Optional staging: every write becomes a diff you Apply or Reject before it touches the disk.
Every prompt, response, tool call and event — with a raw-wire option. Live window plus a daily file, so a bad run can be read afterwards.
API keys are DPAPI-encrypted in settings.json. Run history, memory and approvals live in .enactive/ inside your own workspace.
The fork
The agent scans, plans, writes and tests on its own. Where the tier says to ask, it stops and shows exactly what it is about to do — the whole command, the whole path — instead of guessing and reporting success. Some tools ask at every tier, however far the slider is pushed: deleting a file leaves an absence, and an absence is the hardest thing to notice afterwards.
That pause is the whole point of the autonomy slider, and it is the gap in the logo.
Run tool 'run_command'?
command: mysql --host ate-db-02 -e "SHOW REPLICA STATUS\G"
The whole command, never a summary. A 400-character script used to be approved on its first 120.
From anywhere
Sign in to the gateway — remote.enactive.dev, or one you deploy — from any browser. The desktop application connects outward to it: nothing listens on your computer, and no port is opened. The task runs through the same engine as one typed into the app.
End-to-end encrypted. What you write and what your computer reports back is encrypted on your own devices and on your computer; the gateway stores and forwards ciphertext it cannot read. A computer is paired with a code you carry to it yourself, a phone is added with a one-time link or QR, and every command is sealed with a key the service never holds — so the service cannot start a task, answer a permission or read a result.
A permission appears on the task's own card, so you answer it next to what you asked for. Both ends are asked at once and the first answer wins: sitting down at the computer always works, whatever the phone is doing.
How remote access works ↗ What the service can and cannot see ↗ Connect to gateway ↗
Run tool 'delete_file'?
path: README8.html
Team of models
Configure any number of providers and bind a model to each phase of a run. One local model doing everything is just the simplest case of the same setup.
A reasoner turns the intent into a dependency graph and rates every step trivial, normal or complex.
Steps route themselves by that rating: trivial to a light model, normal to the worker's own, complex to the heavy one.
Each step is judged against the real tool transcript — not the model's summary of it. On a fail, the step is retried with the feedback.
num_ctx
Anthropic
OpenAI-compatible
OpenRouter · Groq · a second Ollama…
The awkward parts are handled for you: local <think> is off by default, Anthropic's
temperature is dropped for models that reject it, max_tokens is auto-sized to each
model's real cap, a truncation guard stops a half-written tool call from looping, and writes can be
verified by reading the file back.
Architecture
Seven projects on .NET 10. Core, Providers, Tools, Agents and the console host pull in zero external NuGet packages. Only storage and the Avalonia UI have dependencies at all.
run_command, run_powershell, git and docker, each gated by permission level.