iii: waarom drie primitieven genoeg zijn om je hele backend te herschrijven — en wat dat betekent voor AI-agents

Software-engineering is een oefening in het assembleren van servicecategorieën. Elke nieuwe capability — een queue, een cron-job, een HTTP-endpoint, een state store, een observability-stack, een agent — brengt zijn eigen integratieverhaal mee. De complexiteit van daadwerkelijke integraties is kwadratisch: vier services betekent zes mogelijke koppelingen, twintig betekent er 190. Elke toevoeging verergert de coördinatiekost van alles wat eraan voorafging.

iii stelt dat dit niet nodig is. Drie primitieven — Worker, Function, Trigger — volstaan om élke backend-capability te modelleren. En dat heeft consequenties voor hoe we over AI-agents denken.

---

Wat iii is — en wat het niet is

iii is geen webframework. Geen queue. Geen workflow-engine. Geen agent-framework. Het is een runtime-unificatie-laag: een engine (Rust) die elke backend-capability modelleert als hetzelfde drietal primitieven, ongeacht taal, runtime of infrastructuur.

| Primitief | Wat het is | Voorbeeld | |-----------|-----------|-----------| | Worker | Een proces dat zich registreert bij de engine | Een TypeScript API-service, een Python data-pipeline, een Rust microservice | | Function | Een stabiel aanroepbare unit of work | orders::validate, docs::summarize, policy::check | | Trigger | Wat een function activeert | HTTP-request, cron-schedule, queue-bericht, state change, stream event |

Het mentale model is radicaal eenvoudig: iii worker add queue, iii worker add agent, iii worker add sandbox. Elke worker voegt zich bij de live catalogus. Elke andere worker wordt genotificeerd en kan hem onmiddellijk aanroepen. De marginale integratiekost wordt nul.

"iii ends the compound interest on complexity. Adding four workers, or twenty, takes the same effort: zero."

---

Waarom dit ertoe doet voor AI-agents

iii positioneert agents niet als aparte infrastructuurcategorie maar als workers — zelfde protocol, zelfde traces, zelfde engine. Een agent registreert functions zoals agent::plan, agent::run_tools, agent::synthesize. Een tool-runner is een worker. Een policy-gateway is een worker. Een sandbox is een worker.

Dit is fundamenteel anders dan de huidige agent-architectuur. Waar MCP tools beschrijft die agents kunnen benaderen, biedt iii een runtime waarin agents, services, queues, cronjobs, streams en business functions allemaal onderdeel worden van één live catalogus. MCP beantwoordt "hoe praat een agent met een tool?" iii beantwoordt "hoe bestaan capabilities als runtime-services die elkaar ontdekken en aanroepen?"

Voor DjimIT's AI-harness betekent dit een architectuur die er zo uitziet:

Human / Operator / Architect
        |
OpenCode / Claude Code / Codex / Kilo
        |
Agent Harness Layer — Skills, Hooks, CLAUDE.md, policy prompts
        |
iii Capability Runtime — Workers, Functions, Triggers, State, Streams
        |
Existing Execution Substrates — Docker, Proxmox, local inference, APIs
        |
Policy & Governance Plane — OIDC, OAuth2, secrets, signing, SBOM, audit

De beste rol voor iii is niet "MCP-vervanger" maar MCP-adjacent runtime. MCP beschrijft hoe agents tools benaderen. iii beschrijft hoe capabilities als runtime-services bestaan.

---

De scherpe kant: wat iii krachtig maakt, maakt het ook gevaarlijk

iii's meest onderscheidende feature is tegelijk het grootste risico: workers kunnen andere workers runtime creëren. Agents en applicaties kunnen het systeem uitbreiden terwijl het draait.

Dit is precies waar governance scherp moet zijn. Zonder harde policy gates ontstaan nieuwe aanvalsvlakken:

| Risico | Scenario | Mitigatie | |--------|----------|-----------| | Capability sprawl | Agent voegt ongecontroleerd workers toe | Signed worker registry, allowlist, approval flow | | Prompt injection naar runtime | Agent krijgt indirect opdracht om worker te misbruiken | Tool authorization, policy-as-code, HITL voor high-risk actions | | Function privilege escalation | Worker exposeert filesystem, shell, network of secrets | Least privilege, sandboxing, network egress policy | | Trace leakage | Logs en traces bevatten prompts, tokens of PII | Redaction, retention policy, data classification | | Supply chain | iii worker add haalt capabilities uit externe bron | SBOM, provenance, signature verification, private registry |

In DjimIT's architectuur moet daarom niet iii worker add centraal staan, maar:

iii worker add, only after policy approval, provenance validation, sandbox classification, and audit registration.

---

Licentie: de strategische rem

Een kritiek punt dat vaak over het hoofd wordt gezien: de iii-engine is niet Apache 2.0. Hij is gelicenseerd onder de Elastic License 2.0 (ELv2). De SDK's, CLI, console, documentatie en website zijn wél Apache 2.0 — maar de engine niet.

Voor DjimIT betekent dit: prima voor lab, PoC en intern gebruik. Maar voordat iii als platformcomponent wordt gecommercialiseerd, als managed service wordt aangeboden, of als embedded runtime in een klantproduct wordt gebruikt, is juridische toetsing vereist. ELv2 is geen klassieke permissieve open-source licentie.

---

Positionering ten opzichte van bestaande lagen

iii vervangt niet alles. Het positioneert zich naast — niet in plaats van — bestaande tools:

| Component | Primair doel | iii-verhouding | |-----------|-------------|----------------| | LiteLLM | Model gateway, routing, budgetten | Complementair — iii kan LiteLLM als worker exposen | | MCP | Tool protocol voor LLM-clients | Complementair — MCP kan iii-functions aanbieden of consumeren | | n8n | Low-code workflow automation | iii is developer/runtime-first, n8n is workflow-UI-first | | Temporal | Durable workflow execution | Temporal is volwassener voor mission-critical; iii is eenvoudiger en agent-friendlier | | LangGraph | Agent state machines | LangGraph orkestreert agent logic, iii orkestreert runtime capabilities | | Kubernetes operators | Runtime lifecycle en service discovery | Overlap in service discovery, maar iii is lichtgewicht en agent-native | | OpenTelemetry | Observability en tracing | iii biedt eigen traces, metrics en logs — complementair, niet vervangend |

iii is geen LiteLLM-alternatief en ook geen zuiver MCP-alternatief. Het is een backend capability fabric waar agents, services en workflows dezelfde operationele taal spreken.

---

Security baseline voor verantwoord gebruik

Voor een veilige PoC zijn deze guardrails het minimum:

• Draai iii geïsoleerd in Docker of VM, niet direct op primaire machines
• WebSocket (49134) en HTTP API (3111) niet open buiten localhost of private subnet
• Reverse proxy met TLS en expliciete authenticatie voor remote access
• Private worker registry — geen ongecontroleerde externe worker add
• Runtime worker creation alleen via policy gate
• Label functions met sensitivity: public, internal, restricted, privileged
• OIDC/OAuth2 voor identity propagation bij externe toegang
• Log alle function invocations met correlation ID, actor, source worker, policy decision
• Redact prompts, tokens, secrets en PII uit traces
• Test prompt injection expliciet tegen workers met filesystem, shell, network, browser of secrets-toegang

De engine zelf geeft al supply chain-signalen: distroless runtime, non-root execution, Trivy scanning in CI, SBOM attestation en build provenance. Dat zijn relevante baselines voor een secure-by-design architectuur.

---

Praktische validatie: een 5-daagse PoC

Dag 1 — Runtime smoke test. Installeer iii lokaal of via Docker. Start de engine. Controleer WebSocket (49134), HTTP API (3111), Stream API (3112), Prometheus metrics (9464) en de console.

Dag 2 — Drie workers bouwen. Eén TypeScript HTTP-worker, één Python data-worker, één Rust utility-worker. Registreer functies met domain::action naming: docs::summarize, repo::classify, policy::check.

Dag 3 — Agent-integratie. Installeer de iii skills via npx skills add iii-hq/iii/skills. Test of OpenCode en Claude Code workers kunnen ontdekken en functions kunnen aanroepen via de live catalogus.

Dag 4 — Security test. Mini threat model op: worker registration, function invocation, trigger registration, secrets exposure, logs/traces, runtime worker creation, network egress.

Dag 5 — Beslissing. Beoordeel met deze scorecard:

| Criterium | Go/no-go vraag | |-----------|---------------| | Developer experience | Kan OpenCode/Claude Code snel betrouwbare workers maken? | | Security | Kunnen we runtime extension hard begrenzen? | | Observability | Zien we elke agent actie, trigger en function call? | | Portability | Werkt dit op Ubuntu server, Mac Mini en Proxmox? | | Governance | Kunnen we policies, ownership en auditability afdwingen? | | Complexity | Vervangt iii complexiteit of introduceert het een extra platformlaag? |

---

Wat DjimIT hiermee doet

DjimIT ziet iii als experimentele agentic backend fabric voor lokale en hybride scenario's. Niet als vervanger van bestaande infrastructuur, maar als de laag die agents, tools, queues en state verenigt onder één runtime-contract.

Onze aanpak:

• iii als capability runtime onder OpenCode, Claude Code en Kilo
• LiteLLM voor model-routing en budgetten
• MCP voor tool-protocol integratie
• Prometheus + OpenTelemetry voor observability
• Een eigen policy gate voor worker/function authorization

De belangrijkste les uit deze analyse: iii maakt capability-extensie extreem makkelijk. Dat is de strategische kracht, maar ook het primaire governance-risico. In een volwassen architectuur staat niet iii worker add centraal, maar iii worker add, only after policy approval.

---

iii op GitHub: github.com/iii-hq/iii. Lees ook onze analyses van DeepSeek's architectuurevolutie, de OWASP Agentic Control Plane, en Kairos temporal alignment.