Lessons 32.1 and 32.2 mapped the rented building: fast, convenient, bounded by someone else's rules. Now we tour the building you own.

What "self-hosted" actually means

A self-hosted (or custom) agent is one where your application owns the agent logic, model routing, tools, state, queue and schedule, logs, approval flow, and interface. You decide which model to call, which tools exist, what state persists, when the agent runs, what gets logged, which actions need a human, and what the user sees.

One clarification: "self-hosted" does not mean you train your own model. The model calls themselves can still go to hosted model APIs — OpenAI, Anthropic, Google, or any provider you route through. What you host is everything around the model: the loop, the tools, the memory, the schedule, the gates. The reasoning engine is rented; the system is yours.

That distinction is the whole lesson in one sentence. Hosted chat agents rent both the engine and the building. Self-hosted agents rent the engine and own the building.

The humble Python worker

The most common first self-hosted agent is a small Python worker: a script or service that takes a job, calls a model API, uses tools over HTTP, reads and writes files or a database, updates a queue, and logs what it did.

Python earns this role honestly. Model and provider SDKs support it well, HTTP libraries are mature, database drivers exist for everything, file and queue handling is straightforward, and the research and data tooling around it is rich. It is a friendly starting point for research, data, and automation workflows.

It is not the only option. TypeScript and Go — and other languages — build excellent agents, especially where the agent lives inside an existing web service written in that stack. Choose the language your team can read, test, and operate. The agent pattern (goal, tools, state, loop, gates) does not change with the language.

LLM-written code is still production code

Here is the honest boundary, and it matters more than any framework choice: an LLM can write much of your agent's code, but generated code is still production code. The moment your worker can publish, spend, delete, or change a production system, everything it does carries production consequences — regardless of who typed it.

That means four non-negotiable habits:

1. Test with safe data. Run the worker against fixtures, copies, or staging systems before it ever touches real records. A collector that deletes instead of drafts should fail in a sandbox, not in production. 2. Read its permissions. Every API key, database role, file path, and deployment token the worker holds is a permission you granted. List them. Remove the ones the job does not need. 3. Keep secrets out of source. API keys and credentials live in environment variables or a secret store, never in committed files. If a key appears in a diff, rotate it. 4. Review consequential actions. Anything that can publish, spend, delete, contact a customer, or alter production passes through a check you designed — a validation step, a staging hold, or a human approval gate from Class 31.

Skipping these because "the AI wrote it and it looks right" is how small agents cause large incidents.

Where it runs

• Serverless for short, bounded tasks: a function wakes on an event, does one job, and exits. Good for classifiers, formatters, single-step enrichments. Bad for long loops or persistent state.
• VPS, Docker, or a small persistent machine for workers and control planes that must stay up: schedulers, queues, collectors that run for hours, anything with local state or a listening port. This is the path you learned in Part VII — you operate it like any other service, with deploys, logs, and monitoring.
• A queue in front of long runs so work survives restarts: jobs wait their turn, workers claim them one at a time, failures retry with backoff, and nothing is lost when a machine reboots.

Match the runtime to the job's shape. Short and stateless goes serverless. Persistent, scheduled, or long-running gets a real machine plus a queue.

The price of control

More control means more of everything: more engineering (you write and test the loop), more operations (deploys, uptime, backups), more security (secrets, permissions, network rules), more monitoring (logs, alerts, run histories), and more testing (fixtures, staging, regression checks).

That is not an argument against self-hosting. It is the budget line. A hosted agent costs a subscription and your time. A self-hosted agent costs engineering attention indefinitely. Choose it when the workflow earns that attention — when it must run on a schedule, touch private systems, enforce custom gates, or persist state you control.

Practical exercise: the five-column comparison

Pick one workflow you care about — the competitor summary from Lesson 32.1 works well. Score hosted versus self-hosted across five columns:

One honest phrase per cell. Then write your decision in two sentences: which option you choose for this workflow, and which single column decided it.

Finish line: a completed five-column table plus a two-sentence decision naming the deciding column.

Verify it: re-read your "data boundary" cells. If either one says something you have not confirmed — a platform's data terms, a database's access rules — mark it "unverified" and note where you would check.

Common failure mode: scoring "speed" as the only column that matters and declaring hosted the winner for a workflow that must run nightly for a year. Speed to first result and cost over a year are different columns. Score all five.

Check your understanding

1. What does a self-hosted agent owner control that a hosted user does not? Name at least four items. 2. Why can model calls stay hosted while the agent counts as self-hosted? 3. An LLM generates your worker's publishing step and it looks correct. What four habits apply before it touches production?

Next, the case study: a real editorial system built exactly this way — bounded, scheduled, validated, and gated — so you can see every part working together.