openagentix turns events into finished work. A webhook, a Kafka message, an e-mail or a schedule starts a run. Agents act through MCP tools. Every tool call is checked before it runs, written to a tamper-evident audit trail and priced to the cent.
How a run flows through openagentixEvents from Kafka, webhooks, Kafka log streams, e-mail, Microsoft Teams (through a webhook) and cron enter the platform on the left. Inside, one to three agents pass the work along. Every tool call passes the agent’s audit gate first, a global control agent watches budgets and guardrails, and each step is appended to a hash-chained audit trail. Results leave on the right through the tools an agent is granted, for example as pull requests, updated tickets, chat messages or reports. The result targets shown are illustrative; declared output targets are planned.Nightly schedule: scan container images, fix the vulnerable dependency, open a pull request.Jira webhook: classify the ticket, check the runbook, update the ticket.Kafka message: investigate failed orders read-only, then send a report and a chat summary.E-mail: an agent tries a bank transfer that is not on its allowlist. Blocked, logged, approval requested.Teams message via webhook: analyse the incident logs, post a summary, export metrics.Kafka log stream: spot anomalies, push metrics, write a short report.
Why openagentix
Agents are easy to demo and hard to run.
The problem
Black boxes
Who allowed the agent to call that API, and with which data? Most setups cannot say.
Runaway costs
A loop or a chatty prompt burns through the budget quietly until the invoice arrives.
Glue everywhere
Every team wires up its own triggers, secrets and scripts. Nothing is reused, nothing is reviewed.
The answer
One platform with the guardrails built in.
Policy before action
Allowlists and argument rules are checked in code before every tool call.
Costs on every step
Tokens, prices and tool calls per step, with budgets that stop a run instead of just warning.
Shared building blocks
Events, connections and agents are declared once, versioned and reused across teams.
How it works
From event to outcome, one guarded step at a time.
Step 1 of 5
01Event in
An event arrives.
A signed webhook, a Kafka topic, a schedule or an e-mail. Chat messages arrive through a webhook. openagentix verifies the event, stores it and starts a run.
02Audit gate
Every tool call is checked first.
Before an agent touches a tool, its audit gate compares the call with the allowlist and argument rules. Deterministic code, not a model. If the call does not match, it does not run.
03Agents
Agents pass the work along.
One agent or a pipeline of several, defined in a versioned agents.md. Each one gets only the tools and data it needs.
04Control agent
A control agent watches every run.
Budgets, rates, data classes and forbidden actions apply across all runs. It can pause or stop a run. Its rules are deterministic code today; an optional model second opinion is planned (0.4).
05Results out
Results land where your team works.
Agents deliver through the tools they are granted: a pull request, an updated ticket, a chat message or a report. Each one traceable to the event that caused it. Declared output targets are planned.
Target architecture · roadmap 0.2
A control node that decides. Workers that only do.
The control node holds the registry, the policy gates, the audit chain, costs and metrics, and never executes a tool itself. By default the worker runs in-process or locally. The spawned, short-lived workers shown here are on main as an opt-in container runner and ship with 0.2; the signed toolbox images are still planned.
Control node
Registry
Policy gates
Audit chain
Costs
Metrics
never executes tools
signed run tokenpolicy checksteps streamed back
Worker node · opt-in, 0.2
Toolbox image · planned
git + node
trivy
jira-cli
signed
scanned
SBOM
egress allowlisted
removed · secrets revoked
Step 1 of 4
01Control node
The control node plans the run.
It loads the agent version from the registry, checks the budget and issues a short-lived, signed run token. Nothing is executed here.
02Spawn
A worker starts with exactly the tools it needs.
On main, opt-in (OAX_CONTAINER_*), ships with 0.2: the runner starts a hardened container per step, with allowlisted outbound traffic. Toolbox images (git + node, trivy, jira-cli; minimal, signed, scanned, pinned by digest) are still planned.
03Ask first
The worker asks before every tool call.
Each call goes to the policy gate first, with the signed run token. Steps are recorded in the audit chain. This holds for the in-process worker and for the opt-in container runner.
04Tear down
Then the worker is gone.
On main, opt-in, ships with 0.2: when the step ends, the container is removed and its per-step credentials are revoked by the credential broker.
The console
See every run, step by step.
Runs, steps, decisions, costs and audit entries in one place, live as they happen.
Run #4821 · cve-autofix
Triggered by cron · nightly 03:00 · 41 s
Succeeded
StepTool / modelGateCost
Event receivedcron · nightlyverified–
Model callbedrock · eu-central-1–$0.08
Tool calltrivy.scanallowed$0.00
Model callbedrock · eu-central-1–$0.11
Tool callgithub.open_prallowed$0.00
Tool callgithub.mergeblocked–
Audit chainVerified · 1,204 entries
Budget$0.42 of $5.00
Tokens18,240 in · 2,115 out
ApprovalsMerge needs a human
Built for the whole team
Four perspectives, one source of truth.
Business user
Describes the workflow
“When a Jira ticket with the label payment comes in, check the runbook, then update the ticket.” Described in plain language in an Agent Plan; an engineer turns it into steps.
Integrator
Provides the interfaces
Connects MCP servers, APIs and event sources. Credentials stay in your secret store and are referenced by name, never pasted into prompts.
Agent engineer
Assembles and ships
Turns the description into a versioned agents.md with tools, budgets and approvals, test-runs it and publishes an immutable version. Test suites and promotion gates are planned.
Auditor
Reviews with evidence
Reads the tamper-evident audit trail, costs and policies, and can verify the hash chain independently.
Features
Everything an agent needs to run under control.
Revision-safe audit
Append-only and SHA-256 hash-chained, with signed checkpoints. A verify command detects tampering.
Events in
Signed webhooks, Kafka, cron and e-mail start runs; Teams and Slack today through a webhook, with dedicated adapters planned for 0.3. Every event is verified and becomes a CloudEvent with a full trail.
Bring your own MCP
Register your MCP servers per tenant, team or agent and group their tools into named read/write profiles (both next release, 0.2); servers run as containers are planned. Every agent gets its own tool allowlist and argument rules, enforced in code.
Cost per agent, use case and run
Every cost line carries tenant, agent, use case, run, step, model and provider. Aggregate by any of them, export as CSV or JSON, and stop runs with hard budgets.
Tenants and per-agent access
Tenants isolate agents, runs, keys, audit and costs (next release, 0.2). Roles are granted per tenant and, if you like, per agent, so people only see the agents they work on. OIDC and LDAP/AD are optional; one person can hold every role.
Configurable runs
Steps, timeouts, approvals and data classification per agent, versioned in agents.md.
Metrics and traces
Prometheus metrics, OpenTelemetry traces and JSON logs, correlated by run ID. Traces have one span per run today; per-step spans are planned.
Bring your own keys and models
OpenAI-compatible APIs (for example Azure OpenAI, OpenRouter, vLLM; not yet verified with real accounts), Ollama, Anthropic and AWS Bedrock. Keys are references. Scoping them to a tenant, team or agent and the model catalog from a pinned models.dev snapshot arrive in the next release (0.2).
Secrets by reference
Connections point to environment variables or Kubernetes Secrets. Values are redacted in logs and audit entries.
Air-gapped mode
No remote prompts, skills or telemetry, and no model list fetched at run time. With local models and your own MCP servers, nothing has to leave your network. A fail-closed switch arrives in the next release (0.2); an external harness still needs its own egress.
Helm and EKS
A Helm chart with IRSA, NetworkPolicies, restricted PodSecurity, autoscaling and a migration job. It renders and lints in CI; an install test follows once the API image is published.
Human in the loop
Mark sensitive tools as approval-required. The run waits until a person decides.
Change-gated schedules
A schedule can check first, with plain code and no model: a hash of a page or file (API responses and queries are planned). The run only starts when something changed, so quiet nights cost nothing.
Guidelines and a hardening agent
Versioned development guidelines attach to an agent or a tenant. A deterministic hardening review can be run on demand; automatic review of pull requests is planned (0.4).
Dark software factory
Opt-in mode with a fixed notice today; a spec, code, tests and pull request template is planned (0.4). Recommended for MVP and proof-of-concept development only. Not for production changes without review.
Four-eyes publishing for agents
Planned
Agents are developed as drafts. With a four-eyes policy enabled for a tenant, publishing needs the approval of another person: reviewers see the exact changes to agents.md, comment on single lines, and approve, request changes or reject, much like a pull-request review. An approval is bound to the exact content, so any later edit needs a new approval. Today agents have drafts and immutable published versions, and the author can publish their own draft; review and approval are not built yet.
Credentials like in a CI server, encrypted
Planned
Tokens and secrets stored per team or tenant, encrypted with a key per tenant and referenced by name in agents. Runs can use the values, nobody can read them back. Personal tokens are possible for development and stay out of published agents unless the tenant policy explicitly allows it. HashiCorp Vault and AWS Secrets Manager are planned as alternative secret backends. Today secrets come from the operator's environment or mounted files; the encrypted store is not built yet.
Runners
Run agents anywhere.
In-process or on your own machine today, containers opt-in on main. Kubernetes or EKS, AWS Lambda, GitHub Actions and GitLab CI are on the roadmap. Optionally with your favourite harness. Always through the same policy gate.
Same policy gate · same audit chain · same budgets
Available in 0.1
In-process
The default. Runs inside the worker with no extra moving parts.
Available in 0.1
Local CLI
oax run agents.md --event event.json on your own machine.
Roadmap
Containers
On main, opt-in, ships with 0.2: Docker or Podman, one short-lived container per step, read-only, egress allowlisted.
Roadmap
Kubernetes / EKS
Planned: one Job per step with its own ServiceAccount, IRSA and NetworkPolicy. A building block is on main, not yet wired into the platform.
Roadmap
AWS Lambda
One function per agent version, attached to your VPC for Bedrock endpoints.
Roadmap
GitHub Actions
workflow_dispatch in a target repository; results come back through a signed callback.
Roadmap
GitLab CI
A pipeline trigger token and the same signed callback.
By default workers run in-process or locally. The container runner and credential broker are on main (opt-in, ship with 0.2). A Kubernetes Job runner exists on main as a building block, not yet wired into the platform. AWS Lambda and CI runners come later.
Next release
Bring your harness. Optional.
An adapter translates agents.md into the harness configuration and routes every tool call through the openagentix policy gate, so audit, control agent and costs stay identical. Claude Code is verified with real runs (in-process, 2026-10-04; next release, 0.2). The isolated run-node path through the model proxy is implemented; its real-run verification is pending. The OpenCode adapter is implemented and tested against a fake CLI; real-run verification is pending. Hermes and OpenClaw are planned. The platform works fully without any harness.
Claude Code
OpenCode
Hermes
OpenClaw
Enterprise trust
Proof, not promises.
Tamper-evident audit trail
Every entry carries the SHA-256 of the entry before it. Change a single byte and verification fails from that point on.
Permissions per resource, scoped by tenant and optionally by agent. Every API route declares the permission it needs, and tests enforce it.
Role
agents
runs
connections
policies
audit
costs
admin
manage
manage
manage
manage
read
read
agent-engineer
manage
manage
read
read
no access
read
integrator
read
read
manage
read
no access
read
operator
read
manage
no access
no access
no access
read
auditor
read
read
read
read
read
read
viewer
read
read
no access
no access
no access
read
managereadno access
Costs you can explain
Per run, step, agent, use case and tenant. Budgets stop a run before it overspends.
cve-autofix$18.40
ticket-triage$42.10
incident-summary$9.75
Monthly budget$70.25 of $150.00
Use cases
From the enterprise to the homelab.
One person on a single server can hold every role. A company adds tenants, single sign-on and signed checkpoints. The core stays the same. The cases below are examples of what you can build; the repository ships cve-triage, ticket-triage, ticket-updater and code-quality-reviewer as runnable examples, more are planned.
Enterprise
Ticket triage
Classify incoming Jira tickets, check runbooks, update fields and route them to the right team.
Security remediation
Triage CVEs across hundreds of images and open fix pull requests, with an approval before merge.
Incident summaries
Collect logs and metrics on a Teams message (through a webhook relay) and post a timeline the on-call engineer can trust.
Compliance evidence
Gather evidence for audits on a schedule and file a report that can be traced to its sources.
Small teams and homelabs
CVE triage for container images
Scan your images every night and get a short, ranked list instead of three hundred findings.
Log anomaly summaries
A digest of what looked unusual in the last six hours, delivered to your chat.
Auto-repair pull requests
Small fixes as pull requests: dependency bumps, configuration drift, failing health checks.
Inbox to tasks
Turn e-mails such as invoices or alerts into tickets, with any payment step held for approval.
Built by an agent
This platform is built by an agent.
agentix-zero writes the code, tests and documentation of open-agentix. The project’s rule is that every change goes through a pull request with the same kind of gates the platform enforces for your agents, followed by an independent review before merge (a second review agent).
agentix-zero is the project’s agent account. Pull requests get an independent review by a second review agent; the maintainer owns the decisions.
Rules for every change
Conventional Commit
Tests · coverage ≥ 80 %
No third-party requests
Independent review
Open source
Apache-2.0. Self-hosted. Yours.
Read the code, run it on your own hardware, extend it. Audit, RBAC and cost controls are part of the open-source core.
Events, agents.md, audit gate, control agent, hash-chained audit, costs, in-process and local runners.
0.2
On main: tenants, scoped model keys, monthly budgets, air-gapped switch, typed handovers, tool profiles, Agent Check, Claude Code harness. Container workers: opt-in on main. Planned: signed toolbox images.
0.3
AWS Lambda, GitHub Actions and GitLab CI runners; Hermes and OpenClaw harnesses; Slack and Teams adapters.
0.4
Planned: agent lifecycle with Agent Build, evaluations, version approval and four-eyes publishing with review comments; encrypted team and tenant secrets with Vault and AWS Secrets Manager backends.
1.0
Stable APIs, signed releases, documented upgrades and a demo on release images.
Start with one event.
Run openagentix with Docker Compose, connect a webhook and watch the first run land on the record.