Self-Host Production AI Agents: 20 You Can Buy and Run

Most of what gets sold as an "AI agent" in 2026 is a prompt in a trench coat. You buy a template, open it, and find a markdown file with a clever system prompt and a promise that it will review your code or chase your invoices "in minutes." It works in the demo. Then you point it at something real, it wanders off the task, calls a tool you did not expect, and produces output nobody checked before it landed in your repo or your inbox. The prompt was never the hard part. The hard part is everything around the prompt.

We built a store for the everything-around-the-prompt. It lives at clskillshub.com/agents, and it holds 20 deployable AI agents you download and run on your own machine. Each one is an engineered system, not a text file: a typed goal contract, a LangGraph state machine, a validated tool executor with a security policy, an evaluation gate that self-checks the output, and a human approval step for anything that writes or sends. You bring your own API key, nothing phones home, and you own the code. This post explains what that architecture actually is, why it matters, and where the honest limits are.

What separates an agent from a prompt

A prompt is an instruction. An agent is a bounded process that pursues a goal, decides which steps to take, uses tools, and checks its own work before it returns. The difference is not the model. Both use the same LLM. The difference is the structure the model runs inside.

When you give a raw model a task and a set of tools, you are trusting a probabilistic text generator to plan correctly, call only safe tools, stop at the right moment, and never hallucinate a result. That trust is misplaced, not because the models are bad, but because a single forward pass has no memory of a plan, no gate on its actions, and no test for whether it succeeded. A template that hands the model your shell and hopes for the best is not an agent. It is a liability with good marketing.

Our packages replace hope with structure. Every agent moves through the same spine: a goal contract defines what success means, a planner proposes steps, a state machine executes them one at a time and can resume if interrupted, a validated executor decides whether each proposed tool call is allowed to run, an evaluation gate checks the output against the contract before returning it, and a human approves anything that changes the outside world. Each stage is inspectable. When something goes wrong you can see exactly which stage it went wrong in, which is the entire point.

Browse the 20 agents if you want to see the range before reading further. The rest of this post is about how they are built.

The architecture, stage by stage

The goal contract (agent.yaml)

Every package starts with an agent.yaml file that is not a prompt. It is a contract. It declares a typed input schema, a typed output schema, and a machine-checked success test. The success test is code, not vibes. When the Invoice Chaser agent claims it finished, the contract runs an assertion against its output and either passes or fails it. This is what lets the agent grade itself instead of asking you to eyeball whether it did the job.

Typed I/O also means the agent refuses malformed input at the door rather than improvising around it. If a field is missing or the wrong shape, you get an error at the boundary, not a confidently wrong result three steps later.

The planner and the LangGraph state machine

The model plans, but it plans into a state machine, not into thin air. We use LangGraph because production agents need explicit state, branching, retries, and the ability to pause and resume. A long task is not one giant model call. It is a graph of small steps, each with its own state, each recoverable. If step four fails, you do not restart from step one. If the process is interrupted, it resumes where it stopped.

This is the difference between a script that either completes or crashes and a pipeline you can actually operate. LangGraph production agents are auditable by construction because every transition is a discrete, logged node. When people say "agents, not assistants," this is the technical substance behind the slogan: an assistant answers, an agent runs a resumable, inspectable process toward a defined end state.

The validated tool executor and the security boundary

This is the part that matters most and the part almost every template skips. The model in our agents never touches your system directly. It cannot. What it can do is propose a tool call. That proposal goes to a policy layer that checks it against a tool allowlist, redacts secrets, and enforces resource limits. Only after the policy validates the call does the call actually run. The model proposes, the policy validates, then the system executes. Propose, validate, execute, in that order, always.

That boundary is why prompt injection does not automatically become remote code execution here. Prompt injection is now a documented, ranked risk in the OWASP Agentic Security ASI Top 10, and the reason it is dangerous in most setups is that a poisoned instruction flows straight from the model into a live tool call. In our architecture a malicious instruction can convince the model to propose something harmful, but the proposal still has to survive the allowlist and the policy. The model persuading itself to do damage is not enough. The policy layer, which does not read your untrusted content and cannot be talked out of its rules, gets the final say on every action.

Every package ships its own SECURITY.md and a policies/ directory so you can read exactly which tools the agent may call and exactly what it is forbidden to touch, before you run it once. No guessing, no reverse engineering.

The evaluation gate

Before an agent returns anything, it runs its output back through the success test in the contract. If the output fails, the agent does not hand you a broken result and move on. It knows it failed. Depending on the package it retries, narrows scope, or returns an honest failure you can act on. This self-check is why these agents shrink a task to a bounded, checkable pipeline instead of an open-ended chat you have to babysit.

Human-in-the-loop approval

Read-only work runs on its own. Anything that writes a file, sends a message, commits code, or changes state outside the sandbox stops and asks you first. Human-in-the-loop is not a toggle we bolted on. It is a required node in the graph for any write or send action. You stay the decision-maker on consequences. The agent does the labor and the checking, you approve the irreversible parts. This is deliberate, and it is the opposite of "set and forget," which we do not sell and you should not trust.

Why two languages, and why bring your own key

Python and TypeScript from the same contract

Every package ships reference implementations in both Python and TypeScript, generated from the same agent.yaml contract. If your stack is a FastAPI backend, the Python version drops in. If you are running a Node service or a Next.js app, the TypeScript version is native. You are not translating anyone's Python into your TypeScript by hand and hoping the behavior matches. Both implementations honor the same typed contract and the same policies, so they behave the same way. Pick the one that fits your codebase and delete the other.

Model-agnostic, bring your own key, nothing phones home

The agents are model-agnostic. They run against Anthropic, OpenAI, Google, or a local model, and you supply your own API key. There is no clskillshub account in the loop at runtime, no metered middleman, no telemetry. The code runs entirely on your machine and talks only to the model provider you configure.

This is the commercial heart of it. The market is full of agent SaaS products that charge you monthly, keep your workflow on their servers, and lock you to their model choice and their pricing. When you buy one of these packages you get the source, you host it yourself, and you own it. If model prices shift, you switch providers by changing a config value. If a better local model ships next quarter, you point the agent at it. Nothing about your ability to run the agent depends on us still being here or our bill still being paid. You bought code, and the code is yours.

Model Context Protocol is relevant here too. MCP has become the de-facto standard for connecting agents to tools and data, now donated to the Agentic AI Foundation under the Linux Foundation. An architecture built on typed contracts and a validated tool executor is exactly the shape that plays well with a standardized tool layer, rather than a pile of bespoke prompt hacks that break the moment the interface changes.

See the Code Reviewer agent if you want a concrete example of the contract, policies, and dual implementation in one package.

What is in the store

The 20 agents split into two groups. The developer agents are Code Reviewer, Test Writer, Debugger, Refactorer, Security Auditor, Agent Team Coordinator, and Docs Writer. The operator agents are Contract Reviewer, Invoice Chaser, Bookkeeping Close Prep, Lead Triage Assistant, Hiring Screener, Content Repurposer, Brand Voice Guardian, Meeting Notes Actioner, Report Builder, Realtor Listing Writer, Email Inbox Triage, Competitive Intel Analyst, and Deep Research Analyst.

Pricing is tiered by complexity: 29 dollars for Essential, 49 dollars for Professional, 79 dollars for Advanced. Buy one, or add several to the cart and get them as a single combined ZIP. Every package ships the same complete structure: agent.yaml, a policies/ directory, python/ and typescript/ implementations, a docs/ folder with ARCHITECTURE, CONFIGURATION, SECURITY, and EXTENDING guides, an examples/ folder with a runnable sample and its exact recorded output, plus README, LICENSE, and CHANGELOG. The recorded example output matters: you can run the sample and compare against the exact output we shipped, so you know the package works before you wire it into anything of yours.

The honest limits

An LLM is one component. The contract, state machine, evaluation gate, and security policy are what make the whole thing reliable, and even then reliable does not mean infallible. These agents shrink your work to a bounded, auditable, resumable pipeline. They do not remove your judgment, and they are not autonomous employees.

The Contract Reviewer flags risky clauses and structures its findings. It does not replace your lawyer. The Security Auditor surfaces issues and explains them. It does not make your codebase secure by running once. The Bookkeeping Close Prep organizes and checks. It does not sign off on your books. The value is that each one turns a fuzzy, open-ended task into a defined process with a checkable result and an approval gate on anything consequential. That is a large improvement over a chat window, and it is honestly smaller than "fire your team." Anyone selling you the second thing is selling the prompt in the trench coat again.

If that tradeoff is the one you want, real leverage with your judgment still in the loop, browse the full store at clskillshub.com/agents. Read the SECURITY.md before you run anything. That is exactly the habit these agents are built to reward.