An agent server. Every AI product runs one. Nobody ships you one.
contenox is that layer as a server you run yourself — on your machine, on any model. Every action is checked against your policy before it happens.
You don't build an agent. You declare one.
Markdown with a YAML frontmatter header — the same file Claude Code reads. Drop it in and the next run picks it up: no build step, no plugin API, nothing to convert.
Installs contenox. Run contenox init to scaffold a workspace.
The mission, live
Thirty seconds, end to end.
One command fires a declared agent at a task, bounded by a policy you wrote. What happens after you walk away is the point.
No babysitting a terminal, no timed-out approvals, no silent changes. The envelope decided what could run unattended, the agent you declared decided nothing beyond it, and one answer resumed the run exactly once.
The part you can’t download
You’ve already used this engine. You’ve just never held the controls.
When an assistant shows you its "thinking steps," you’re watching an orchestration loop: plan, call a tool, check the result, check the budget, decide again. Every major AI product runs on one — event-driven agent choreography under governance. That layer decides what the model may do, when it pauses, and what it costs. The vendor configures it. You never see it, and you can’t change it.
Contenox is that layer, shipped as the product — with the control panel handed to the operator. The agent is a file you declare. The boundaries are an envelope you wrote. The loop it generates is JSON you can read, and take the pen to. The state is on your disk. The differentiator isn’t inventing the machine; it’s who holds the controls.
Route → workflow → agent loop
One sentence in. The loop that sentence deserves.
Behind an agent is a chain, and the interactive ones do not begin with a single loop. They begin with a route task that reads the request, labels it, and hands it to the loop built for that label — its own instruction, its own tool scope, its own budget, its own recovery path. The chains that ship with contenox sort every message into coding_change, general, or review_change before anything else runs.
{
"id": "classify_request",
"handler": "route",
"system_instruction": "Classify the user's latest message. Use 'coding_change'
for requests to create, edit, refactor, fix, test or otherwise change
code/files. Use 'general' for questions, explanations, setup help. Use
'review_change' for requests to review, audit or assess code that already
exists, where nothing is to be modified...",
"execute_config": { "model": "{{var:alt_model|var:model}}", "tools": [] },
"transition": {
"on_failure": "acp_chat",
"branches": [
{ "operator": "equals", "when": "coding_change", "goto": "coding_chat" },
{ "operator": "equals", "when": "general", "goto": "acp_chat" },
{ "operator": "equals", "when": "review_change", "goto": "review_chat" },
{ "operator": "default", "when": "", "goto": "acp_chat" }
]
}
} Trimmed from the shipped chain-agent-acp.json. The classifier holds no tools, so it cannot act on a request it has not yet understood, and it can run on a cheaper model than the loops it feeds. An unrecognised label falls to the default branch — the least-powerful loop, never the most. Which branch ran is in the run log, so a disappointing answer is a question with an answer.
- →A specialist is configuration, not phrasing: the review loop withholds every mutating tool with hide_tools, enforced where calls execute rather than by leaving them out of what the model was offered.
- →A support assistant routes billing questions to a read-only loop with the billing API, and account changes to one that can write but pauses for a human.
- →A data workflow routes "summarise this" and "extract these fields" to loops with different output contracts, so callers get parseable output without asking for it every time.
- →A governed deployment routes anything touching regulated data to a loop under a stricter policy, no matter how the request was phrased.
You write the rules
How much agency? You decide — in writing.
Every run is bounded by an envelope: a JSON policy naming what passes silently, what pauses for a human, and what is denied outright — plus hard ceilings on tool calls and tokens, and a pin on which models and backends the unit may use. No hidden prompt decides for you. The file lives in your repo and gets reviewed like any other change.
{
"default_action": "approve",
"compute": { "maxToolCalls": 300, "maxTokens": 2000000, "onExhausted": "finish_stuck" },
"rules": [
{ "tools": "local_fs", "tool": "*", "action": "deny",
"when": [{ "key": "path", "op": "glob",
"value": "**/{.ssh,.aws,.kube,.config/gcloud}/**" }] },
{ "tools": "local_fs", "tool": "read_file", "action": "allow" },
{ "tools": "local_fs", "tool": "write_file", "action": "approve" },
{ "tools": "local_shell", "tool": "local_shell", "action": "allow",
"when": [{ "key": "command", "op": "command_prefix_allowlist",
"value": "go test,go vet,ls,cat,grep,npm test,pytest" }] },
{ "tools": "local_shell", "tool": "local_shell", "action": "approve" }
],
"attention": { "allowAgentAnswers": false }
} Trimmed from the shipped default preset. Anything no rule matches fails closed — it asks a human. Six presets ship with contenox init, and contenox vet checks your policy before anything runs under it.
Agentic engineering
Vibecoding finds the loop. Loop engineering keeps it.
Vibecoding is real discovery — improvising with an agent until the loop works. We’ve shipped features that way and written honestly about what it cost. But a loop that has to run tomorrow, in CI, unattended, isn’t a vibe anymore. It’s an artifact.
That’s agentic engineering: the loop is authored, reviewed, versioned, and bounded — and so is the choice of which loop runs. Every stage in a contenox chain came from a named failure mode, under one discipline: never let confusion default into unattended mutation.
One harness, everywhere
Author once. Run it where the work is.
The same agentic workflow, the same envelope, the same session state behind every surface — what you approved in the editor is what runs from cron.
Your terminal
contenox "your prompt" is a session-backed chat: history carries across invocations, stateful tools keep their state across turns, and a gated call stops for your approval before it runs.
Your editor
The full agent inside Zed, JetBrains, AionUi, or OpenClaw — approvals route through the editor’s own UI, and the agent stays in your files, not the plugin.
Your scripts and pipelines
contenox run executes a chain non-interactively — from cron, CI, or a shell script. Tool-heavy jobs are the home ground: release evidence packs, request-processing chains, narrow API wrappers with approval on every mutating call.
Untrusted drivers
A headless acpx session gets the hardened profile: shell, writes, and network are denied outright rather than offered for approval.
- → Editors talk to the full agent over stdio — no plugin lock-in. Agent Client Protocol
- → Any MCP server — stdio, SSE, or HTTP — registers once; its tools become policy-scoped chain tools. Model Context Protocol
- → Any HTTP service with a spec becomes a callable, allowlistable tool. OpenAPI tools guide
The same seat, contested
Copilot helps you type. Contenox does the shift while you’re gone.
The AI that does work for you at work is one seat, and there are two ways to fill it. The vendor’s agent runs on your work: behavior decided in Redmond, rules you can’t read, tenant-admin-controlled, your usage flowing into their telemetry.
Contenox is the other way to fill it: your agent under your envelope — rules you wrote, state on your disk, models you chose. Not two categories. One category, contested from opposite ends.
Yours by default
Your machine, your state, your models.
- →Sessions, config, run logs, and captured execution state live on your machine. No account, no contenox service in the loop — unless you pair with the optional relay below. Telemetry is opt-in and off by default.
- →Inference is configuration: local Ollama or vLLM when nothing may leave your network, or OpenAI, Anthropic, Gemini, Bedrock, and Vertex on your own keys, pinned to a region you choose. Swapping later is a config change, not a rewrite.
- →Secrets resolve from your environment at request time and never land in config on disk; agent-reachable shells get a scrubbed environment with only what the task needs.
Optional: the hosted relay
Your session, on your phone.
Everything above runs without an account. When you want a running session reachable from elsewhere, pair the machine with the hosted relay: one typed key from the contenox app, no browser on the machine. The machine dials out and sends exactly two things — the key and its hostname — and from then on you read the transcript and answer approvals from your phone. Free for you and three teammates, one machine each — and an install that never pairs contacts no relay at all.
We can also provision and run contenox agents for you — managed, on your terms — and we are looking for early design partners: talk to us.
Get started
Fire your first mission.
Questions? hello@contenox.com · Issues and PRs on GitHub
Built on
Local models connect through Ollama or vLLM over their local APIs; hosted providers over their public APIs. No bundled inference runtime, no GPU drivers to ship.
