What is Tiny Systems?

Tiny Systems is a self-hosted AI agent runtime for Kubernetes. Describe an agent in your editor, and it runs as real workloads on your own cluster — your keys, your data, no SaaS in the path.

An agent here is not a Python script or a hosted API call. It's a set of Kubernetes resources that an operator reconciles and keeps running: an HTTP endpoint, an LLM call, a Slack notifier, a memory store, wired together. You build it by prompting; you can kubectl get tinynodes and watch it run.

How it works

You (Claude Code / Cursor / any MCP client)
  │
  │  "An agent that alerts Slack when a pod crashes"
  │
  ▼
MCP endpoint (hosted at mcp.tinysystems.io, or local via the tiny CLI)
  │
  │  Creates TinyNode / TinyFlow CRDs in your cluster
  │
  ▼
Your Kubernetes Cluster
  │
  │  Module operators reconcile the CRDs and run the agent
  │
  ▼
Running agent (watches pods, calls the LLM, sends Slack messages)
  1. You describe the agent in natural language.
  2. The MCP endpoint translates that into TinyNode custom resources.
  3. Module operators (installed via Helm) reconcile those resources and run each component.
  4. Data moves between components through typed ports with expression-based mapping.

Under the hood an agent is a flow: connected components passing typed messages. The flow is the mechanism; the agent is what you build with it.

Key concepts

ConceptWhat it is
AgentWhat you describe and run — a working flow of components on your cluster
ComponentA reusable building block with typed input/output ports (e.g. http_server, slack_send, pod_watch)
ModuleA Helm-installable operator that ships one or more components
FlowThe connected graph of components that makes up an agent
TinyNodeA Kubernetes CRD representing one component instance with its configuration
EdgeA connection between ports with {{$.path}} expression-based data mapping

What makes it different

  • Prompt-built — you describe an agent in your editor; the primary interface is natural language over MCP, not a drag-and-drop canvas (the canvas is there to watch and inspect what you didn't hand-write).
  • Real workloads — not a wrapper or an abstraction layer. kubectl get tinynodes shows your agent running.
  • Self-hosted — runs on YOUR cluster. No SaaS dependency, no data leaving your infrastructure.
  • Durable — trigger-driven agents record every step and survive pod restarts (see Execution model).
  • Open source modules — all modules are open source. Build your own with the Go SDK
  • Production-grade — leader election, metadata persistence, graceful shutdown, exponential backoff

Use cases

  • Alerting — watch pods, TLS certs, deployments and send Slack/email notifications
  • Automation — scale clusters on schedule, mirror images, sync config
  • API integration — connect REST APIs with data transformation
  • Event processing — handle webhooks and trigger multi-step workflows
  • Data pipelines — ETL with error handling and conditional routing

Architecture

Tiny Systems has three parts:

PartDescription
MCP ServerLocal binary (brew install tiny-systems/tap/tiny) that exposes flow-building tools to AI clients
SDKGo framework for building custom modules and components
ModulesPackaged operators deployed via Helm — each ships one or more components

There is also a browser flow editortiny serves it locally at http://localhost:7775 — for inspecting and fine-tuning flows, and a hosted platform for team collaboration. But the MCP server is the primary entry point.

Next steps