ADE
Agent Development Environment: an environment built to run, organize and supervise development agents.
Whole library
Pick a way in
01Concept
Guided models — the environment is the policy
Working safely with an agent depends less on the model remembering to ask for permission and more on the harness, the operating system and the credentials making it impossible to act outside the intended scope.
⚿ Agent governance02Concept
CLI vs. web — the agent inside the project
The terminal does not make the model smarter: it places it inside the system it has to understand, modify and verify. The web keeps the edge for thinking, researching and communicating.
⌨ Agent governance03Guide
Choosing a model and reasoning level
A practical guide to assigning coordinators and workers, raising reasoning before paying for a bigger model and scaling up when a real capability gap appears.
△ Agent governance04Guide
Before publishing, test the real startup
A successful build does not guarantee the backend can start. A preflight with the production command and a blocking healthcheck close that gap.
◉ Agent governance05Editorial
Amp and the cloud agent factory
Amp packages agent, machine, context and Git into a single surface. It does not invent multi-agent development, but it turns into a product a practice we usually still build by hand.
◌ Agent governance06Guide
How to read the OpenRouter rankings
A guide to interpreting OpenRouter usage, spend, speed and benchmarks, following its thirteen text sections and turning the signals into comparable tests.
△ Agent governance07Concept
Jev: small decisions inside large systems
What a structured-decision model does and where it belongs: routing, classification, scoring and gates before state changes.
◈ Agent governance08Editorial
Gentle AI and Engram: memory and process for coding agents
What an environment configurator contributes and what persistent memory solves when agent work spans sessions, tools and projects.
◈ Agent governance09Concept
Tailscale: a private network built around identity
Tailnets, WireGuard, direct connections, and relays: what Tailscale solves and what remains your responsibility.
◈ Agent governance10Guide
Tailscale: permissions you can explain
Design grants by identity, destination, and port; test allowed and denied access; separate networking, SSH, and application permissions.
⚿ Agent governance11Editorial
Comparing CLI harnesses: Codex, Claude Code, OpenCode V2, Cline and OMP
The strengths, differences and drawbacks of five coding harnesses: how to choose them, assign responsibilities and assess the real cost of agent work.
⚿ Agent governance12Editorial
Advanced agent routing: model, effort, role and harness
Why agent selection must account for model, reasoning effort, task role and execution harness, using Codex versus OMP as a controlled contrast.
⌘ Agent governance13Editorial
RCT and Overdrive: human protocols for managing provider quotas
Two prepared responses to scarce or expiring capacity: protect LIVE operations, prioritize useful BUILD work, and keep control with the human operator.
◈ Agent governance14Concept
Orca as an ADE and control plane
Orca organizes agents, repositories and execution environments; it does not replace the model or decide on its own how the team should work.
◉ Orca15Concept
Workspaces, projects and worktrees
The project organizes the repository, the workspace represents a work front and the worktree provides real isolation of files and branch.
⑂ Orca16Concept
Orchestration in Orca
Orchestrating is not opening agents in parallel: it is distributing authority, dependencies, context, decisions and evidence of completion.
✣ Orca17Concept
SSH hosts and execution topology
Orca can act as a local interface while agents, repositories and runtimes live in WSL or on a remote machine.
⌁ Orca18Concept
Agent terminals and the session lifecycle
An agent terminal ties together a CLI, a session, a worktree and an observable state; it is not just a console under another name.
▤ Orca19Concept
Continuity, recovery and observability
Orca preserves layout and scrollback, and can keep agents alive as long as the daemon survives; critical state must still exist outside the interface.
◌ Orca20Guide
Orca Desktop with Windows and WSL
A reference pattern for separating the desktop interface from the Linux environment where repositories, runtimes and agents live.
⊞ Orca21Guide
Portable access to Orca over a private network
Use another device as a client of the same development environment, without duplicating repositories or exposing SSH to the Internet.
↗ Orca22Case study
Case study — Orca as a multi-agent cockpit
The evolution from one coordinator to separate direction, integration and packages, with cross-family auditing and verifiable acceptance.
◈ Orca23Guide
Planning a scalable AM5 workstation
How to audit an existing PC and migrate to AM5 across three stages — budget, mid-range and high-end — without rebuying half the machine at each step.
◈ Orca24Editorial
OpenDesign and the visual direction of agents
Models can already build interfaces. The problem is getting them to stop improvising the visual identity on every run. OpenDesign proposes turning that direction into portable files.
✦ Agentic design25Editorial
OpenDesign across Windows, WSL, plans and proxies
Local-first does not always mean a single environment. When the interface lives on Windows and the agents in WSL, choosing between CLI, BYOK and proxy defines spend, sessions and risk surface.
⌁ Agentic design26Concept
Hermes as an operational agent
A self-hosted agent that brings queries and alerts to the channels where the team works, without turning every interaction into a technical session.
✦ Hermes27Guide
Hermes installation preset
Five decisions to make before setting up Hermes without copying someone else’s infrastructure: hosting, model, channels, concurrency and integrations.
◇ Hermes28Case study
Case study — Hermes as an operational interface
A self-hosted agent brought queries and alerts into everyday channels, with scoped permissions and observable business tests.
◈ Hermes29Concept
From backup to a CRM function platform
The read-only backup became the foundation of an internal platform for analyzing, reviewing and deploying CRM functions with separate authorities.
▣ Versioned CRM30Guide
Read-only as an architectural decision
Keep backup and analysis without production authority while a separate path allows reviewed, verifiable changes to be deployed.
⌁ Versioned CRM31Case study
From backup to process map
The process map enables analysis without production access; the new change path connects verifiable findings with review and controlled deployment.
⌘ Versioned CRM32Case study
Case study — From counter to operational continuity dashboard
A personal tool grew to combine incidents, service health and progressive signals without bringing credentials into the browser.
◌ Product cases33Case study
Case study — Widgets that turn CRM rules into guided flows
Two embedded widgets brought context, validation and automation to the exact point where the team made decisions.
◆ Product cases34Case study
Case: a Director that separates narration from memory
An orchestrated architecture where one model writes the scene, Jev decides its consequences and an event log rebuilds what each character can remember.
◉ Product cases35Guide
Tailscale for an agent environment: laptop, VPS, and WSL
An anonymized reference design for accessing a workstation, operating a VPS, and sharing internal previews without exposing admin ports.
◆ Product cases