| Agent |
A z4j process running inside your app, connected to z4j via WebSocket. One per app process. |
| Brain |
The central z4j server - FastAPI + React dashboard + Postgres. One per organization. |
| Broker |
The message transport underneath your queue engine (Redis, RabbitMQ, SQS). z4j observes queues but does not act as a broker. |
| Capability map |
JSON object each agent sends in hello, advertising which actions it supports natively vs. which need polyfill. |
| Control plane |
The management layer that observes and acts on task infrastructure without participating in the task runtime. |
| Engine |
A Python task-queue library (Celery, RQ, Dramatiq, Huey, arq, taskiq). z4j adapts to each. |
| Engine adapter |
A z4j pip package (z4j-celery, etc.) that bridges engine-specific APIs to the z4j wire protocol. |
| Event |
A timestamped record of a task lifecycle transition (task_sent, task_started, task_succeeded, …). |
| Framework adapter |
A z4j pip package (z4j-django, etc.) that hooks into the framework’s boot and settings. |
| HMAC chain |
The audit log’s tamper-evidence mechanism - each row’s HMAC depends on the previous row’s. |
| Polyfill |
When z4j implements an action that the engine doesn’t expose natively (e.g., bulk retry for arq). |
| Project |
The tenancy boundary in z4j. Agents, tasks, users - all scoped to a project. |
| Reconciliation |
The background process that finds “started-forever” tasks and queries the agent about their real state. |
| Redaction |
Stripping secrets from event payloads before they leave the agent. |
| Scheduler |
A periodic-task system paired with an engine (celery-beat, rq-scheduler, APScheduler, etc.). |
| Scheduler adapter |
A z4j pip package (z4j-celerybeat, etc.) that bridges schedule discovery and CRUD. |
| Setup URL |
The first-boot one-shot URL z4j prints so the operator can create the initial admin. |
| Wire protocol |
The JSON-over-WebSocket framing that agents and z4j speak. Versioned; currently v1. |
