Overview

Three layers, one installation

An installation is three things, not one: a Kubernetes cluster, the services deployed into it, and the application your people work in. Keeping the three apart is what makes it clear which part answers for what.

The cluster

One Kubernetes cluster on Talos, inside one cloud project that you own. That project is the isolation boundary — access, billing and the limit of any blast radius all end where it ends. Everything needed to rebuild the cluster from nothing is held as code, so an installation is reproduced rather than reassembled by hand.

The services

Ready third-party components, deployed as they are. Underneath: storage, queue, ingress, certificates. Above them, the services your work actually passes through — the model gateway that every call to a model goes through, and the automation runtime that carries out scheduled and triggered work. Teagsoft integrates these services and answers for their behaviour at the boundary. It does not rewrite them.

The application

The code Teagsoft writes, and the only part of an installation there is exactly one of. It is where an employee creates an agent, edits that agent’s instruction as a file, connects capabilities the administrator has published to the catalogue, binds the agent to a channel, and where approvals, access and spend are settled. Everything a person sees is here; the services sit behind it.

What the platform does not do

These limits are structural. They follow from the installation running inside your perimeter and not ours.

We do not host it. There is no copy of your data on our side, and no support path that starts with us logging into your cluster. Your administrator holds the credentials, and the model provider key is yours from the first day.

There is no telemetry back-channel. The installation does not report to us — not usage, not health, not errors. The licence is a signed file, verified locally; renewal is a string your administrator pastes in, and it never requires opening a port outward. The same fact cuts the other way: we cannot see into a running installation, so diagnosis depends on what your side can read and send us.

Nothing is counted. There is no run counter, no trace volume, no per-seat meter, and no numeric limit on agents or users. An edition is defined by what was delivered and what the licence declares, not by a meter reading. We publish no uptime figure for your cluster either — it is not ours to observe.

Where to go next

• Agents — what an agent is, the instruction file behind it, the two agent levels, and how work runs when no person is present.
• Catalogue — what an administrator publishes (MCP servers, integrations, skills, channels) and what an author may connect without asking.
• Approvals and audit — which actions wait for a human decision, who may take it, and what the record holds afterwards.
• Editions — how an edition, an industry pack and an option compose, and how the licence file is checked on your own hardware.