The AI System

You’re building an agent. Or an assistant, a pipeline, an AI-powered feature. In Brutor, that thing you’re building has a name: an AI System — and it is the common denominator that follows your work through the whole platform. Every stage of the journey, from the first chat.completions.create() on your laptop to the assurance report an auditor reads a year later, attaches to the same entity.

This section walks that journey end to end, as a developer would live it:

   DEVELOP            DEPLOY             GOVERN            OBSERVE            ASSURE
      │                  │                  │                  │                  │
 point your code    create the AI      attach guardrails, watch cost, usage  run ledger, drift,
 at the gateway,    System, bind its   policies, budgets  and logs filtered  liveness, contracts,
 add tools, wire    resources, mint    and approvals to   to YOUR system     health & the
 the run header     its credentials    its scope                             assurance report
      │                  │                  │                  │                  │
      └──────────────────┴────────── one AI System ───────────┴──────────────────┘

1 · DevelopPoint your agent at the gateway, add governed tools, skills and knowledge — and send the one header that makes everything later possible.

2 · DeployCreate the AI System entity, bind its resources, mint its credentials, declare its intent, and pass the lifecycle gate.

3 · GovernGuardrails, tool policies, budgets, approvals and agent grants — scoped to your system, composing safely with the org's rules.

4 · ObserveMission Control, usage and cost attribution, logs and alerts — every view filtered to the system you shipped.

5 · AssureWhat did it do, has it changed, is it alive, can you prove it — the run ledger, drift detection, contracts and the assurance report.

What an AI System is, concretely

An AI System is a resource group with group_type: "ai_system". That single design decision is why the journey holds together: a resource group is already the thing Brutor scopes access to (models, MCP servers, skills, knowledge bases, agent cards), attaches controls to (guardrails, policies, budgets, rate limits, approvals), issues credentials for (API keys, agent memberships), and attributes usage to (cost, tokens, audit rows). Making your agent be one means all of that machinery applies to it natively — nothing is bolted on.

A system_kind field records the shape of what you built, because the lifecycle machinery treats different shapes differently (silence detection is critical for a pipeline and wrong for a chat assistant):

system_kind	What it describes
agent (default)	Autonomous or semi-autonomous goal pursuit — the most common case
assistant	Human-in-the-loop conversational system
application	A product feature that calls models
integration	Scheduled or event-driven pipeline
workflow	Orchestrated, deterministic control flow
service	Internal shared AI capability

Because the AI System is one entity, every question about your agent has one place to look:

Question	Where the answer lives
What may it use?	The system’s resource bindings and effective view
What must it obey?	The guardrails, policies and limits resolved for its group
Who or what is acting as it?	Its API keys and agent identities
What does it cost?	Mission Control filtered to the system — including cost per completed task, not just per request
What exactly is it allowed to do, as of when?	Its hash-pinned contract
Is it healthy?	Its worst-of health score
Can you prove all of the above?	Its Assurance Report

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 human users in the portal — all executing in the same AI System, all rolling up to the same budget, ledger and health.

The worked example

The five stage pages build one concrete system so you can follow real commands end to end: support-copilot — an agent (system_kind: "agent") that answers customer questions, looks up orders through a CRM MCP server, runs a refund skill that requires human approval, and delegates billing verification to a peer agent over A2A. Swap the names for your own; the mechanics are identical.

Before you start

The journey assumes a running gateway. If you don’t have one yet:

1. Run the platform with Docker Compose — about ten minutes.

2. Make your first governed LLM call — two minutes, and confirms your credentials and base URL work.

3. Come back here and start with Develop.