Skip to content
Lesson Four

Anatomy of a
simple system

Frontend, backend, datastore: the three parts nearly every system is made of, and the flow one request takes through them.

Scroll, click, or use the arrow keys to move through.Scroll, or use the arrows and dots to move through.

Almost everything is this

Nearly every system you use is three parts to build a flow.

The frontend you interact with through buttons, words and screens; a backend that organizes and controls; and a datastore that saves the work. They are designed with a flow between them to produce the desired output.

Frontend
see · type · click
Backend
organize · control · call the LLM
Datastore
save the work
The frontend

What you see and touch.

The pages, buttons, and forms in a web page or an app. It holds no truth of its own: it displays what the backend gives it and collects what you type and click.

Runs on: your device · Job: display and collect
The backend

Where the rules live.

A program running on a server. It receives requests, decides what is allowed, applies the business rules, calls services like an LLM when the work needs one, reads and writes the datastore, and sends back an answer. When people say “the logic,” this is where it lives.

Runs on: a server · Job: decide and enforce
The datastore

What the system remembers.

Storage that survives after everyone logs off. It might be a database, a set of files, or blob storage: the form varies, the job does not. It is the only part with a memory, so if something is not saved here, the system does not know it tomorrow. Frontends and backends can be rebuilt; the datastore is the part you protect.

Runs on: a server · Job: save and remember
Endpoints and requests

An endpoint is a function with an address.

The backend exposes named functions, each with a unique address and its required inputs. To perform an action, the frontend sends the required data to that address and gets a response back. A call to an LLM works the same way: the provider exposes an endpoint, and your backend sends text to it.

Put it together

One request,
end to end

A real example: an AI proofreader

A page that proofreads your text.

Take the simplest useful AI tool: a page where you paste a draft, click proofread, and get a corrected version back. Here is everything that happens between the click and the answer.

1
You paste a draft into the page and click proofread. The frontend collects the text.
2
The frontend sends the text to an endpoint on the backend.
3
The backend checks that you are allowed, then calls the LLM's endpoint with your text and the instruction to proofread it.
4
The LLM returns the corrected text, and the backend saves both versions to the datastore.
5
The response travels back and the corrected draft appears on your screen.

A few seconds end to end, and every AI tool you use is doing exactly this.

For anyone building with AI

This is the map the AI works on.

When you build

Ask an agent for a tool and this is what it builds: a frontend, a backend, a datastore, and the flow between them.

When it breaks

The first question is which part broke: the thing you see, the rules, or the memory. Naming the part is half the diagnosis.

When AI connects

Connecting AI to a system means calling the same endpoints the frontend uses. The next lesson covers how.

The lesson in one line

Three parts, one flow, and the design of a harness.

The proofreader you just walked through is a deterministic structure wrapped around a probabilistic LLM call: the harness from Lesson One. Every AI tool you use is built this way, and every tool you build will be too.