What is an AI System?

An AI system is a deployed piece of software that delegates part of its work to an AI model. Not “an app that happens to call an API”: in an AI system the model’s output decides what happens next — which tool runs, which record changes, which email goes out, whether the loop continues. That delegation is what makes AI systems powerful, and it is also exactly what makes them harder to operate than the software you ran before — more on that in why AI systems are different.

The agent — today’s most common AI System

The AI system you are most likely to run in 2026 is an agent: a program that repeatedly asks a model “what should I do next?”, executes the answer — often by calling a tool over MCP — feeds the result back, and loops until the task is done.

Maybe the loop runs twice; maybe forty times. It runs in your process, with real side effects — emails, refunds, database writes. The vocabulary for what one trip around (and one whole task) is called — runs, steps, turns, actions — has its own page: the anatomy of a run.

But agents are not the only kind

Anything that delegates work to a model is an AI system, and the differences matter operationally — silence overnight is an incident for a nightly pipeline and perfectly normal for a chat assistant. Brutor records the shape as system_kind:

Kind	What it describes	Example
agent (most common)	Autonomous or semi-autonomous goal pursuit — the loop above	A support agent that resolves tickets end to end
assistant	Human-in-the-loop conversational system	An internal copilot in the User Portal
application	A product feature that calls models	Single-shot summarization in your app
integration	Scheduled or event-driven pipeline	Nightly ticket classification
workflow	Orchestrated, deterministic control flow with model steps	A document-processing chain
service	Internal shared AI capability	A company-wide embedding or extraction service

The kind tunes what gets watched and how hard: action-count drift is a headline signal for an agent and meaningless noise for a single-shot application — and a product that alerts on noise gets turned off.

The AI System as the governed unit

Brutor’s design decision is to make this thing — the agent, the assistant, the pipeline — a first-class entity with an owner, an intended use, a lifecycle stage and a risk tier, and to key everything on it: access, credentials, budget, audit trail, contract and health. Think of it as the “application” in your CMDB, rather than the process ID or the API key.

Technically an AI System is a resource group with group_type: "ai_system", so it already composes resources, carries limits and inherits policy. One system may contain several actors — API keys, agent identities, human users — all rolling up to the same ledger and the same verdict.

One system, many actors

An AI System is the work; the humans and agent identities inside it are the actors. A support copilot might be driven by two API keys, one agent identity and a dozen portal users — all executing in the same AI System, all rolling up to the same budget, ledger and health.

Where to go next

The anatomy of a runRuns, steps, turns and actions — the vocabulary that everything else counts in.

Why AI systems are differentNon-determinism, quiet failures, cost as a runtime variable — why the classic ops playbook doesn't transfer.

AI System AssuranceHow Brutor keeps evidence that a deployed AI System is still doing its job.

Your AI System — the journeyBuilding one? Develop, deploy, govern, observe and assure it with Brutor, end to end.