Applied AI · Self-hosted
AI that joins
the team.
KNURZ builds AI products for real work: agent teams that take a task to a reviewed pull request, a meeting participant that remembers what was actually said, and speech that runs on your own terms. One platform — and every piece works on its own.
The products
One platform. Three products.
Each one is a product on its own. Together they close the loop from a sentence in a meeting to delivered software.
Agent teams that ship.
- Teams, models and delegation managed in a UI — one desired state, materialised on Docker or Kubernetes
- A task becomes plan, code, tests and a pull request — the merge stays human
- Or give a seat a mailbox: what arrives is sorted, answered as a draft, and filed
- Every run shows its cost, reasoning and tool steps
The participant that remembers.
- Answers when addressed — in the room, in a direct chat, or in Teams
- Keeps commitments and open points with the verbatim quote as evidence
- Draws diagrams, code and live previews onto the shared screen while you talk
Voice, on your terms.
- OpenAI-compatible speech endpoint with custom voices
- Audio streams while it is being generated — no waiting for the file
- Whisper transcription with live results; keys never leave the server
One connected loop
From a sentence in a meeting to a merged pull request.
- 01
Talk
meetingDecisions and commitments are captured as they are spoken — with the original quote attached, across the whole meeting series.
- 02
Frame
youAn open point becomes a work item: title, acceptance criteria, repository. A person decides what is worth building.
- 03
Ship
agentdThe lead plans and delegates; specialists write the code, run the project’s own tests and open the pull request.
- 04
Merge
youReview and merge stay with people. The pull request is the gate — not a formality.
No lock-in between the pieces: run meeting without agentd, agentd without meeting, and speech under anything that talks the OpenAI audio API.
Another way in
Some work arrives as email.
A ticket is one way to start work; an inbox is the other, and it is the one nobody manages. An agentd seat can be given a mailbox: it reads what comes in, sorts it into the classes you describe, answers as a draft a person releases, and files the documents into the system you already run.
Answers that wait for you
Replies land in the mailbox as drafts by default and leave on their own only where you said so — always to the sender of the mail being answered, never to an address the message asked it to write to. Senders outside your list never reach a model at all.
Documents end up where they belong
An attachment is identified by its content rather than its name, and is filed through your existing API under a record the seat looked up itself. What it cannot place with certainty, it holds — a mail waiting for a person is visible, a wrongly filed document is not.
The same agent, the same evidence, a different door — see how the mail door works.
The platform underneath
Built like infrastructure, not like a demo.
A control plane, not config files
Agents and teams are created and changed in the cockpit. One versioned desired state drives Docker locally and Kubernetes in production — the same contract on both, one agent per container.
Identity is automatic
Every agent gets its own OIDC client, created and removed with the agent. On Kubernetes there are no durable agent secrets at all — short-lived, rotating service-account tokens do the proving.
Delivered by GitOps
Push, tests, image, deployment — on our own Git and Argo CD. What the cockpit shows is what is actually running, down to the version number.
Honest by measurement
Cost per run, evals in the repository, limits written down. When a setup loses to a simpler one, the numbers say so — and the simpler one stays.