SeoWeb
  • Work
  • Services
  • CV
  • Contact
    • AI
  1. Home/
  2. AI Handbook/
  3. Fundamentals/
  4. Anatomy of an AI-automated system

[ Fundamentals ]

Anatomy of an AI-automated system

Target audience: everyone | Prerequisites: 1.4 Where AI automation already works: use cases

What you'll learn

After this document you will be able to:

  • name the seven parts of an AI-automated system and explain each one's job;
  • read a system diagram and see where the steps of a concrete workflow take place;
  • distinguish the three shapes of a system — a single prompt, a workflow, and an agent-based system — and judge which one your task needs;
  • map an ordinary use case onto the anatomy diagram.

In plain terms

An AI-automated system is like a cook in a kitchen. An order comes in — that is the trigger. The recipe says what to do and how — that is the instruction. The cook cooks — that is the AI model. Before plating, someone tastes the dish — that is the checkpoint. Only then does the plate go to the customer — that is the output. The register keeps what was ordered and what was served — that is data storage. No single part feeds the guest alone; the result is born from the whole line working together.

From document 1.1 we know that the model's part is only one step — all the surrounding work (fetching data, checking, sending) is ordinary, reliable software. This document takes that thought apart and puts the whole system on one picture — before we start building the parts one by one.

The seven parts of the system

Every AI-automated system — whether a simple email flow or a company's large processing line — consists of the same seven parts:

  1. The trigger — the event that brings the system to life: a customer sends an email, someone fills in a web form, the clock strikes eight every morning. Without a trigger the system is a sleeping machine.
  2. Input data — the text to be processed and the data from your systems to draw in. From document 1.1 we know: the model does not look up facts — if the purchase date is not supplied, it will guess it (that is a hallucination — an answer the model states confidently but that is false). Everything together must fit into the context window (the amount of text the model can see at once). Poorly formatted or incomplete input is a frequent cause of failure — data preparation is covered in document 2.4.
  3. The instruction, or prompt (the instruction given to the model) — the rules, role, and output format the model works by. How to write a good prompt was taught by 1.3; what matters for the system is that the instruction is a separate, maintainable, and changeable part — not just in someone's head.
  4. The AI model — the only place in the flow where randomness is at work: the model classifies the letter, extracts data, composes the draft. It is capable but without guarantees — which is why it is never left alone to reach the output.
  5. The checkpoint — the place where the result is checked before the outside world: either a human-in-the-loop (a human reviews the result before it is used and approves it) or an automated rule (“does the answer contain the invoice number, and does it exist in the data?”).
  6. Action / output — the moment the system touches the outside world: the reply goes to the customer, the data is entered into a table, a notification is sent. An error at this step is the most expensive — that is why a checkpoint always precedes it.
  7. Data storage — where the result and the history persist: sent replies, decisions made, the course of processing. Without the history you can neither see what happened in the system nor investigate errors later.

The whole diagram in one picture — read it top to bottom, like a recipe:

   1. TRIGGER
      new email · form submission · schedule
                │
                ▼
   2. INPUT DATA
      customer letter + data from your systems
                │
                ▼
   3. INSTRUCTION (prompt)
      rules · role · output format
                │
                ▼
   4. AI MODEL
      classifies · extracts data · drafts the reply
                │
                ▼
   5. CHECKPOINT
      human-in-the-loop or automated rule
      ← doubtful cases (classification or check) return to a human
                │
                ▼
   6. ACTION / OUTPUT
      reply to the customer · data entry
                │
                ▼
   7. DATA STORAGE
      result and history are kept

In plain terms: the model is the only part that guesses — the six other parts are software doing solid work. That is why the quality of the system is a bigger question than the quality of the model: a good model in a bad system gives a bad result, and vice versa. For a new idea, walk through all seven parts: where the flow comes from, what data goes along, what the instruction is, who checks, where the result goes, and where the history is kept.

Two technical topics stay short here: how to assemble these parts programmatically is explained by the API (a programmatic interface for calling the model from code) — see 3.1 API integrations; what happens when one part fails — see 3.4 Errors and error handling.

Three shapes: a single prompt, a workflow, an agent

The same anatomy can come to life in three forms — the larger the form, the more parts are built into the system:

a) A single prompt. The human does everything else: opens a tool with the model, pastes the text, reads the answer through, and copies it where it is needed. Of the seven parts the machine does only the instruction and the model — trigger, input data, checking, and storage remain on the human's shoulders. Enough when the task comes up a few times a day.

b) A workflow (a sequence of automated steps). The steps are written in advance and the trigger sets them running on its own: an email arrives, the system classifies it, pulls the data, composes the draft, routes it to a human for approval. Conditions decide which path the system takes (“if the letter cannot be classified confidently, go straight to a human”). All seven parts are visible and precisely defined — this is the main topic of Level 2.

c) An agent-based system. The work is driven by an AI agent — the model decides for itself what the next step is (covered by 4.1 Agent systems: what they are and when you need them) — but keep the ground rule in mind: the simpler solution is often better, and the agent is usually the last choice, not the first.

ShapeSuits whenExample
Single promptthe task comes up a few times a day and the human does the remaining steps themselveswriting a sales letter draft in a tool window
Workflowthe steps are always the same, the volume is high, and the checkpoint is definedprocessing return requests in an online store
Agent-based systemthe path cannot be written in advance — and the simpler shape has already been tried and was not enoughan exploratory task where the next step depends on what the previous one found

In plain terms: always move from the simpler shape toward the more complex. If the human does everything but the writing, a single prompt is enough; if the work repeats by the hour, build a workflow; an agent only comes into play where the steps themselves don't follow a fixed path.

A step-by-step example: the anatomy of the return-request flow

Let's take the return-request flow we saw in the previous document and look at what actually runs underneath it. 1.4 showed four steps — now the same steps in the language of anatomy:

Step / element from 1.4Part of the anatomyWhat actually happens there
the customer writes: “I would like to send product X back — it didn't fit.”1. triggera new email brings the system to life
(the letter's content)2. input datathe letter's text + purchase data from the system: date, amount
(always present in the background)3. instructionthe rules: “return window 14 days, cost 5 euros, money back within 3 business days”
AI classifies the letter and drafts the reply4. AI modeltwo jobs in a row: classification and writing the draft
the support agent checks and approves5. checkpointhuman-in-the-loop: the system shows the purchase date and rule-compliance status; angry cases the human takes over
the reply goes to the customer with one click6. action / outputthe letter reaches the customer — from here on, no one checks anymore
(always in the background)7. data storagethe returns register: what was decided, when, and by whom

Two details the diagram shows especially well:

  • The fallback is not an exception but part of the diagram. When a letter cannot be classified confidently, the flow turns straight to a human — as 1.4 already said, this is a normal path, not a failure. How to handle such situations systematically is the topic of 3.4 error handling.
  • “Simple automation” is actually a clear machine. From the outside it looks like: “AI answers customers.” From the inside you see the seven named parts, each with exactly one job. It is precisely the clear division — not a magical model — that makes the flow reliable and fixable.

In plain terms: when the system sometimes errs, the anatomy shows which part erred — wrong data at step 2, a weak instruction at step 3, checks too loose at step 5. Without the diagram, the error is “AI's fault”; with the diagram, the error has an address to go to and fix.

Every part, of course, also needs someone responsible for it — who those people are and how the work is divided is covered by 1.6 Roles and responsibility in a project; that question stays open here.

Summary

  • Every AI-automated system has seven parts: the trigger, input data, the instruction, the AI model, the checkpoint, action/output, and data storage.
  • The AI model is the only part that guesses — the other six are ordinary software that make the system reliable and fixable.
  • Three shapes: a single prompt (the human does everything else), a workflow (steps and conditions written in advance), an agent-based system (the model decides the next step itself). Always start from the simpler one — the agent is the last resort.
  • The steps of 1.4's return-request flow map point by point onto the seven parts — “simple automation” is actually a properly assembled machine.

What's next?

  • previous → 1.4 Where AI automation already works: use cases
  • next → 1.6 Roles and responsibility in a project
  • Practical building → Level 2 (building workflows: 2.3, a guide to the first system: 2.5)
  • back → handbook index

Last updated 2026-10-05

← PreviousWhere AI automation already works: use casesNext →Roles and responsibility in a project

© 2026 Siim Liimand · SeoWeb

GitHub/AI Handbook/Tallinn, Estonia

59.4370° N, 24.7536° E — Tallinn, Estonia

↑ Top