Build git-native AI appliances
Your agent is YAML in your repo - reviewed as a pull request, versioned by tag. kdeps ships it with the open-source model as one deployment: cloud, on-prem, edge, or air-gapped.
$ kdeps
kdeps v2.x | agent loop
Model: llama3.2 (llamafile, offline) | /help for commands
> find the failing tests in ./api and suggest a fix
Ran go test ./api/... - 2 failures in handler_test.go.
Both assert 200, but the router now returns 204 for an
empty body. Update the expected status on lines 41 and 58.
> /model claude-sonnet
Switched to claude-sonnet (Anthropic)
>who it's for
kdeps packages the model with the workflow, so the whole thing runs inside your boundary.
Deploy an internal RAG or document-processing agent entirely inside your customer's VPC. No prompts, no documents, no embeddings leave their infrastructure.
on-prem · regulatedShip the model and workflow as a bootable ISO or a single binary. Runs on a disconnected edge box with no external AI dependency and no network at inference time.
edge · offlineTurn a YAML workflow into a production HTTP API and container. No FastAPI, no LangChain wiring, no hand-written Dockerfile - validation, ordering, and response shape are declared.
workflow modeWorking examples, each a runnable project:
git-native
What the appliance does - model, validation, step order, response shape - is defined entirely by the YAML in your repo. Change it, commit, and it behaves differently; your git history is the changelog of the agent's behavior. Only the model binding lives outside the repo, so the same commit runs local on a laptop and cloud in production.
chat:
- model: llama3.2:1b
+ model: qwen2.5:7b
prompt: "{{ get('q') }}"
validations:
check:
+ - len(get('q')) < 2000 # reject prompts over 2k charsOne commit, two behavior changes: a bigger model, and the API now 400s on oversized input. No redeploy config, no console toggle - the diff is the change.
A change to an agent is a diff: a new resource, a tightened validation, a reshaped response. Review it in a pull request like any other code.
A git tag is a release. kdeps validate and kdeps bundle build run against any checkout or tag; the built appliance pins the runtime and the model too.
Point CI at a tag: kdeps validate, kdeps bundle build, push the image. The same commit produces the same appliance every time.
The registry is a convenience for installing and publishing agents by name - kdeps registry install owner/repo pulls from a GitHub repo. You never need it to build or deploy your own.
getting started
Start in the REPL. Write YAML when you want a pipeline. Ship the same file.
kdeps opens the agent REPL. No YAML. No API key. A local model downloads on first use.
Declare resources -- chat, HTTP, Python, SQL. Wire them with requires:. One file, both modes.
kdeps run serves the API. kdeps . loads it as a tool. Export Docker, Kubernetes, ISO, or a binary.
vs doing it yourself
No Python scripts, no wiring, no boilerplate.
| Traditional approach | kdeps |
|---|---|
| Python script + Flask + OpenAI SDK + retry logic | One workflow.yaml file |
| Manual dependency wiring | requires: in YAML |
| Write error handling by hand | onError: block (continue / retry / fail) |
| Write Dockerfile + CI pipeline for deployment | kdeps bundle build --tag then docker push |
| Chaining agents by hand | agent: resource — one agent calls another declaratively |
book
Everything from first agent to production deployment, in one place.
Build & Deploy Autonomous AI Agents and Agencies in YAML
Your AI prototype works. Now ship it. Hands-on guide to deterministic pipelines, multi-agent orchestration, error handling, and vendor-agnostic deployment — the production challenges most AI frameworks leave to you.
Read the book ->