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

Author once. Publish a version.
Run anywhere you sign in.

Configure your whole agent platform in the browser — 16 config domains across Build, Connect, Govern, and Deploy. Freeze it into an immutable id@version, and every engine you sign in to pulls the exact same setup. No drift, no surprises.

Open the Console

Resolve a published config

openeng config use my-agent@2.1.0
Immutable versions Mirror, not source Secrets by reference No telemetry
console.openeng.ai
support-triagev2.1.0
chat: gemma-3-4b
planner: qwen2.5-1.5b
apiKey: ${ZENDESK_TOKEN}
+ 3 agents · 2 cells · custom flow
Previewing what your engine will runimmutable

Everything in one place

16 config domains. Four stages. One console.

The whole agent platform is configuration — and all of it lives here. Build the intelligence, connect it to the world, set the rails, and ship it, without leaving the browser.

Build

Compose the intelligence — what your agent is.

Models

Map roles — chat, coding, planner, executor — to open-weight models from any registry, in any format, on the runtime that fits, or to a hosted model through the gateway.
Open

Agents

Single-purpose and orchestrator agents, wired into a multi-level org chart.
Open

Templates

Prompt blueprints prepended above your persona at run time.
Open

Cells

Read/write connectors that give agents live signal from your own systems.
Open

Connect

Reach the outside world — what your agent can touch.

Plugins

External decision, approval, and tooling endpoints invoked above the floor.
Open

MCP servers

Register Model Context Protocol servers your engine connects out to.
Open

Gateway & guardrail policy

Order the gate / transform / observe / enrich plugin chain above the security floor.
Open

API keys

Issue and revoke keys for headless and server sign-in — references, never secrets.
Pro+

Govern

Set the rails — how your agent is allowed to run.

Token limits

Per-turn and per-run token ceilings the engine enforces before it spends a call.
Open

HITL approval gates

Pause for a human on the actions you choose — approve or deny from the queue.
Pro+

Loop strategy

Govern which agent-loop strategy runs at each altitude, from a catalog of 44.
Open

Directories

Scope which paths an agent may read and write — outside is denied by default.
Open

Deploy

Ship it — how your agent runs at scale.

Execution flow

Design the stages the engine runs for a config on a visual canvas — the per-config pipeline that replaces the fixed default.
Open

Schedulers

Cron-validated headless jobs that run a published config on a timetable.
Pro+

Defaults

Workspace defaults — speed tier, permission mode, and the config every new machine resolves.
Open

Sandboxes

Cloud-coordinated execution — concurrent, leased, and takeover-aware.
Pro+

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 tag

Diff & timeline

Every publish lands on a timeline with a field-level diff against the version before it — see exactly what changed in models, agents, policy, or secrets before you ship.
console.openeng.ai/configs/support-triage

Version timeline

  1. v2.1.0latestnow

    Added device-code API key, swapped planner model

  2. v2.0.03 days ago

    Authored a custom execution flow

  3. v1.4.02 weeks ago

    Tightened directory scope to ./support

  4. v1.0.01 month ago

    First published config

What your engine will run

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 resolves to so you can verify it before you sign in. The browser holds no logic and no execution power.

See it before it ships

The preview renders the fully-resolved config — every role, agent, policy, and reference — as the engine will see it. No guessing what's live.

The engine is the source of truth

Configs are pulled and run by your local engine. The Console authors and freezes; it never holds intelligence, secrets, or an execution path.

Resolved by name, everywhere

Sign in on a new machine, run openeng config use id@version, and it pulls the identical setup. Zero per-machine drift.

Compose, don't code

Design each config's execution flow on a canvas.

Drag execution stages — complexity, planner, agent, reviewer, summarizer — onto a graph and wire them in order. The flow publishes as part of the config, and the engine runs exactly what you drew instead of the fixed default pipeline.

console.openeng.ai/configs/support-triage
ComplexityPlannerAgentReviewerSummarizer
support-triage · execution flow5 stages · valid
  • Stages, not free nodes

    Each stage is a step the engine actually runs — score complexity, plan, execute, review, summarize. 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.

  • Rides the config

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

Safe by construction

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

Every config runs above a non-negotiable security floor. Your guardrail policy and plugins compose on top of it — they can tighten, never weaken. The order is yours; the floor isn't optional.

The floor is non-negotiable

Worker-only execution, default-deny on destructive actions and downloads, and the always-on guardrail judge are built in beneath every config — there's no toggle to turn them off.

Plugins layer above it

Order a chain of gate / transform / observe / enrich plugins on top of the floor. Each one can add a check; none can remove one.

Policy is versioned too

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

Secrets never touch the cloud

The control plane stores references, not secrets.

You write ${ENV} references in the Console. The real values resolve from the local environment on the machine running the engine — they never travel to, or rest in, the control plane.

References only

An API key, token, or endpoint is stored as ${ZENDESK_TOKEN} — a name, not a value. The Console literally has nothing sensitive to leak.

Resolved at the engine

When your local engine pulls the config, it substitutes references from its own environment at run time. The secret is read on your machine and used on your machine.

What the cloud sees vs. what runs

cloudapiKey: ${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. Govern how the loop runs.

Put a human in the loop on exactly the actions you choose, and pick the agent-loop strategy that fits each job — from a catalog of 44, governed per altitude.

HITL approval gates

Mark agents, models, MCP servers, workers, cells, or functions as approval-required. The run suspends, lands in the Console queue, and waits for a human to approve or deny — polled about once a second.
  • Approve or deny from the queue
  • Versioned, per-domain decisions
  • Pro and above

Loop-strategy governance

Choose which loop strategy runs at each altitude — react, reflection, plan-execute-replan, durable, and more. A reviewer validates every iteration, so an autonomous run stays on the rails you set.
  • 44 loop strategies
  • Governed per altitude, down to the worker
  • Reviewer checks every iteration

What's open, and what's Pro

The composable building blocks are open to everyone. The fleet-automation and credential domains unlock on Pro and above.

Open to all

  • Models
  • Templates
  • Cells

Pro and above

  • Schedulers
  • API keys
  • Cloud sandboxes
  • HITL approval gates

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

Configure once in the browser, freeze it into an immutable id@version, and sign in anywhere to run the exact same setup on your own machine.