Practical example
A service agent — from request to approved action
An AI agent is meant to analyse incoming service cases, retrieve information from several systems, draft a recommended course of action and — after human approval — trigger defined actions.
What it’s about
The example is deliberately industry-neutral and contains no confidential or fabricated customer data. It serves as a common thread along which the architecture questions of the seven missions can be played through concretely.
For newcomers it shows, step by step, what you have to think about with an AI system that acts — from “Who is responsible?” to “How do I stop it in an emergency?”.
For architects, developers and decision-makers, each step highlights the concrete architectural decisions that make the system reliable, traceable and bounded.
This example is deliberately didactic. To see how the same principles play out in a real, governance-led system with a demonstrator, look at the practice reference “AI-Operable IT-Services”.
Step 001 · Mission 001: Target picture & operating model
Who is accountable for the service agent, what goal does it pursue — and which decisions is it allowed to make?
- A named owner is accountable for operation, approval and shutdown; the initiative is listed in the AI inventory.
- Goal and benefit are defined in measurable terms (e.g. faster, more traceable case handling) — not “more AI”.
- A clear boundary: the agent may propose and prepare, but may only trigger defined actions after human approval.
- A risk class determines which obligations (approvals, logging) apply to precisely this case.
Step 002 · Mission 002: Data becomes context
Which data sources may the agent use, how up to date are they — and where does a piece of information come from?
- Only approved sources (knowledge base, case history, master data) — no unfiltered access to everything.
- The permissions of the human handling the case are carried over to the context access, not bypassed.
- Every piece of information drawn upon can be traced back to its source (provenance), so the recommendation is verifiable.
- Outdated or blocked content is flagged or excluded from the index.
Step 003 · Mission 003: APIs become tools
Which systems does the agent call — and which calls are read-only, which are write operations?
- Read tools (retrieve case, search knowledge) are clearly separated from write tools (trigger action).
- Write actions have a dry run and are idempotent — a repeated call does no double damage.
- Errors, timeouts and retries are defined in the tool contract; multi-step flows have compensation logic.
- All calls run through a controlled gateway and are logged in an auditable way.
Step 004 · Mission 004: Identity, security & governance
Under which identity does the agent act, which rights does it have — and where is an approval mandatory?
- The agent has its own machine identity (no shared collective account) with minimal rights.
- Access is short-lived (time-limited tokens) and separated into reading, proposing and executing.
- The triggering action requires explicit human approval (human-in-the-loop).
- A kill switch halts the agent's activity immediately in an emergency — tested, not just documented.
Step 005 · Mission 005: Evals, reliability & observability
How is answer quality tested, how are tool calls logged — and when is a case escalated?
- Golden datasets with typical service cases test the recommendation quality continuously (continuous evals).
- Tracing reaches down to the individual tool call, not just to the model call.
- Quality SLOs and monitored failure patterns trigger defined responses when violated.
- Uncertain or risky cases escalate automatically to a human; incidents can be reconstructed via replay.
Step 006 · Mission 006: Portability, sovereignty & economics
Which provider dependencies exist, what does one transaction cost — and which data leaves the house?
- The model provider can be swapped via a model gateway, without rebuilding the application.
- Costs are measured per case handled (business outcome), not just per token.
- It is a deliberate decision which data may reach external services and which stays in-house.
- Your own evaluation data enables a before-and-after comparison when switching provider.
Step 007 · Mission 007: AI-native software engineering & platform
How is the agent developed, tested and versioned — and how secure is its supply chain?
- Prompts, tool definitions and model versions are versioned and go through reviews and approvals.
- Generated code passes through the same quality gates as hand-written code.
- The provenance of code, models and data is traceable (provenance / AI-SBOM).
- Architecture rules are stored as executable fitness functions, not just as a document.
Apply this example to your own case?
Nova-7 links the scenario to the matching missions and primary sources.