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 · ObserveThe Overview board, Analytics, the system's own Signals, logs and the Inbox — 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

This is not a label — it selects a signal profile. Each of the six kind-scoped assurance signals lands at enforced (counts toward the health verdict), advisory (computed and shown, excluded from the verdict) or not_applicable (not scored; rendered n/a, never as a zero and never as a pass). A seventh signal, review — open critical findings in the Inbox older than the review SLA — is enforced for every kind, because unreviewed findings are a human-process fact, not a property of the system’s shape.

Kind	Relaxed signals
agent, workflow, integration	None — all six enforced
service	liveness (advisory)
application	liveness, behaviour (advisory)
assistant	liveness (n/a), behaviour (advisory)

agent is the default precisely because it is the strictest superset: a system nobody classified is never scored more leniently than one that was. Reliability, cost and conformance are never relaxed by any kind — an erroring, overspending or policy-violating system is unhealthy whatever shape it is.

Pick honestly, and note that you cannot pick your way out of a bad score: every relaxation a kind applies is disclosed on the health response and in the Assurance Report, naming the signal and the reason. How the profiles work.

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?	Its Signals → Cost tab, and its card on the Mission Control Overview — including cost per completed task, not just per request
Where is it in its lifecycle, and who let it through?	Its Lifecycle tab — the stage diagram, the open gate, and every recorded transition with its approver
What exactly is it allowed to do, as of when?	Its hash-pinned contract, on the Contract tab
Is it healthy?	Its worst-of health score
Can you prove all of the above?	Its Assurance Report

In the Admin UI the system has two homes, on purpose. AI Estate → AI Systems → your system opens the assurance side — seven tabs, in the order the journey runs: Lifecycle (the default), Signals, Runs, Trajectory, Drift, Contract and Assurance. Resource Groups → your system opens the resource-group side — General, Usage, Resources, Members, API Keys and Governance — where you bind what it may use and set what it must obey. The pages below say which of the two each step happens on.

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.