282 orchestrators
Multi-level planners that decompose a goal and delegate — 212 on the first level, 68 on the second, and 2 at the top. Drop one in and you inherit a whole team's worth of routing.
OpenEng AI · the ecosystemDon't start from a blank prompt.
Don't start from a blank prompt.
Start from 5,100+ building blocks.
Browse and adopt agents, skills, templates, models, cells, plugins, loops, roles, and connectors — or import a whole Library bundle — then publish a config your engine just runs. Every catalog is content-as-code on a CDN. You assemble; you never start from zero.
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. The catalogs are live to browse; adopting, publishing, and running are how it is built to work.
1,092Agents
885Skills
754Templates
28On-device models
550Cells
1,524Roles
252Connectors
14Plugins
8Library bundles
6Global loops
The catalogs
Ten catalogs. One composable platform.
Each catalog is a live, deep-linkable gallery with a true count. Adopt what you need into your account, select it in a config, and the engine resolves it by name — no code to write.
Agents1,092
1,092 agents: 810 single-purpose agents and 282 orchestrators (212 / 68 / 2 on levels 1–3), across 35 categories.
agents.openeng.app
Skills885
Named, invocable playbooks the engine runs on demand, across 18 categories.
skills.openeng.app
Templates754
Prompt blueprints prepended above your persona, across 28 segments.
templates.openeng.app
Cells550
AWS / Azure / GCP cells (435 read, 115 write) exposing 1,053 cloud tools, deployed in your own cloud account.
cells.openeng.app
Models28
On-device open-weight models from the Ollama library, about 1 GB up to Llama 3.3 70B, run through your local Ollama — no provider API keys.
models.openeng.app
Plugins14
14 gateway plugins: 2 built-in modules and 12 external decision, approval, and tooling endpoints, layered above the security floor.
plugins.openeng.app
Loops6
Global loops: backlog burn-down and failing tests until green need no integration; alert triage, inbox-to-done, the nightly PR review sweep, and the ticket sweep need integrations that aren’t live yet.
loops.openeng.app
Library8
Curated bundles of agents, skills, templates, cells, and models — backend APIs, CI/CD, FinOps, Kubernetes, security, and more.
library.openeng.app
Roles1,524
Role definitions across 19 categories, each with the components and capabilities it needs.
roles.openeng.app
Connectors252
Bring-your-own-cloud connector packages for the Data, Terminal, and Kubernetes apps — AWS, Azure, GCP, and databases; 13 validated against live services so far.
connectors.openeng.app
Counts are read from each catalog’s live catalog.json, as of September 25, 2026. Each tile opens its catalog subdomain in a new tab.
Agents · 1,092
Orchestrators and specialists — not a flat list of prompts.
Orchestrators plan and delegate; single-purpose agents do one thing well. Compose a top-level orchestrator and it routes sub-tasks to specialists, up to three levels deep.
2 orchestratorslevel 3
68 orchestratorslevel 2
212 orchestratorslevel 1
plan & delegate
KubernetesDatabases & SQLSecurity & AppSecCI/CD PipelinesAWS CloudTesting & QA
810 single-purpose agents across 35 categories
810 single-purpose agents
Focused workers across 35 categories — Kubernetes, databases, security, CI/CD, the major clouds, testing, and more. Each is small, sharp, and recombinable.
Cells · 550
550 cloud cells, exposing 1,053 tools — in your own cloud account.
Cells give agents live signal from AWS, Azure, and GCP. Each one is deployed into your own account and runs under that deployment’s identity. Reading and writing are separate cells, so an agent only gets write access you deliberately add.
AWS · Azure · GCP
One cell model across all three clouds — list, describe, query, and inspect resources from the same agent config.
- 260 AWS · 150 Azure · 140 Google Cloud
- 1,053 tools exposed
Read and write are separate
435 cells only read; 115 can change things. Write cells are opt-in — you register them deliberately — and every call passes the engine’s security floor first.
Your cloud, your keys
Cells deploy to AWS Lambda, Azure Container Apps, or Google Cloud Run in your own account. A config holds only the
${ENV} name of each cell’s key — the value resolves on the machine running your engine.Models · 28
28 on-device open-weight models, one for every role.
The catalog’s models come from the Ollama library, from about 1 GB (Qwen2.5 Coder 1.5B) up to 43 GB (Llama 3.3 70B), grouped into the engine’s eleven role groups. The engine pulls and runs them through a local Ollama daemon that you install and run, so they execute inside Ollama rather than in the engine’s sandbox. No provider API keys — and you can add your own from Hugging Face, ModelScope, or a direct URL, in any major weight format (GGUF and ONNX run built in; the others need their runtime’s toolchain).
Checked against your hardware
Every catalog model lists its minimum requirements. When you build a config, the Console checks your machine profile against the models you picked before you publish.
Any format, the runtime that fits
GGUF, Safetensors, GPTQ/AWQ, EXL2/EXL3, MLX, ONNX, or TensorRT — the format determines which runtimes can run it, and the compatibility matrix is published at models.openeng.app/runtimes.json (it lists GPU offload for llama.cpp, a build option the published engine doesn’t include). Runtimes such as vLLM or SGLang are used only when their toolchain is installed on your machine. All through one role system, from a tiny laptop model to a 70B.
- Open-weight, no provider API keys
- Catalog models run in your local Ollama, which manages its own GPU use
Or bring your own
Point a role at any network endpoint — your own OpenAI-compatible API — and the engine routes to it through the same gateway. The same config, your cloud.
Loops and the Library
Work that repeats itself, and bundles that start you off.
Two catalogs that save you the setup: global loops that keep an agent on a job until it’s done, and a Library of curated bundles you import into a config in one step.
Loops · 6
6 global loops
Each loop repeats a request over a source — a backlog, an incident list, open pull requests, an inbox — on a cadence, until its stop condition is met, capped by iterations and an optional token budget. Two of them, backlog burn-down and failing tests until green, need no integration; the other four enumerate through integrations (PagerDuty, Gmail, GitHub, Jira) that aren’t live yet.
- Alert triage watch
- Backlog burn-down
- Failing-tests until green
- Inbox-to-done
- Nightly PR review sweep
- Ticket sweep
Library · 8
8 curated bundles
Ready-made sets of agents, skills, templates, cells, and models for a job — backend APIs, CI/CD and release engineering, cloud cost and FinOps, database reliability, frontend and web ops, Kubernetes operations, observability and incident response, and a security and compliance baseline. Import one into a config in one action.
Roles and Connectors
How your agents behave, and what they can reach.
Two more catalogs: behavioral roles that set how an agent works, and connectors that reach the clouds and databases your team already runs.
Roles · 1,524
1,524 roles in 19 categories
Each role definition describes a job — a product-metrics data analyst, say — with the components and capabilities it needs. In the Console you attach a base role to your agents and layer your own sharpen-only rules on top.
Connectors · 252
252 connectors, 13 validated live
Bring-your-own-cloud connector packages for the Data, Terminal, and Kubernetes apps: AWS, Azure, and GCP services, plus Kubernetes and databases such as PostgreSQL, MongoDB, Redis, and Kafka, each deployed in your own cloud as an AWS Lambda, Google Cloud Function, or Azure Function. 13 have been validated against live services so far — Kubernetes, PostgreSQL, MySQL, Redis, S3, and Kafka among them; the rest are checked against their specs. A config's Connectors step is separate: it attaches sandbox-isolated integrations (GitHub, GitLab, Jira, and more) from the Console's integrations catalog.
How it comes together
Compose your own agent. Freeze a version. Run it on your engine.
Assembling is the whole job — there's no glue code. You adopt building blocks, publish an immutable version, and every engine you run resolves that same version (MCP servers still come from each machine's .mcp.json).
step 1 · compose
Adopt and select
Adopt blocks from the catalogs into your Console account — or import a Library bundle — then select them in a config’s builder: a model per role group, the agents and skills it should call, the templates, roles, loops, cells, MCP servers, and connectors it may use.
step 2 · freeze
Publish id@version
Freeze the whole composition into an immutable, SemVer-versioned id@version. Publish-once with a strictly-higher version — you can always see exactly what a version contains.
step 3 · run
Run on your engine
Pick the config in the Web Console, or preload it when the engine starts, and your local engine pulls and runs it — the same config version on every machine, with the MCP servers each machine's .mcp.json supplies.
Preload a published config
How it's served
Everything is content-as-code, consumed read-only.
The catalogs aren't a closed marketplace. Every entry is a published file on a CDN that the engine and Console only read — never a service your data passes through.
Published to a CDN
Each catalog generates from definitions into a static catalog.json on its own subdomain — versioned, cacheable, and independent of any live service.
Read-only consumption
The engine and Console read catalog entries and resolve them locally. Fetching a catalog runs nothing and uploads nothing of yours; the cells you deploy run in your own cloud account.
The Console mirrors it
The Console reads the same CDN catalogs to show you what's available — a mirror of the content, not a source you depend on at runtime.
Questions
The ecosystem, answered.
Ten public catalogs: 1,092 agents, 885 skills, 754 templates, 28 on-device open-weight models, 550 cells exposing 1,053 cloud tools, 14 plugins, 1,524 roles, 252 connectors, 6 global loops (2 need no integration; 4 need integrations that aren’t live yet), and a library of 8 curated bundles. You adopt what you need into your Console account and select it in a config the engine runs. The 252 connectors are bring-your-own-cloud packages for the Data, Terminal, and Kubernetes apps, deployed in your own cloud; a config’s Connectors step attaches sandbox-isolated integrations (GitHub, GitLab, Jira, and more) from the Console’s integrations catalog.
Every catalog is content-as-code published to a CDN and read, never written, by the local engine and the Console. You adopt entries into your account, select them in a config, and freeze it into an immutable id@version; your engine pulls that same version on every machine, and a published version never changes. The engine doesn’t yet connect a config’s MCP servers (each machine’s .mcp.json supplies them) or apply its Directories and storage points.
The 550 cells deploy into your own cloud account — AWS Lambda, Azure Container Apps, or Google Cloud Run — and run under that deployment’s identity. 435 of them only read; the 115 write cells are opt-in, and every call passes the engine’s security floor before it executes.
Stop writing prompts from scratch. Start composing.
Browse the catalogs today. Adopting building blocks in the Console, publishing a config, and running it from the Web Console on your own engine open once OpenEng AI’s API and Broker are deployed.