Skip to main content
The control plane · console.openeng.app

Author once. Publish a version.
Run it on any engine with your key.

Configure OpenEng AI in the browser — a config at the center, with 20 domains around it in four groups: Building blocks, Connect, Govern, and Deploy. Freeze it into an immutable id@version, and every engine you run pulls the exact same config version. No version drift, no surprises.

Status: OpenEng AI isn’t live yet. The Console and Web Console interfaces load, but the OpenEng AI API routes and the Broker aren’t deployed. Nothing can be saved or published, and no AI engine can register or connect. Pro, Enterprise, and pay-as-you-go launch in Q4 2026 and can’t be purchased yet. You can explore the builder and the building blocks today; this page describes how saving, publishing, and running are built to work.

Open the Console

Preload a published config

Immutable versions Mirror, not source Secrets by reference Diff any two versions
console.openeng.app/configs/support-triage
support-triagev2.1.0
agent: qwen3-8b
planner: qwen3-14b
apiKey: ${ZENDESK_TOKEN}
+ 3 agents · 2 cells · 1 connector · custom flow
Placeholders ready · diff vs v2.0.0publish

Everything in one place

One config at the center. 20 domains around it.

In the Console, the config is the primary thing you make; everything else is a building block, a connection, or a rule that attaches to it. Here is the Console’s navigation, group by group.

Overview Configsat the top of the Console, with Configs the primary entry

Building blocks

What a config is made of — adopted from the catalogs or authored by you.

Library

Preset bundles of agents, models, skills, templates, and cells — import one into a config in one action.
All plans

Models

The one place models are created — catalog models, Ollama, a network endpoint, or a cloud provider, each with its capabilities. Configs pick one per role group.
All plans

Agents

Browse the agent catalog, adopt or customize an agent, or author your own.
All plans

Skills

Browse the skill catalog and adopt skills into your account; configs select the ones they use.
All plans

Templates

Browse the default templates, or author and version your own prompt templates.
All plans

Loops

Browse the global loops and adopt them into your account; configs select the loops they use.
All plans

Schedulers

A cron-like schedule plus a prompt and a target — the jobs meant to run a config headless once the engine’s scheduler ships.
Pro

Connect

What your agent can reach — with credentials as ${ENV} names, never values.

MCP servers

Model Context Protocol server definitions — a URL plus ${ENV} names for credentials, never the secret values. The engine doesn’t connect a config’s MCP servers yet; it uses the servers in your .mcp.json.
All plans

Cells

Browse the cell catalog and register the read or write cell deployments that run in your own cloud account.
All plans

Connectors

Browse the connector marketplace — GitHub, GitLab, Jira, and more — and attach a remote, sandbox-isolated integration to a config (the integration endpoints aren’t live yet).
All plans

Storage points

Where run results are to be delivered — GitHub, S3, GCS, or Drive — once fleet delivery ships. Credentials are ${ENV} names only.
Pro

Govern

The rails — how your agent is allowed to run.

Token limits

Per-model, per-role, and per-day token budgets. Caps for a single config live in its builder’s Token caps step.
All plans

Directories

Directory configuration and the scoping defaults for where an agent may read and write (the engine doesn’t apply published Directories yet).
All plans

Defaults

Account-wide role-model defaults and resource caps, used by the Console as fallbacks.
All plans

Gateway

Gateway policy — token conditions plus guardrails such as injection screens, redaction, and groundedness checks. The compiled floor (authorization, secret-egress blocking and redaction) is always on; approval defaults can be relaxed only by operators.
All plans

Plugins

Gateway guards — gate, transform, observe, or enrich — on the model, cell, or connector gateway. Built-in modules are free; external endpoints need Pro.
External: Pro

Roles

Behavioral rule-sets from the roles catalog: attach a base role, layer your own sharpen-only overlay rules, and target specific agents.
Pro

Human-in-the-Loop

Pause a run for a person at any boundary, with approval rules, contacts, and the approvals queue.
Pro

Deploy

How it runs — the keys and the fleet.

API keys

Issue, rebind, and revoke API keys, shown once at creation. An API key is also the OpenEng key your engine starts with.
Pro

Sandboxes

Your fleet of sandbox-mode nodes — status, allocation, runs, and revoke — once nodes can register and run work.
Pro

Under Account: Plan & billing and Preferences. Plan-gated pages show a lock until your plan opens them.

The config builder

A config is built step by step.

Configs are authored in a guided builder. Each step shows its status in the rail, and every step stays open to revisit — nothing locks you in a forward-only wizard.

  1. 1

    Resources

    CPU, GPU, memory, and storage caps, as a percent of the machine.

  2. 2

    Execution flow

    Design this config’s pipeline on a canvas — or leave it empty to run the default.

  3. 3

    Models

    One model per role group.

  4. 4

    Components

    Agents, templates, skills, roles, loops, routes, cells, MCP servers, and connectors — picked from your own items.

  5. 5

    Global paths

    Where the engine keeps its data; the default is ~/.openeng.

  6. 6

    Token caps

    Per-component token budgets that prompt or stop on a breach.

  7. 7

    Settings

    Functionalities, the reviewer, the machine profile, the loop posture, and plugins.

  8. 8

    Review & publish

    Required placeholders, a diff, and publish.

The component steps list only the items in your own account — adopt from a catalog first, then select.

Publish-once

A config is a version. Versions don't change.

Publishing is immutable. Every publish requires a strictly-higher SemVer, and a published id@version always resolves to exactly the same bytes — on every machine, forever. Roll forward, never in place.

Strictly-higher SemVer

You can't overwrite a published version — only publish a higher one. There is no edit-in-place, so a name you've pinned can never silently shift under you.
  • support-triage@2.0.0 → 2.1.0
  • Old versions stay resolvable
  • Roll back by pinning an earlier version

Diff & timeline

Every published version lands on a timeline. Pick any two and see a field-level diff — exactly what changed in models, agents, policy, or placeholders.
console.openeng.app/configs/support-triage/versions

Version timeline

  1. v2.1.0latestnow

    Swapped the planner model, added a Jira connector

  2. v2.0.03 days ago

    Authored a custom execution flow

  3. v1.4.02 weeks ago

    Lowered the reviewer’s token cap

  4. v1.0.01 month ago

    First published config

What a config resolves to

A preview, not a controller. Mirror, not source.

The Console never runs your agent — your local engine does. The control plane shows you exactly what a config will resolve to so you can verify it before you publish. The browser holds no logic and no execution power.

See it before it ships

Review & publish lists the placeholders the config needs and a diff against the last published version — every role, agent, policy, and reference, before anything goes live.

The engine is the source of truth

Configs are pulled and run by your local engine. The Console authors and freezes; it holds no intelligence and no execution path, and configs carry secret names, not values.

Resolved by name, everywhere

Start an engine with openeng serve --config=<id> to preload a published config and its models, or pick the config per session in the Web Console. Every machine resolves the same config version (MCP servers still come from each machine’s .mcp.json).

Compose, don't code

Design each config's execution flow on a canvas.

Place components on four ordered tiers — intake, planning, execution, finalize — and the engine runs exactly what you drew instead of the default pipeline. Start from a preset: Minimalist (just the agent), Product ship (planner, agent, summarizer), or Detailed, the default.

console.openeng.app/configs/support-triage
ComplexityPlannerAgentReviewerSummarizer
support-triage · execution flow5 stages · valid

  • Tiers, not free nodes

    Ten components across four tiers: the complexity check at intake; the planner and plan orchestrator in planning; the agent and its helpers in execution; the reviewer and summarizer to finalize. The designer keeps the ordering legal.

  • Capabilities toggle on the agent

    Enable sub-agents, delegators, and device use on the execution stage, with a recursion-depth cap — the engine spawns them as the plan needs. Device use needs screen and input control, which ships in a later engine build.

  • Rides the config

    The flow freezes into the config’s id@version under the same strictly-higher SemVer rule. A config with no flow runs the default pipeline.

Safe by construction

An always-on floor you can layer on, never under.

Every config runs above a security floor that no config can remove. Your gateway policy and plugins compose on top of it — they can tighten, never weaken. Operators can relax the engine’s approval and sandbox defaults with environment variables; a config can’t.

The floor no config can remove

Envelope checks, authorization, and secret-egress blocking and redaction are compiled in beneath every config. By default, destructive actions and downloads need your approval and shell commands run in a kernel sandbox where the host supports one; operators can relax those defaults with OPENENG_FLOOR_MODE, OPENENG_SANDBOX, and OPENENG_MCP_AUTO_ALLOW.

Plugins layer above it

Order a chain of gate / transform / observe / enrich plugins on the model, cell, or connector gateway. Each one can add a check; none can remove one.

Policy is versioned too

Your gateway policy and plugin selections publish as part of the config — pinned to a version, diffed on every change, rolled forward like everything else.

Secrets by reference

Configs store references, not secrets.

You write ${ENV} references in the Console. The real values come from the environment of the machine running the engine — or, only if you choose, from the optional vault, which stores a value encrypted on our servers.

References only

An API key, token, or endpoint is stored as ${ZENDESK_TOKEN} — a name, not a value. A breach of the configs yields names, not values.

Resolved at the engine

When your engine resolves the config, it substitutes each reference at run time — from its own environment first. The secret is read on your machine and used on your machine.

Or the write-only vault, if you choose

Rather not manage environment variables? In the Web Console’s Settings you can save a placeholder value to the vault, which stores it encrypted on our servers. It is write-only — never read back into a browser — and only your engine, signed in with its API key, can fetch it. An environment variable on the engine machine always wins.

What the Console stores vs. what runs

consoleapiKey: ${ZENDESK_TOKEN}
resolved on your machine
engineapiKey: zd_•••••••••••

The same reference resolves to whatever each machine has in its environment — dev, CI, and prod stay cleanly separated.

You stay in control

Approve the actions that matter. Choose how the loop runs.

Put a human in the loop at exactly the boundaries you choose, adopt global loops from the catalog, and set which loop strategies each config allows.

Human-in-the-Loop

Pause a run for a person at an agent, an MCP server, a model, a worker (any delete, say), a cell, or a function. The run suspends, lands in the Console's approvals queue, and waits for an approve or a deny. Your engine checks that queue about once a second (one poll for the whole machine, however many runs are waiting), so an approval lands almost immediately and the run proceeds. Token-cap breaches park here too, as boost-or-proceed prompts.
  • Approvals, rules, and contacts
  • Rules ride the config version
  • Pro and above
Open Human-in-the-Loop

Loops and the loop posture

Adopt global loops from the catalog (2 of the 6 need no integration; 4 need integrations that aren’t live yet): each repeats a request over a source — a backlog, an incident list, open pull requests — until its stop condition is met, capped by iterations and an optional token budget. Each config also sets its loop posture: which strategies it allows (React, Reflection, Plan · Execute · Replan, Orchestrator · Worker, Durable) and the default for chat, coding, goal runs, and research.
  • 6 global loops, 2 needing no integration
  • 5 strategies to allow per config
  • Per-iteration review stays on
Browse loops.openeng.app

What's open, and what's Pro

The composable building blocks are open to everyone. Automation, credentials, delivery, and the governance extras unlock on Pro and above — and because the engine starts with an API key, running it needs Pro too. Pro and Enterprise are launching in Q4 2026 and can’t be purchased yet.

Every plan

  • Library, Models, Agents, Skills
  • Templates and Loops
  • MCP servers, Cells, Connectors
  • Token limits, Directories, Defaults
  • Gateway and built-in plugins

Pro and above

  • Schedulers
  • API keys — and so the AI engine
  • Sandboxes
  • Storage points
  • Roles
  • Human-in-the-Loop
  • External plugin endpoints
See full pricing Read the Console docs

Questions

The Console, answered.

Not in your configs. A config stores ${ENV} references only; the values resolve from the environment of the machine running the engine. If you choose, the optional per-config vault stores a value encrypted on our servers instead: the Web Console can only write it, it is never read back into a browser, only an engine presenting your API key can fetch it, and an environment variable on the engine machine always wins.

Author your platform. Publish a version. Run it anywhere.

Explore the Console’s interface today. Once its API is deployed, configure once in the browser, freeze it into an immutable id@version, and run the exact same config version on your own machine — every time.

Open the Console Open the Web Console