Build AI Agents on a Canvas.
Run Them Where You Point.

TheYgent is a no-code, local-first platform for building and running AI agents on a visual canvas. You drag nodes — LLMs, MCP tools, routers, RAG retrieval, guardrails, human approvals — wire them with edges, and run the graph as an agent. Inference runs on your own machine via llama.cpp, MLX, or vLLM, or on any OpenAI-compatible API you register, chosen per agent and per call.

TheYgent is source-available under a fair-code license (the Sustainable Use License), not an OSI-approved open-source license. The full source is on GitHub, and you are free to use, modify, and self-host it for internal business, personal, and non-commercial purposes. Selling it — including offering it as a hosted service — is not permitted.

Most visual AI workflow builders call a model server you install and run separately. TheYgent runs local models on its own engines, sends no telemetry, and can make every run crash-resumable. The comparison pages set it side by side with four popular builders, with sources and dates — including where each of them is the better pick.

TheYgent never routes your prompts, payloads, or model weights through anyone else’s servers — you own every hop. By default everything runs on your machine: local engines, your own Postgres, localhost interfaces. If you register a hosted API for a model, that traffic goes directly from your machine to the provider you chose — it crosses the wire only because you sent it there.

Three local engines plus a universal escape hatch: llama.cpp (runs on any machine, CPU or GPU), MLX (Apple Silicon), and vLLM (NVIDIA GPUs) — plus any OpenAI-compatible API you register. Models get a logical ID, so you can swap the engine underneath without touching the agent graph, and one graph can mix local and hosted models side by side.

No. TheYgent runs local models on its own engines — llama.cpp, MLX, and vLLM (experimental). Install a model from the in-app Hugging Face catalog, where every variant shows whether it fits your RAM, and the inference plane starts the engine on the first call, keeps it warm, and unloads it when idle. There is no separate model server to install or keep running.

Yes, once it is installed. With models installed from the catalog, or weights copied onto the host and registered by path, the canvas, the engines, Postgres, durable runs, and retrieval with a local embedding model all work with no network. The only automatic request — a public price list fetched at startup — falls back to a bundled copy when offline. Every network touchpoint is listed on the private and offline AI page.

No. TheYgent has no usage analytics, crash reporting, update checks, or license activation, and it needs no vendor account. Traces stay in your own Postgres; OpenTelemetry export is off until you point it at a collector you run.

Yes. TheYgent connects to any MCP server over stdio or HTTP, and you can browse and install servers from the MCP registry inside the app. MCP tools drop onto the canvas as nodes, so a local model can call the same tools a hosted assistant would — running in your own trust domain.

No. The canvas is the whole workflow: drag nodes from the palette, connect them, configure each one in the inspector, and run. Publishing an agent mints an immutable, content-addressed version you can invoke by API, roll back, or wire to a trigger — all without writing code.

Yes. A published agent can sit behind a token-authenticated endpoint, an HMAC-signed webhook, or a cron schedule. Runs can be durable: every step is checkpointed, so if the process dies mid-run it resumes from the last completed node — loops, subgraphs, and human-approval waits included.

Yes. Drop a human approval node into the graph and the run pauses there until someone approves or rejects it, from the interface or over the API. Approvals run on the durable runtime, so a run can wait minutes or days and still pick up where it left off after a restart.

Clone the repo, copy .env.example to .env, and run make up for bare metal, or deploy the same services with Docker Compose or Kubernetes — it’s one architecture in every topology. There’s no vendor account and no cloud dependency — the only account is the local admin you create in the first-run wizard; the stack listens on localhost by default and stores everything in your own Postgres.

Yes. Crawl a site or upload documents, embed them locally into pgvector in your own Postgres, and wire a retrieval node into any graph. Embedding and retrieval both run through engines you choose — keep the embedding model local and your documents never leave your machine; bind a hosted API and they go only where you pointed them.

Yes — engine choice is per node, not per app. A common pattern is a fast local model handling triage on-device while a larger hosted model, reached through an API you registered, takes the escalations. Because nodes reference logical model IDs, swapping any binding later doesn’t touch a single edge.

The AI Gateway is a TheYgent service you run between Claude Code and the Anthropic API to cut what Claude Code costs. In observer mode it records every exchange — its cost, its kind of request, and what routing would have saved — without changing it. In router mode it moves work where that is a drop-in: subagents and cold-cache turns to a cheaper Claude model, and a share you choose to models on your own inference plane, each measured on your own traffic first.

Yes — it relays them, so it runs where you run it: your machine or your cluster, in the same trust domain as Claude Code. It never writes a prompt or a response anywhere. What it sends to the control plane is metadata only: timings, model names, token counts, costs, and the reasons behind each routing decision — never prompt or response text.