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.