BETA
Human-in-the-loop case management Open source · Apache 2.0

When an agent needs a person, the decision is made here.

K9X HIL is where AI applications built on K9-AIF hand a decision to a human: a review gate, an escalated finding, a low-confidence result. Each request arrives over Kafka as a task in its application's queue; a reviewer approves, rejects or escalates it, and the decision goes back to the waiting workflow, which resumes exactly once.

Demo login: [email protected] / demo · open public demonstration: you see and decide the live tasks from the K9X demos, such as DAS review gates. Shared login; do not enter real or personal information.

What it does

One place for every decision a person has to make in an agentic workflow, organised the way the workflows are: projects, their applications, and each application's queues.

Kafka-native queues

Each queue is a Kafka topic. An application publishes a task to its queue and listens on its reply topic; nothing calls HIL over HTTP, and HIL never calls back into the application.

Projects → Applications → Tasks

Pick a project, then an application, and see its tasks by status: Pending, In progress, Escalated, Completed, Critical. Sort any column, filter by queue, or find a job by its ID.

Decisions go back, once

Only a final decision (complete, reject, expire) is published to the task's reply topic with its correlation ID. A compare-and-swap on the task and a reply outbox make sure the waiting flow resumes once, even if a message is delivered twice.

Deadlines

A task can carry a time limit and what to do when it runs out. A sweep expires overdue tasks and sends that outcome back, so a workflow is never left waiting forever.

The evidence, in the task

The agent's rationale and payload are shown as readable details, and attached documents (object-storage links) open in the task, so the reviewer decides with the material in front of them.

Roles and audit

Admin, manager and assignee roles decide who may act. Every action (claim, start, complete, reject, escalate) is recorded with who and when. Malformed messages go to a dead-letter topic instead of being dropped.

How it works

A K9-AIF workflow pauses for a person without blocking, and picks up where it left off when the decision arrives.

1 · RAISEAn agent asks for a personAn agent or squad raises RequiresHIL; the orchestrator publishes the request to hil.requests.<queue> and returns "pending".
2 · QUEUEA task appearsHIL consumes the message and files a task in the application's queue, with priority, deadline and the agent's evidence.
3 · DECIDEA reviewer actsClaim, start, then complete, reject or escalate, with a comment. Escalation keeps the task open for someone else.
4 · REPLYThe decision is publishedThe final decision goes to the task's reply topic with its correlation ID; the outbox retries until it is delivered.
5 · RESUMEThe workflow continuesThe K9-AIF router matches the correlation ID to the paused flow and resumes it once, with the decision in hand.

Architecture

HIL sits beside the applications, connected only by Kafka topics.

Orchestratorcatches RequiresHIL, records the paused flow
→
Kafkahil.requests.<queue>
→
K9X HILconsumer · tasks in PostgreSQL · web UI · deadline sweep · reply outbox
→
Kafkahil.replies.* (the task's reply topic)
→
K9-AIF Routerresumes the flow once, by correlation ID

The queues in this demonstration belong to the K9X example applications, among them K9X DAS (its acquisition review gates) and K9X Continuum (building-block promotion reviews). A separate HIL instance on the internal network receives K9X Sentinel's security findings for framework administrators.

One HIL per project, in its own colours

A project can run its own instance of K9X HIL, rebranded for it, beside this shared one. Its reviewers sign in to a case-management app that carries the project's name and colours and shows only its own queues.

  • Its own branding. Name, subtitle, accent colour, logo text and an about line, set in one instance file; the instance's administrator can change them later.
  • Its own projects, applications and queues. The same file lists them, down to each queue's Kafka topic and deadline.
  • Its own data and identity. A separate database schema, Kafka consumer group, sign-in secret and port, so two instances never see each other's tasks.
  • The same software. Every instance runs the same image as this one and is started with one command; an upgrade reaches all of them.
K9X HILthis shared instance: every K9X demonstration's queues
K9X HIL · DASa DAS instance: one queue per acquisition gate, from Service validation to the SRR
Your projectyour name, colours and queues; the same Kafka round trip

Run your own, for your organisation

K9X HIL is open source under the Apache 2.0 licence. Clone it, describe your instance in two files, and start it.

git clone https://github.com/k9aif/k9x-hil && cd k9x-hil
cp instances/das.yaml instances/acme.yaml   # id: acme; name, colours, logo text; projects, applications, queues
cp .env.sample .env.acme                    # your PostgreSQL, Kafka and storage
cat .env.das.example >> .env.acme           # then set HIL_INSTANCE=acme, port, schema, consumer group, secrets
bash ubuntu_instance/build-run.sh all acme  # build the image and start your instance

Built on the K9-AIF framework

K9-AIF (Agentic Integration Framework) is an architecture-first framework for building governed, secure, and enterprise-scale AI applications. Built on OOA/OOD principles and TOGAF-aligned, it brings consistency, governance, and auditability to agentic systems from day one. Every Router, Orchestrator, Squad and Agent in an application built on K9-AIF extends a K9-AIF Architecture Building Block, so governance, human review and auditability are inherited, not hand-built per application.

Security checks that keep pace with new attacks. AI is now used to attack applications that are themselves built with AI: instructions hidden in documents, agents impersonating other agents, poisoned tool results. K9-AIF tracks these attack techniques as they are published, for example in the OWASP Top 10 for LLM Applications, and adds matching checks to the framework's governance pipeline. Solutions built on K9-AIF pick up the new checks with a framework upgrade, without rewriting their own agents. That is why K9X Sentinel was introduced: every day it reads newly published attacks and checks each one against the framework's security capabilities, so gaps are found and closed early.

The K9X ecosystem brings the framework to life with core components, including K9X HIL (this application: the human decisions every K9-AIF workflow can pause for), K9X Sentinel (above) and K9X Satan (an adversarial harness that fires attacks at a pipeline to prove its defences hold).

k9x.ai ↗ K9X HIL: login K9X Sentinel ↗ K9X Satan ↗ Framework source ↗

Scope of this demonstration

  • This is an open public demonstration. The tasks are live: they are sent by the running K9X demonstrations, such as DAS review gates and Continuum promotion reviews, whose documents are synthetic. The demo login is shared; do not enter real or personal information.
  • The demo user is a manager and can act on these tasks. Decisions are real for the demonstrations: approving a DAS review gate here moves that DAS job to its next stage, exactly as a reviewer's approval would.
  • K9X HIL is in Beta: the case-management model and the Kafka round trip are built; integrations such as ticketing are optional and not configured here.