Team workflows and standards

Target audience: non-technical leadership + technical | Prerequisites: 5.1 Architecture at scale

What you'll learn

After this document, you'll be able to:

• explain why a standard (an agreement that makes work predictable) is not bureaucracy but quality assurance in a growing team;
• name the five standards that must be written down in every team doing AI automation;
• give every system and every prompt an owner (the owner — the person responsible for a system/prompt, a single name);
• run significant changes through a review (a review — another person looks over the change) before they go to production;
• onboard a new member so that they work reliably from the very first month.

In plain terms

As long as prompts live in people's heads, a conversation is enough. In a team of ten, heads stop holding up: someone changes something, someone doesn't know, someone doesn't test. Standards aren't about control — they make your work predictable: everyone knows how things get changed, who may approve, and where to look things up. And when a new person arrives, they read it from the documentation, not from someone's memory.

Why standards: predictability is value

There's one sentence that lives beside every growing automation project: “Kaja fixed the prompt, but nobody knows why or whether it was tested.” Nobody is guilty — Kaja really did fix it. The broken thing isn't the person but the system around the person: the path of a change isn't written down, so every change is an individual risk that depends on who happens to be at the keyboard.

A small team can agree verbally on everything important — up to a certain number of people. Agreements living in heads don't copy: a new member doesn't read them, they guess — and one untested change reaches the customer directly.

A standard (an agreement that makes work predictable) solves exactly this. It doesn't slow the work down; it makes it predictable: the same bug gets the same response no matter who finds it, and everyone knows where things stand and who decides. The difference from bureaucracy is simple: bureaucracy is writing things down that nobody uses afterward; a standard is writing things down that every change actually goes through. That's why standards aren't bureaucracy but quality assurance.

The five standards that must be written down

What follows are five agreements — each fits on half a page.

1. The prompt change flow. Workflows (an intended sequence of actions) define how a prompt gets from one state to another: the need for a change → the testing cycle (2.1) → under another person's review → recorded in the bank (2.6). Without a flow, prompts get changed by conversation and mood; with one, a change is a sequence of steps anyone can walk through.
2. Approval rights. Not everyone on their own: the agreement says who may let a change into production — that is, into use, where the result reaches the customer. The usual split: changing and testing is open to everyone; going live is the prompt owner's right or that of their named deputy — human-in-the-loop (a workflow where a human approves the result before use) at team level: the change itself is also a result that someone must approve.
3. The birth protocol for a new system. The birth protocol (the check a new system passes before going live) prevents the situation where the first result that reaches a customer is also the first test. Before going live, every system passes three steps: the safety check — what can go out and where a human steps in (3.5); evaluation on a test-case set (4.5); documentation — bank, owner, and limits written down (the checklist in 5.8). The full checklist in 5.8 additionally covers the cost estimate, security, and monitoring readiness.
4. Rules for lists and documentation. The agreement about where to find what: one prompt bank, one system list (owner, status, last tested), one decision log. “One” means exactly one here: if the same prompt lives in two places, soon nobody knows which version is the true one.
5. The review principle. Significant changes never go to production on one person alone. The review (see the explanation in the learning goals) isn't a question of trusting a colleague but simple arithmetic: the author sees their own plan; another person sees the record as it actually is — and often notices exactly what the author no longer sees.

When standards grow to company-wide scope — who may make which decisions and to whom everyone answers — that's already a governance (rules for steering the system) question: see 5.7 Responsibility, ethics, and governance.

Documentation in real time

In plain terms: a document that no longer describes reality isn't a document — it's a well-formatted mistake. The principle for the whole library: if you open an entry and see that it lies, spend two minutes and fix it before starting new work — not “later, when you have time.”

This applies equally to the standards themselves: a bug fixed in real time is two minutes of work; false entries a month old are research nobody gets time for.

Roles in a growing team: an owner for every system

1.6 Roles and responsibility in a project defined five roles — sponsor, builder, content designer, reviewer, maintainer — and that isn't repeated here. A growing team raises a second question: not “which roles exist,” but “who carries them on each system.”

The rule is one sentence: every system and every prompt has an owner (see the explanation in the learning goals). One name, not a committee — because by default a committee is responsible for everything that goes well and for nothing that goes wrong.

The owner doesn't have to write or test every change themselves — they must have the right to approve and the duty to know where their system stands. One person may own several systems; only one state is forbidden: nobody owns anything. When the owner leaves or goes on vacation, a deputy's name is written into the bank — the person changes, not the responsibility.

In plain terms: “everyone keeps an eye on this” means in practice that nobody does. An owner isn't a rank or a culprit — it's an address where questions go and whose signature sends a change live.

Onboarding a new member

In plain terms: well-written standards are the best onboarding material — a new person reads for one day and knows how things get changed here. A bad standard looks like this: “Ask Jaak, he'll explain” — and when Jaak leaves, nobody knows anything anymore.

Onboarding is three steps:

1. Read. The library is ordered into levels (handbook index): the fundamentals 1.1–1.6, then practice from level 2, onward through levels 3–5 depending on what the person is starting to work on. The order isn't a style requirement — each level assumes the previous one.
2. Watch along. For a week, the new member watches how an experienced person walks through the flows — how a change reaches the bank and what happens when a test fails.
3. Do it under review. The first changes go through the same flow as everyone else's — under another person's review. This way the new person learns the flows without the customer paying for the lesson.

The introducer is the prompt's or system's owner or an experienced builder — not whoever “happens to have time.” A good standard is written so that onboarding takes days, not months.

Step-by-step example: the Number Bureau from 4 to 12

The same fictional Number Bureau that 1.6 and 2.6 have described. Starting state: four people worked on the system — Anu, Kaja, Merle, and Jaak — and all 12 prompts had been organized into prompt banks. Then, within half a year, the office grew to 12 people: new accountants joined and two new builders were hired.

Chaos came quickly. The prompt “monthly summary email text” was changed by three people in the very same week — each writing their own version, overwriting one another. One change reached production untested, and the wrong confirmation email went to a client: the email confirmed a summary whose numbers came from a state compiled according to the old template. To the question “which of your emails is correct?” the office had no answer.

Anu and Jaak write down four agreements:

1. The change flow, written down. Every prompt change goes through the same path: change → test → another review → approval → bank. Table below.
2. An owner for every prompt and system. Twelve prompts and one system — thirteen names in the bank. The two new builders got the sales invoice and payroll flows; Kaja keeps the summary prompts as before.
3. A weekly 15-minute review moment. Every Monday: what changed, what was tested, what was left unfinished (how to build such a routine is taught by 4.6 Production monitoring).
4. A new-employee page. What to read and in what order — 1.1–1.6, then level 2, onward as needed (handbook index) — and who the introducer is.

The change flow as a table:

A month later, nobody in the office asks “which one is right” — the bank answers.

Summary

• A standard is an agreement that makes work predictable — not bureaucracy but quality assurance: the same bug gets the same response no matter who finds it.
• Five standards must be written down: prompt change flows, approval rights, the new-system birth protocol, documentation rules, and the review principle.
• Significant changes never go to production on one person alone — the second eye isn't a lack of trust but protection against human error.
• Every system and prompt has an owner — one name, not a committee.
• Documentation gets fixed in real time — a wrong entry before starting new work, not “later, when you have time.”
• Well-written standards make onboarding fast — the new member reads, watches along, and makes their first changes under review.

What's next?

• previous → 5.1 Architecture at scale
• next → 5.3 Security and data protection (GDPR, audit)
• back → handbook index